Re: Lightweight syntax: a dissident view

[Luis Carvalho <lexcarvalho@...>]

> > 
> >    \x,y,z(x*y+z)    --> function(x,y,z) return x*y+z end
> > 
> > It's concise and seems to have the fewest (zero?) ambiguities.
> > 
> I'm starting to get the hang of this discussion.  Nobody really 
> takes it seriously, but it's hard to resist the temptation to 
> chip in.  Even I, who think there is zero chance of the developers 
> implementing anything seen so far, now succumb.
> 
> If all you want is a concise notation for mapping an m-tuple
> of variables to an n-tuple of expressions, the standard way to 
> do it in mathematics is
>     $$  (a,b,c,d) \rightarrow (f,g,h) $$
> (sorry for the TeX, but the Lua community will very shortly be
> swelled by thousands of TeX users once LuaTeX is the standard).
<snip>

I'm also very fond of this notation but, for an argument similar to yours,
would prefer

  \x,y,z.(x*y+z) --> function (x, y, z) return x * y + z end

since it's more formal in a different context. I agree it tends to get a bit
jammed and the parens have an alien meaning, but I guess it's all justifiable
as being a departure from usual Lua syntax for brevity's sake. One can get
used to switching in and out of these lambda forms after a while, but what
about code readability?

Another option is to go for a more familiar Algol/Lua style,

  lambda(x, y, z) x * y + z --> function (x, y, z) return x * y + z end

where we could either limit the output to one expression (too restrictive),
assign a lower precedence (potential source for confusion), or add optional
delimiters like

  lambda(x, y, z) (x * y + z)
  lambda(x, y, z) {x * y + z}

and live with a mixed approach where parens and brackets have different
semantics under lambda. These options are listed by my order of preference; I
could live with one-expression lambdas since I believe it covers most of the
need for a shorter anonymous function -- at least that's my case -- but I'm
not sure it's reasonable to expect changing the language just for it alone.

Which brings me to my next point: should we be discussing something more
general beforehand, such as statements as expressions or a macro facility?
Most of this discussion on shorter forms would become moot if, for example,
the token filter was made official in Lua 6.0...

Finally, I'd like to comment that while it's almost impossible to not pitch in
your two cents in this thread, the discussion would be much enriched if
somehow guided by the Lua team; for instance, how does this discussion --
being it about shorter functions or borderline statements as expressions and
macros -- fits in the big plan for Lua? Would such proposals be considered?

Cheers,
Luis

-- 
Computers are useless. They can only give you answers.
                -- Pablo Picasso

-- 
Luis Carvalho (Kozure)
lua -e 'print((("lexcarvalho@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'