Re: Lightweight function syntax (again) Re: [ANN] Lua 5.2.0 (alpha-rc2) now available

[Mark Hamburg <mark@...>]

On Nov 21, 2010, at 9:52 PM, steve donovan wrote:

> But there is a widespread idea that this is (a) redundant and (b) not
> in the Lua keyword-driven spirit.  I think it makes the functional
> style of programming less 'noisy' - the issue is not 'typeability'  so
> much as  'readability'.  I understand that this belief isn't shared by
> everyone ;)

I agree that the pressure tends to have to do with what sort of programming one is trying to engage in with more functional styles being more challenged by Lua's otherwise very pleasant syntax -- though it is also a challenge for idioms common in Smalltalk and Ruby. For me, it's an issue in trying to build up reactive systems.

I also think it's a lot more about readability than about typeability and that puts significant back pressure on any efforts to move toward more special characters. The issue at hand -- and one clearly up for debate -- is whether the existing syntax ends up overwhelming the meaningful bits in some usages. Contrast:

	seq:map @[ x => x * x ] -- to pick one of the syntaxes recently floated

With:

	seq:map( function( x ) return x * x end )

The former does require that one know the new syntax, but there is a lot less material to dig through to see that it is squaring the value. In the latter case, one would arguably be better off with a named function:

	local square = function( x ) return x * x end

	seq:map( square )

Mark

P.S. In writing this example, I found myself drawn to using some form of braces around the lightweight function if I was going to use it as a parenthesis-less parameter. ( seq:map | x => x * x |  anyone?) I actually disliked the even using the @ sign. That format, however, seems to argue against including statements in lightweight functions which would then probably increase pressure for a ternary operator...