On 8/20/07, Mark Hamburg <mhamburg@adobe.com> wrote:
on 8/19/07 8:39 PM, Anders Bergh at anders1@gmail.com wrote:
> 2. shorter syntax for anonymous functions. I saw a patch somewhere
> that allowed "do ... end" syntax for these... really nice looking in
> my opinion.
I used to really want this and even made proposals in this regard. I've gone
back and studied the subtleties of Smalltalk blocks and realized that the
problem is a lot deeper than one would expect.
After various experiments with metalua, I think the best compromise is to have "|x,y| some_expr" be a shortcut for "function(x,y) return some_expr end".
If you need more than an _expression_ as a function body, or multiple returns, you're probably doing something non-trivial, and you should not only use the traditional syntax, but give the function a proper name, for documentary purposes.
About smalltalk-style blocks, it would be a completely different feature, I don't think that's what people are asking for. Besides, coroutines can serve in most cases where you'd want block returns, and I think they're conceptually simpler to grasp.
About passing unevaluated code, I'd rather pass explicit functions, without messing with return's semantics, nor adding a construction that's "quite a function but not really". An acceptable compromise is to have an infix, low-priority application operator, a la Haskell. Keeping the function visible makes it clear what a return would do:
locking(some_mutex) $ function()
-- do my synchronized stuff
end
Another alternative is to have macros that let you define new control statements :)
About conditional expressions, and more generally statements in an _expression_'s context: ternary operator "a<b ? a, b" works quite well. When it comes to statements-as-expressions, most legitimate use cases are about using conditionals or assignments inside a sub-_expression_. I'd rather provide _expression_ operators for these two cases, and keep the distinction: a statement has a side effect, an _expression_ yields a value. You're allowed to disregard that design rule if you know what you're doing, but the syntax shouldn't encourage you. Unifying expressions and statements makes sense in a functional language, but that's not Lua's philosophy.
And these stuffs' usefulness is to be weighted against the will to keep Lua orthogonal. Until know, the designers' ability to remain deaf to such pleas has kept the language amazingly clean, so maybe we'd better trust them :)
-- Fabien.
