Re: Macros and expressivity

[Mark Hamburg <mhamburg@...>]

on 1/11/08 2:54 PM, Asko Kauppi at askok@dnainternet.net wrote:

> 
> Chaining functions to each other can be done already, by returning a
> function that then again gets called, until the end says () or similar.
> 
> I've used this somewhere, guess it was a 'switch' implementation. But
> you're right, the "function()" token itself makes it a bit uneasy on
> the eyes.
> 
> Here's two lines from luaSub's (one of those dreaded 'macro'
> packages :) tests/test-do.lua:
> 
> <<
> f do print "not" end function() print "quite" end do print "yet!" end
> -- f ( function() print "not" end ) ( function() print "quite" end )
> ( function() print "yet!" end )
> <<
> 
> First line is the modified syntax and the latter is what is fed to
> Lua core.
> 
> 'f' is defined as: function f(x) x() end
> 
> This needs two changes in the Lua parser:  allowing 'do' as 'function
> ()' and allowing function blocks as paranthesis-less args, just like
> func"" and func{} already are.

For your example, I think you need:

    f = function(x) x() return f end

But yes, Lua is really close to being able to support this natively.

Of course, the moment one starts using this to create control constructs,
you get into the messy question of what does a "return" inside the code
mean.

Turning to my class examples, without the sugar but with the support for
parenthesis-free passing of function arguments we get:

    class "Foo" function()

        inherit_from( Baz )

        function display( self ) print( self:name() ) end

        readWriteField( "name", "_name" )

    end

This is an improvement over:

    class "Foo" ( function()

        inherit_from( Baz )

        function display( self ) print( self:name() ) end

        readWriteField( "name", "_name" )

    end )

But still looks strange. Furthermore, "function()" is a lot more to stick on
the end of a line than "do".

The other reason I started adding in the notion of a standard dynamic scope
was that it avoids having a global references detector complain about the
declaration of "display". This could actually be handled as:

    class "Foo" ( function()

        inherit_from( Baz )

        function _S:display() print( self:name() ) end

        readWriteField( "name", "_name" )

    end )

But as with the explicit function creation, the use of a magic global
variable feels odd compared to using special syntax.

(On a tangential note, it might be interesting to require special syntax for
accessing the global environment -- e.g., global symbols would have to be
prefixed with "$". Variables would be "local by default" except that you
would still have to declare them so essentially they would be "undeclared by
default".)

Mark