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:
> 
> 
> ----- Ursprüngliche Message -----
> > Von: Sean Conner <sean@conman.org>
> > An: Leo Romanoff <romixlev@yahoo.com>; Lua mailing list <lua-l@lists.lua.org>
> > 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
existing datatypes.

> 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
incompatible:

	syslog.open(syslog.LOG_USER,"myprogram")
	syslog.log(syslog.LOG_WARNING,string.format("Danger %s! Danger!","Will Robinson"))

	syslog.open('LOG_USER',"myprogram")
	syslog.syslog('LOG_WARNING',string.format("Danger %s! Danger!","Wil Robinson"))

  I got around that my using a namespace for my syslog module [1]:

	org.conman.syslog.open('user',"myprogram")
	org.conman.syslog('warning',"Danger %s! Danger!","Wil Robinson")

otherwise, there would be three incomptible version of the syslog module in
existence.

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

	send(dst,msg1,msg2,msg3)

or even [2]:

	send(dst) msg1 msg2 msg3

but I can see your point.  Then I think of LPeg ...

  -spc

[1]	https://github.com/spc476/lua-conmanorg/blob/master/src/syslog.c

[2]	function send(dest)
	  local function s(msg)
	    dest:write(msg,"\n")
	    return s
	  end
	  return s
	end