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

[Glenn Maynard <glenn@...>]

On Thu, Apr 12, 2007 at 07:06:18PM +0100, David Given wrote:
> 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

"Just enough language to be useful" certainly does not describe Lua.

> own* copy. The fact that each place uses its own dialect is a feature, not a
> bug.

Fragmenting the language is definitely a bug.

> ...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 =.

It's perfectly intuitive for me that the above would fail.  For any given
language feature, some people will want special cases for one reason or
another.  That's unrelated to the value of the feature itself.

> 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.

I'd want no separate metamethods for these; it encourages inconsistent
behavior between the + and += operators.  No separate metamethods means
I can read code using addition in both forms without having to keep checking
whether they're actually the same operation, and it means the feature has
no impact on the VM.

> 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.

Convenience *is* functionality; programs are written by people, not machines.
A cumbersome, inconvenient language is a bad language.  As a scripting
language, Lua is very convenient, which is one of its strengths: it's very
natural and quick to write code for.  This is just a missing piece.  You're
contriving complexity, but in my opinion, it's the contrivances that are
complex, not the feature.  :)

(By the way, the length of this discussion may suggest I feel more strongly
than this than I do.  I think the reasons given so far for not adding it are
poor ones, and I'm happy to discuss it because it's interesting, but I'm not
losing any sleep over it.)

-- 
Glenn Maynard