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

[Rici Lake <lua@...>]

Asko Kauppi wrote:
> With Andy's idea about C-side-only token filtering, we could have a 
> continuum of choices for the developers. Pick as much (or little) sugar 
> as they like.

Why not just let them write directly in Lua VM code then? :)

I hate to be a wet blanket here, but I think Roberto's concerns really
need to be addressed. Removing all syntactic sugar from "core Lua" will
make it really uncomfortable to write useful libraries. If there were
no : notation in "core Lua", we'd start seeing suggestions that
"safe library coding" avoid the syntax altogether, and frankly I
don't want to give it up. (I've also left Roberto's important question
about : notation in, as it is not possible to implement it with a source 
transformation, as far as I can see.)

It's really cool that it is quite easy to make Lua-like languages with
a variety of tools -- source patches, token filters, metalua, etc. This
allows for easy experimentation with language features, some of which
may eventually get adopted by Lua, or may become features in other
languages. It is also interesting that it is easy to create a language
which essentially targets the Lua VM by generating Lua source; there
are many applications for that.

But these are not Lua, and they shouldn't pretend to be. If one wants
a language to grow a large and useful array of third-party compatible
libraries -- and I believe that you share that goal for Lua -- then
it is vital that there be a standard Lua in which you can write those
libraries. If you are using a source-transformation system to code
those libraries in, then by all means provide the pre-transformed
code as well, but make sure you distribute something which can just
be require()'d by a casual Lua user.

-- Rici

> > > (Not to mention
> > > how to implement the : notation correctly [that is, without extra side
> > > effects] with token filters...)
> > >
> > > -- Roberto