lua-users home
lua-l archive

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




On Feb 8, 2008 12:56 AM, Leo Razoumov <slonik.az@gmail.com> wrote:

How difficult is it to use MetaLua to augment Lua syntax with
Matlab/Octave matrix specific syntactic constructs.
For example, I would like to have something like that

t= {'a','b','c','d','e'}[2:4] --> {'b','c','d'} -- (index ranges)

t={1:9:3} --> {1,3,6,9}  -- (inline iterative constructors)

t={1,2;
    3,4} --> {{1,2}, {3,4}}  -- (almost natural matrix contstructors)

c= 1+2i  --> Complex number re=1, im=2

Would be easy on principle, it's actually already mostly done in the clist extension, although with different syntactic choices. However, your proposal will conflict with Lua syntax in many places:

- ":" is the method invocation operator, which makes it hard to override after an _expression_

- {1,2;3,4} already is a valid Lua _expression_, with a sense different from the one you're proposing. That's certainly one of those "not worth it" cases where a surface syntax tweak will only cause havoc.

-{ extension "clist" } will let you write:
t = {'a','b','c','d','e'}[2 ... 4]
t = {i for i=1,9,3}

As far as syntax (re)usability is concerned, syntax is a matter of
convention. If a (large) group of people consciously agree to  use the
same stable syntax, their code can be made reusable.

I agree, but the trick is, it's very difficult to make it happen. *Some* of the musts, for an extension to be even remotely considered for reuse, is that it must not break the existing syntax, and it must be easy to integrate with other extensions. For instance, if you introduce a new kind of expressions, and they're always prefixed with a dedicated keyword, it won't conflict with other well-behaved extensions (unless they happen to use the same keyword in the same context). OTOH if you monkey-patch an existing part of the language, e.g. the function parameters parser, you might not be the only one who want to do that; other macros might be reusing that parser in different contexts, or they might patch it themselves. Your extension is therefore much more rogue, and it'd better bring something very special to justify such a disregard to modularity.