Re: Proposal for a standard way of defining custom operators in Lua

[Sean Conner <sean@...>]

It was thus said that the Great Leo Romanoff once stated:
> 
> In principle, I agree with you, guys. But I do not quite follow why you
> think that allowing definition of custom operators would result in
> introducing a huge set of strange operators, whose semantics is not known
> to anyone besides its creators. Why so black and white, why looking only
> at the extremes? Either no custom operators at all or use them to the
> extent where nobody can follow...

  So you are perusing some new Lua code, and you come across something like:

	a = { timestamp = os.date() , msg = "Danger!" level = "critical" }
	x = somefunction( @a )

  What would you look for to see what this does? (yes, this is a
contrived example, but I have a meaning in mind for this)

> Many of you say in the same message that custom operators are evil and
> dangerous, but then also say that yes, for bit operations it would be
> nice, and LPEG notation is also not that bad after all, because it follows
> a certain well-known notation, etc. Basically you say that operators and
> DSLs are nice, if they are defined in a meaningful way and follow a
> well-known notation. 

  In the case of LPeg, it uses existing operators; it does not define new
operators.  Bit modules do the same.  

> Some people mentioned that LPeg or Metalua could/should be used. I agree
> that this is the case, but I think it is an overkill for the task. Let me
> explain: We only want to add a few new lexemes to the language dynamically
> and essentially it is the lexer that needs to be affected. And this is how
> I envisioned a possible implementation. IMHO, this is a minimal required
> change.

  Could you provide an example where the existing set of operators is
insufficient for your problem domain?  Perhaps some Lua-esque code of how
you would define your new operators and some examples using it?  It might
help us get a better feel for what you are attempting to do.  

> Assuming that one would use LPeg or Metalua instead would mean that at
> design time one defines a new parser and at runtime this parser needs to
> parse the whole source file containing new operators in a preprocessing
> step just to convert those few new lexems into a pure Lua code, which
> needs to be feed into into Lua interpreter or JIT and parsed again. IMHO,
> this is quite some overhead for such a simple task, but your mileage may
> vary. It is like writing a new compiler just to be able to parse one new
> token, instead of introducing a small change in the existing parser/lexer.

  Well, you don't have to read in the entire source file, process it, then
feed it into the Lua parser---you can look into lua_load() (or load() from
within Lua 5.2) and process chunks of text as Lua is parsing, but if I'm
reading you correctly, you probably won't like that idea either ...

  -spc