Re: 'in' keyword today (was Re: mathlib)

[Sven Olsen <sven2718@...>]

The _expression_: a, b, c in some_table    -- which can appear in any _expression_

Making this work would get tricky.  Table constructors also allow _expression_ lists, so how should we interpret:

    {  a, f(0), b in t } ?  

That said, the special cases of function argument lists and assignment expressions can both, I think, be expanded to allow the semantic.  I have a proof of concept parser patch that handles the case of things like:

  print( name, age, height in record ) ==> print(record.name, record.age, record.height)

But it's not pretty, and my sense is that cases where you want the more general 'in' semantics aren't common enough to justify the complexity they'd add to the parser.

A new question:  Should only valid identifiers be used before the
'in'? Or do we allow identifiers and objects?

Peter's power patch allows 'in' to be used in any assignment.  That can be useful in certain situations; like setting up a new environment to contain a subset of _G:

  local env={}

  env.ipairs, env.pairs, env.print in _G

Which expands as:

  env.ipairs=_G.ipairs ; env.pairs=_G.pairs ; env.print = _G.print

Again though, I'm not entirely convinced that the feature is useful enough to justify its implementation complexity.  It really is just the basic local initialization shorthand that I find myself using over and over.  i.e.:

  local a,b,c in t

-Sven