Re: special forms, take two (was Re: A lua version of "amb")

[Jay Carlson <nop@...>]

On Feb 27, 2012 11:36 AM, "Fabien" <fleutot+lua@gmail.com> wrote:

> I see that the undead "short lambda syntax" troll experiences its monthly revival... :)

I know I skipped out on the mailing list for a few years, but this one
seems a bit different. I've decided Lua will never have code running
at compile time. Given that, is there a minimal set of general
capabilities I can get at runtime to fake it for enough of my cases? I
really dislike where Ruby ended up with its blocks, but I've been
thinking a lot about
http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp
.

> Short and curry-friendly lambda syntaxes are idiomatic in functional languages, i.e. languages with little or no side effects: Scheme, ML dialects, Haskell, etc. But mixing a functional programming style with a lot of mutable data is a maintenance nightmare.

I don't think anybody's been talking about a functional programming style.

If you go back to the beginning of the thread, this came out of one of
the usual reasons for Scheme macros: to delay or avoid evaluation of
arguments. The description of (amb) had it as a special form, which I
noted could have been simulated in lua with thunking. A lot of control
special forms come down to "treat my arguments as 0-arg functions, and
I'll evaluate them zero or one time".

There's an obvious example of execute-or-not: switch.

switch(c, {
  p=@() print(a) !;
  q=@() os.exit() !;
  e=@() eval(args) !;
})

where @ is function and ! is end. I'm not sure I like how this looks,
but it's the only short function proposal to allow statements.

This is one of those cases where function declaration syntax inside a
table would work for some kinds of use too:

switch(c, {
  function p() print(a) end;
  function q() os.exit() end;
  function e() eval(args) end;
})

but that's dependent on the cases being suitable as table keys. If
you're building some kinds of control flow you can arrange for that to
be true. Let's ignore the number of tables and closures being
cons'd...

> Lua happens to be built around mutable tables; it would be bad design for the language to encourage functional style.

Do Ruby and Smalltalk-80 encourage functional style?

> If a short lambda syntax would significantly reduce your programs' verbosity, you're probably not being hampered by silly language limitations, you're writing bad code in a language you don't understand.

Without a macro system, the only alternative I know of for extensible
control flow is terse lambdas. Given you went to the trouble of
building the pattern match syntax, you should consider how verbose
anything like it would be in base Lua.

The place I did something like this was
http://lua-users.org/wiki/XmlIter in xmliter.switch(). I used this for
a while although rarely used the more arcane features. Something like
XPath pattern matching is more modern, but I'd expect after
compilation they'd end up in a case statement too....

I was beating on the 0-arg case because it's where this started. Arity
is more important in some cases than others. xmliter.switch almost
needs 1-arg and wants 2-arg. If your domain-specific control flow
extension involves looping you probably care about the 1- or 2-arg
case. As I also said, feelings are mixed on the proliferation of
lambdas, and Python took list comprehensions to cover many of the use
cases instead.

As a bonus, $"" constructors lead almost directly to
Lua-4.0-upvalue-restricted lambdas with L$[[ 2 * %a ]].

Jay