Re: What's up with token filters (Re: New operators?)

[David Given <dg@...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glenn Maynard wrote:
[...]
> I don't want to have to learn a new child language when I use Lua in a
> different place, depending on the little extensions in each case.  Adding +=
> to my copy of Lua is not the same as += being added to Lua.
[...]
> It
> just seems like an odd omission from the language ...

The Lua philosphy is that the core language contains just enough language to
be useful, and if you want any additional syntactic sugar, you add it to *your
own* copy. The fact that each place uses its own dialect is a feature, not a
bug. The core language has very little sugar (the only things I can remember
offhand are that x.y is x["y"], function foo() becoming foo = function(), and
the : operator.

Also, adding something like += isn't as simple as it first appears. Remember
that the = operator is *not*:

lvalue = expression

Instead, it's:

lvalue, lvalue, ... = expression, expression, ...

So if we have a statement like:

a, b += 1

...then what this is actually going to do is to add 1 to a and add nil to b,
which will most likely fail. This is not intuitive and you're almost certainly
going to get people wanting this special-cased so that 1 gets added to both a
and b. That's even *less* intuitive, because it's now inconsistent with =.

Even once that's been settled, you now have a primitive operation for
'increment' (and decrement, and self-multiplication, and self-division, etc).
Would it not make sense to add metatable entries for these? That would allow
such things as:

local vector = Vector.new(1, 2)
vector *= 1.5 -- scale vector in place

Logically you do, because it adds consistency to the language, but now you've
just doubled the number of metatable operations, which has lots of knock-on
effects on size and speed.

Basically, this kind of extension adds convenience rather than functionality,
and as such I do not believe it belongs in the core language due to the
additional complexity the extension requires. (In fact, I'd argue against the
'function foo()' syntax, too, but it's too late now for that.) This sort of
thing is, IMO, better suited for a precompilation step or a local
modification, than something that has to be designed so that it suits everyone.

- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───────────────────
│ "Thou who might be our Father, who perhaps may be in Heaven, hallowed be
│ Thy Name, if Name Thou hast and any desire to see it hallowed..." ---
│ _Creatures of Light and Darkness_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGHnUaf9E0noFvlzgRAu5HAJ9rDL9rS1aJ1jx+/fB2CdUN5nQnSQCfbO3x
IOlS1OXfaXONyj7SnQAEL9M=
=oVnk
-----END PGP SIGNATURE-----