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

[Leo Romanoff <romixlev@...>]

> Von: Fabien <fleutot+lua@gmail.com>
>An: Lua mailing list <lua-l@lists.lua.org> 
>Gesendet: 15:45 Mittwoch, 24.Juli 2013
>Betreff: Re: Proposal for a standard way of defining custom operators in Lua
> 
>
>
>Fancy syntaxes tend to improve your ability to map your own thoughts onto code, but make your code more impenetrable by anybody else. Fancy 
>operators, with their impronouncability, associativity, commutativity, precedence, tokenization rules, and with people's overloaded prejudices about what 
>they mean, almost always end up costing more in maintainability than they afford in expressiveness. <troll> Just look at the debacle of ">>" / "<<" 
> overloading by C++ streams </troll>.


As a long-time C++ developer, I cannot agree with that! :-) 
Jokes aside, IMHO, it is a matter of a taste. 

Yes, it is a powerful feature, which can be misused. But it doesn't mean it has to/will be misused. As an example, C++ and Scala are not that bad after all.
And their fate is not that same as Lisp's that you mention. This is probably due to the fact that operator oveloading alone is too weak to f*ck up the whole language. But Lisp with its ability to redefine more or less almost everything was enough for that purpose ;-) Another factor in case of Lisp was probably the fact that it was a first language which offered such possibilities. People were not aware of dangers at the time. But today we hopefully know better.

>For this reason, new operators definition isn't consistent with Lua's design principles. I even have some reserves about user-overloading of arithmetic 
> operators: you should only overload them with operations which respect their algebraic properties, and I don't think it should happen on anything but 
> userdata.

>
>
>Now there are reasons to play with them: first it's fun, and that's good enough a reason in some contexts. More importantly, out of wacky experiments 
> sometimes come great ideas, worth implementing in serious languages. Think of Lisp's legacy: it's a language entirely tuned for fun and personal 
> expressiveness, with a very bad record in terms of large-scale long-term collaboration, but half of the ideas that make modern languages productive 
> started as Lisp macro experiments. So yeah, there's already a dialect of Lua optimized for language tinkering, and it's called Scheme ;-)


:-) 

>TL;DR: I might enjoy playing with mine, but not at the price of risking having to play with those of other people I didn't personally select :)


I worked on pretty big C++ and Scala projects with many other people and I survived ;-) It is not that bad. But of course it requires a certain discipline and good documentation, when you start playing with operator overloading and new (embedded) DSLs.