Re: Microlight

[Jay Carlson <nop@...>]

On Dec 18, 2012, at 10:13 AM, Pierre Chapuis wrote:

[mapcar, filter]

> That being said I agree that these primitives are being abused a lot in
> Lua. Its style is mostly imperative, embrace it or use a Lisp...

I keep hearing this as "get off my lawn". So, OK. I go walking back to the park I passed. Wait, that's not a park, it's the Lisp mansion's gigantic front yard, and staring at the renovated Modernist house, I managed to trip over the Common Lisp LOOP macro and gave myself a concussion. So now I'm lying on Lisp's lawn and somebody is yelling something....

LOOP is pretty much the answer to everybody's list comprehension, filters, reductions, etc etc and you can even write FOR I = 1 TO 100 in it. It largely survives as a warning to others. 

http://www.gigamonkeys.com/book/loop-for-black-belts.html

http://common-lisp.net/~loliveira/tmp/iterate-manual/html_node/Introduction.html

Lua's problem is that iteration control features are too weak to express common/repeated patterns.[1] The good news is that Lua can do this; the bad news is the only way to control evaluation is with lambdas[2]. Since we're apparently not going the road of macros, we're stuck looking for other paths. Table constructors could use better function syntax if they are to serve as control flow syntax surrogates. Smalltalk blocks would work, and are weaker and a better fit to imperative languages; I've grown to think this is the genuine contribution of Ruby to the modern language landscape.

Jay

[1]: This is not quite fair. The generic-for iterator protocol solves a lot of problems in an elegant way, bringing together many language features in one place. It is much cleaner than in peer languages. 

[2]: OK, lambdas are the only way to do so with lexical captures. If you don't need lexical captures or syntax-checking at compile time, memoize load("function (_1, _2) return _1 < _2 end").