user-defined operators

[Martin J. Logan]

I think that the overloading of operators is a nifty idea and I can
think of a few places where it would make my life easier. I must state
in the face of my previous statement that my take on operator
overloading and defining ones own operators is that it should not be
done. Operators should be defined by a central body responsible for the
language syntax and semantics. In this way a modicum of consistency in
the language is ensured. With functions, because they are typically
spelled out with letters, at least one is nudged in the direction of
intentionality. With operators they can be anything $_ $# @# @_. I hated
reading c++ code where some operator was overloaded to do something
completely unintuitive. This is inevitable when you give control of
these things to anyone.


Example:
wasting_your_time_trying_to_read_this() -.
   %% Here I append strings with the "string <- enters other 
   %% string" operator. At the end I use the "'}{' Convert integer to
   %% string and  append" operator to append an integer to the string.
   BigString = "I " <- "write " <- "crappy " <- "code + " '}{' Integer
<- "   ",

   %% Here I want to to take my string and use the case operator '.]'
   %% which takes a string and an atom either 'upcase' or 'downcase' to
   %% alter the case of chars in a string. I then operate on it with the
   %% 's+' string operator with the argument 'chop' which will remove 
   %% any trailing space.
   Cased = (BigString '.]' upcase)'s+'chop.

I am sure that I will be subjected to erlang code of this type if people
are allowed to create their own operators. An objection that could be
raised is well the Haskell code I have seen does not suffer from that.
The answer to that question is that as soon as the user base grows it
will.

Cheers,
Martin
   
   


On Sun, 2004-03-21 at 11:06, Thomas Lindgren wrote:
> Some time ago there was interest in extending Erlang
> with your own operators, e.g., !!. So why not provide
> them?
> 
> Here is a code sketch for extending Erlang to permit
> simple user-defined infix operators `op`. The idea is
> basically taken from Haskell and seems fairly clean. I
> used backquotes around the operator because Haskell
> did so.
> 
> I modified the erlang parser and scanner to support
> this notation; it seems to work, though I haven't used
> it very extensively. 
> 
> f(X, Y) -> X `foo` Y.   %% note: foo is "backquoted"
> 
> is parsed as if:
> 
> f(X,Y) -> 'foo'(X,Y).   %% call function foo/2
> 
> The operator `op` has the same precedence as
> andalso/orelse. You can also write `mod:func` to
> invoke mod:func(X,Y), e.g.,
> 
>    Port `erlang:port_command` Data
> 
> Both the module and the function have to be non-empty
> atoms. Thus, the following are considered errors,
> where foo is any atom:
> `:foo` 
> `foo:` 
> `:`  
> ``
> 
> I haven't tested how the scanner behaves with extreme
> quoting in the infix operator. The error return value
> in the scanner does not have a format_error. Finally,
> the code could probably be improved by someone more
> familiar with erl_scan/erl_parse.
> 
> Example use:
> ==========
> 1> {ok, Ts, _} = erl_scan2:string("f(X,Y) -> X `op`
> Y.").
> ...
> 2> erl2:parse_form(Ts).
> ...
> 
> Best,
> Thomas
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance Tax Center - File online. File on time.
> http://taxes.yahoo.com/filing.html
> This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
>