lua-users home
lua-l archive

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

On 25/07/2013 16.24, Leo Romanoff wrote:
[snip]


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

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.

But this is exactly what I'd like to achieve as well. My proposal is
not to introduce a "wild West" when it comes to custom operators and
overloading, but to provide a basic (I'd even say minimal) mechanism
to define them. Obviously, one should take care and introduce
meaningful, well-known notation whenever possible, instead of
introducing new unknown notations with strange meanings.
Well the problem doesn't lie in people that know what they are doing AND restrain themselves from abusing such a feature.
The problem (IMHO) is that when a language feature is added, it will get used (unless it is so difficult to use that most people don't understand it). This poses a serious threat to readability: people _will_ try the feature and will find it useful even in fields where there are no compelling needs to use it. In other words, it will 
prompt for abuse, even by expert programmers. I wouldn't want
to open a .lua file and ask myself "Is this really Lua?!?".
As for DSLs, I think that there are few problem domains where BOTH the "overloadable" built-in operators are not enough AND there is a compelling need for operational syntax. In such cases probably an expert programmer had better resort to higher level approach (such as writing a parser using LPeg) than to mess with basic Lua syntax customization. 



And if people are too afraid of introducing really strange free form
symbolic forms for operators, then may be a weaker approach can be
taken: - Let Lua recorgnize a "stable" set of well-known operators
which we know from existing programming languages. E.g. it could
recognize (but does not need to understand their semantics. It just
needs to dispatch them via metatables and let those methods handle
the semantics) most/all of C, Java , Python, Ruby operators, etc.

>
> Most of the operators are the same anyway among those languages.
> There are only few symbolic names that are very unique for a specific
> language. With this approach, we limit the damage because no
> free-form operators can be defined. But we have a richer set of
> operators than we currently have in Lua. It can be useful for
> expressiveness of Lua as such and it can make a process of mapping
> existing code from other languages to Lua also a bit easier.

Aehm, no. I don't agree here.
As I said before, if you talk about DSLs and problem domains OUTSIDE programming languages, I acknowledge that sometimes there is a pressing need to mimick the usage of their operational syntax.
If, however, you advocate mimicking the syntax of other PLs for the purposes of easing the porting of code, I'm strongly against it. The reasons are many, but boil down essentially to:
1. in the wild you will end up with lots of half-ported code, using every possible mix of syntax (half-perl half-Lua; 20% Python-80%Lua, etc...), but with Lua semantics. UGLY!
2. Porting code by simple syntax transformation is rarely possible: so to ease the syntax translation phase would only benefit the simpler of projects; the hard work is translating semantics. Thus the benefits won't be so big to compensate for the dangers and the complication.
3. there would never be consensus on which customizable operators to include: it depends too much on personal past experiences with PLs. Moreover, having a fixed number of "overloadable tokens" in a language with no semantics attached is weird and probably complicates matters in the implementation anyway. 
For example Java has (IIRC) <<, >> and >>>, but no <<<. Would Lua
have <<< for symmetry or not? Javascript has ===, would !== also make sense (with no semantics attached who knows)? This would be the 
pandora's box of bikeshedding!
If Lua gets to have bit infix operators (as I would like to) I hope they will come with corresponding metamethods, thus widening the choice for custom operators, if one really has the need of so many custom operators. 



Regarding "minimal" mechanism: 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.

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.

-Leo



Cheers.

-- Lorenzo



--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments