Re: Features you would like to see

[Mark Hamburg <mhamburg@...>]

on 8/21/07 8:00 AM, Fabien at fleutot+lua@gmail.com wrote:

> 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 :)

Which is, of course, the second big use for blocks after doing little one
off evaluations.

I rather like the look of the $ syntax above though it doesn't particularly
match with standard Lua. The key benefit is that it avoids putting a
parenthesis after the "end" which always feels odd if the function is at all
long. Interestingly, it's actually more keystrokes this way than it is to
write:

    locking( some_mutex, function()
        -- do my synchronized stuff
    end )

A lot of this ties to wanting to do things with altered scopes. It hit me a
while back that one of the cool things about class definitions in Ruby was
that they opened up a scope in which you could execute arbitrary code to
populate the class. The Lua equivalent would be to write something like:

    class( "MyDBEntity", DBEntity, function() )
        hasOne( "foo", FooEntity )
        hasMany( "baz", BazEntity )
    end )

Again, the parenthesis after the end feels like it makes one too aware of
the low-level details when you want people to think in terms of the
high-level constructs.

Mark