lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


David Given <dg@cowlark.com> writes:

> Paul Hudson wrote:
> [...]
>> Because, for Lua in particular, there is a resistance to convenience and
>> sugar. Not a refusal to ever consider it, but Lua is remarkably free of
>> cruft and I for one would prefer it stayed that way.
>
> Yup. There are, AFAIK, precisely two bits of syntactic sugar in Lua
> --- : notation for calling functions, and 'local function' for
> defining them. And even the first isn't really sugar, as it generates
> specific bytecode that you can't generate elsewhere.

There is more. function id is equivalent to id = function, and most
prominently a.b is equivalent to a["b"].

It is important to realize that all of this "syntactical sugar"
diversity is for cases where commonly and conceptually things are
implemented wildly different from their unsugared counterpart, but are
unified in Lua.

In contrast, |x| x*x is not conceptually different from the variant
written with reserved words.

> So if people want functional syntax, design a *proper* functional
> language syntax from the ground up and translate it into Lua. That way
> you get other functional things like everything-is-an-expression, etc.
> Most functional languages have simple syntaxes that are easy to parse,
> too.

Actually, I am considering trying my hand at reasonably efficient
Scheme->Lua translation.  The music typesetter Lilypond has a somewhat
inscrutable C++/Scheme implementation/extension language system that
seems to put more limitations on readability, extensibility and control
flow than I am fond of.  In particular, coroutines are just nice to
have, and continuations with a large warning label "don't use if you
require efficiency" are not a proper substitute.  At least simple
user-level Scheme code would need to be supported to maintain
compatibility.

However, this would be a rather large project all in all.

-- 
David Kastrup