Re: Another example for syntactically lightweight closures

[Fabien <fleutot+lua@...>]

In practice, "|id_list| expr" has been implemented in metalua for about a year, I use it a lot and I really like it. There's no problem with ambiguity *in practice* as long as you don't allow to pass functions as arguments without surrounding parentheses.

I also gave a shot at "|id_list| do block end", it appeared not to be worth it: it barely shortens the original function call, I perceived no added value. As written elsewhere, altering the syntax induces serious costs, so I avoid to do it gratuitously. I tried also an "on/with" macro to call functors, to retrieve Smalltalk and Ruby's block arguments feeling, which would turn this:

table.imap on t1, t2, t3 with function(x, y, z)
   return x+y+z
end

into "table.map(|x,y,z|x+y+z, t1, t2, t3)". Not really convincing either IMO. 

BTW, you'll notice that I moved the function from the last to the first position: in most interesting functors, it's much better to have the function parameter as the first one: there often is a variadic parameter that you want to put last, to benefit from "...". In the example above, table.imap supersedes map, map2, map3 and all other map_n from statically typed languages such as Haskell. I think that's an issue to keep in mind, when discussing block args.

Another track you might want to experiment, to get rid of parentheses around functions-as-params, is Haskell's $ operator. It's simply a binary __call operator with a very low priority. It would let you write "table.map(t) (function(x) ... end)" as:

table.map(f) $ function(x)
   ...
end

The $ operator has a certain elegance and simplicity which I find not incompatible with the Lua way, actually. In metalua, you can also use ` `, which lets you put a function in infix position: 

t `table.map` function(x)
   ...
end

translates into "table.map(t, function(x)...end". That's not not what it was intended for but it happens to work, at least for binary functions.

To generalize about syntax discussions, my experience is that you need to actually try a syntax for a couple of weeks before forming a useful advice about it. Finally, I happen to dislike to look of <<....>>, but I try to refrain from entering into superficial syntax trolls :)

-- Fabien.