Here's the exprlist problem:
foo(|x| sin(x), cos(x))
How many arguments am I passing to foo? If lambda bodies are exprlists,
then that should be one argument (a lambda_expr which defines a
function of one argument with two results). If lambda bodies are exprs,
then that is two arguments, the first being a function of one argument,
and the second being an _expression_ using a different x.
Traditionally, e.g. in ML dialects, Haskell or "plain old" lambda calculus, lambdas have very low precedence, i.e. what you wrote is to be read as a multireturn lambda. It's quite convenient, as the other interpretation could safely be written "foo((|x| sin(x)), cos(x))": only the last arg of an application can be treated as a multireturn. That's the approach taken by metalua.
Your point about currying is reasonable, but I wonder if the common
case is currying or multiple return values.
I fail to find a practical example where currying impedes access to multireturns, so I'd obviously choose currying, but clearly I'm tainted with a functional background.
Anyway, bottom lines are:
- parentheses canceling the multireturns break the principle of least surprise, so I feel that they're one of the very few un-lua-ish features of lua. I would have preferred a standard function "_one_ = |x,...| x" to explicitly cut the lists when I want to (there's been a recent discussion here about multireturns being unusable in the middle of a table, and no satisfying solution has been found IIRC).
- it requires a lot of thinking to design a robust extension indeed, and the more power you give to developers, the more mediocre code will be written. But can also get amazing things out of them. Think of C++ templates: they've been a source of inspiration for some the most awful, unmaintainable things ever written by careless coders, but in the right hands you get STL or Boost, which are amazing at least according to C++ standards.
I'm not sure that I agree that macros are better for producing new
control structures than blocks
They're more complex, but more powerful. Try to write a continuation-based system, or a structural pattern matching control without macros :) Both approaches have their respective strengths, and I certainly won't deny that Smalltalk is one of the finest language ever designed.
Besides, implementing smalltalk blocks from macros doesn't seem difficult, except for the usual codewalker lack of compositionality issue.
