Re: Another example for syntactically lightweight closures

[Mark Hamburg <mhamburg@...>]

I think there is value in distinguishing between the cases where the goal is
a quick one-liner and the case where we want to pass something more complex
and trying to solve those separately. If the solutions converge, that's
obviously better since it reduces the number of proposed features, but it
may be that the use cases are different enough that it's reasonable to solve
only of them or to solve them in different ways.

With respect to one-liners, I think the goal is to find values for A, B, and
C (including possibly nothing) such that one can write:

    A argument-list B expression C

And generate:

    function( argument-list ) return expression end

The goal would be to do this is in a way that doesn't break any existing
programs.

I'm intrigued by the notation I saw in one message here of saying:

    A = |
    B = |
    C = nothing

Thus allowing one to write:

    | a, b | a + b

    || currentTime() - startTime
        -- up values

And so forth. I'm a little bit leery of the lack of an indicator for the
close of the expression, but I think that decision comes down to seeing how
easy it is to write ambiguous code or code that parses in unexpected ways.

I've also been wondering whether something could be done with << ... >> but
I haven't found a notation for argument lists that makes me comfortable. The
following seem like possibilities, but they also seem to require more look
ahead in the parser:

    << a, b | a + b >>

    << currentTime() - startTime >>

As for the block of expressions case, it remains interesting but using "do"
does require some syntactic changes and it introduces surprising effects
with respect to return and break.

Mark

P.S. The semantic change that might be useful with this would be to have
setfenv return a new function -- i.e., the association of a function
environment to a closure would be immutable. This would allow an optimizing
compiler to notice that | a, b | a + b could be hoisted to the top of the
chunk since it references no upvalues and hence doesn't need repeated
instantiation.