Re: Short function definition syntax; thoughts on Lua

[Mark Hamburg <mark@...>]

On Dec 7, 2009, at 12:03 AM, Juris Kalnins wrote:

>> 2. Expression trees
>> 
>> If one wants to get really compact, then we could actually allow function construction at compile time at least for single argument functions. For example, $ isn't currently used as a token, so consider:
>> 
>> 	$ would be defined as function( x ) return x end
>> 	$ * $ would be defined as function( x ) return x * x end
>> 	$ + 1 would be defined as function( x ) return x + 1 end
>> 	etc
> 
> Nice idea, but Super hard to specify correctly. What is g(x + f($ * $ + 1)):
> 
> g(x + f(function (_) return _ end + function (_) return _ end))
> g(x + f(function (_) return _ * _ end + 1))
> g(x + f(function (_) return _ * _ + 1 end))
> g(x + function (_) return f(_ * _ + 1) end)
> g(function (_) return x + f(_ * _ + 1) end)

Good point. I was going to supply the answer:

	function( _ ) return g( x + f( _ * _ + 1 ) ) end

This was based on a rule where these percolated up the tree as far as possible. That, however, makes these very difficult to pass as arguments.

> ?
> Plus, you have to make parser backtrack arbitrarily far upon encountering '$'.
> Currently it pretty much can emit bytecode as it goes over expression.

It's still amenable to recursive descent parsing and on the fly code generation, but there is probably a lot more work that has to be done in postfix order rather than prefix order and/or a second pass over the expression tree. So, yes, it complicates the compiler a bit (or considerably depending on how one views the construction and tear down of temporary syntax trees as part of the process).

But I think it's the complexity of getting the rules right rather than the complexity of implementation that really kills this approach.

Mark

P.S. LINQ makes this work in C# by using the static type rules to figure out where an expression tree is appropriate. That said, the static typing and extension mechanism in LINQ  doesn't work as well for dynamically extensible libraries precisely because it wants to resolve so much at compile time.