[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Proposal for a standard way of defining custom operators in Lua
- From: Sean Conner <sean@...>
- Date: Wed, 24 Jul 2013 15:28:33 -0400
It was thus said that the Great Leo Romanoff once stated:
> ----- Ursprüngliche Message -----
> > Von: Sean Conner <email@example.com>
> > An: Leo Romanoff <firstname.lastname@example.org>; Lua mailing list <email@example.com>
> > CC:
> > Gesendet: 20:09 Mittwoch, 24.Juli 2013
> > Betreff: Re: Proposal for a standard way of defining custom operators in Lua
Wow ... I've never seen a email user agent change the field names. Neat!
> > Is it a hexidecimal number (so x would be 47806) or the value of an
> > environment variable BABE (which means x is either nil, or a string)? I
> > mean, assuming I included *both* definitions of "$". And if that is
> > even possible, and how to handle such conflicts. I would hate to have a
> > large amount of code using my definition of "$" only to need a module
> > that has its own definition of "$".
> I see your concern. But typically operators are overloaded or defined for new user-defined types (i.e. userdata or tables).
> The goal is not to define a new strange semantics for builtin datatypes and operators, though it could be done.
> Usually it is a very bad idea to do so due to the reasons that you describe and many others.
Okay, so you define the token ("@#$%!!*"), the metamethod
("__athashdollarpercentbangbangsplat"), it's precedence and how it can
appear (prefix, postfix, infix, unary) but otherwise it can only operate on
> It is also not adviced to introduce conflicting or counter-intuitive
> definitions, e.e. defining __plus with a semantics of minus, etc.
> But one thing to mention here is also the following: - Let's forget about
> operators for a moment. Let's speak about APIs. Imagine an API that
> defines a method X. Now everyone can implement her own version of method X
> (an in languages with function overloading or in OOP languages each such
> implemenation may even have the same name). And there is no way to
> guarantee that this implementation is not contradicting other
> implementations or expected semantics of this API. This is a
> responsibility of a developer to implement it in a meaningful and
> compliant way.
True, that is a concern. I've already come across two implementations of
"syslog" that install themselves (in Lua 5.1) as "syslog" but are
syslog.log(syslog.LOG_WARNING,string.format("Danger %s! Danger!","Will Robinson"))
syslog.syslog('LOG_WARNING',string.format("Danger %s! Danger!","Wil Robinson"))
I got around that my using a namespace for my syslog module :
org.conman.syslog('warning',"Danger %s! Danger!","Wil Robinson")
otherwise, there would be three incomptible version of the syslog module in
> > I don't mind verbosity---I think minimalism is overrated (APL anyone? How
> > about Forth?). I suspect minimalism comes from programmers hating to type
> > rather than any notions of purity (one friend knew a programmer who
> > literally would cut-n-paste, even individual letters, because he disliked
> > typing).
> May be. But looking at the prevalence of languages which actively use
> brackets over languages using begin/end I have my doubts ;-) I think
> expresiveness of the language and ability to provide a concise notation is
> playing a big role here as well ... E.g. (sorry for a bit stupid example)
> dst <- msg1 <- msg2 <-msg3 vs send(send(send(dst, msg1), msg2), msg3)
One can always write send() in such a way to allow
or even :
send(dst) msg1 msg2 msg3
but I can see your point. Then I think of LPeg ...
 function send(dest)
local function s(msg)