user-defined operators

[Samuel Rivas]

Richard A. O'Keefe wrote (and I still respect his opinion):

> Samuel Rivas <samuel@REDACTED> replied most confusingly:
> 
> 	  As you stress, a symbol that can represent different
> 	operations in different contexts is said to be "overloaded".  +
> 	++ and * are DIFFERENT operations, your definition says nothing
> 	about using the same function name to indicate those operations.
> 	
> Nor does it say anything about the Arian controversy, bimetallism, or the
> interpretation of quantum mechanics.  Why should one little definition have
> to deal with quite irrelevant matters?

  It should deal with function names if you want it to justify your
assertion:

    By the definition I use, a symbol which is bound to a single
    definition is not overloaded, no matter how many types that definition 
    applies to.
 
> In Erlang, +, ++, and * are bound to different definitions.
> There is no proposal in this or any other thread to change that.

  Where did I write there is a proposal to change these operators?

> Erlang *already* permits the definition of a function which sometimes
> calls one, sometimes calls the other, of those operations.  That function
> is nevertheless itself still ONE "operation".

  So, is your f(X,Y) when integer(X) ... overloaded or not? In your
previous mail you said that is a *single* definition, which necessarily
lead us to the fact that an operator bound to f is not overloaded.
> 
> 	  You are not adding more polymorphism or overloading, you are mapping
> 	the problems of functions to the operators.
> 
> So what?  What kind of mental deficiency could cause someone to have
> NO trouble with functions that can do different things depending on what
> their arguments are, but to suddenly fall all to pieces when it is an
> operator that does this?

  Again, where did I write there are no problems with functions? I
actually wrote there ARE problems with functions.

> People seem to be arguing against user-defined operators on the grounds that
> operators have some kind of unique sacred character that makes them different
> from functions.  But in EXISTING Erlang this is not so.

  Agreed, that is not the point.

> 	Currently you can have confusing functions, but the set of
> 	operators is well defined and (more or less) widely accepted (I
> 	really don't like the ++ operator since it's just the same as
> 	lists:concatenate and you have to know it because of
> 	optimisation issues).
> 
> I don't know what is meant by "widely accepted" here.  It is, of course,

  This is meant everybody can assume +, *, ++, /, !, ... will do
what are supposed to do. I am not trying to say introducing user defined
operators will change the meaning of these built-in operators but that
you can find one operator that is not "universal" (and I trying to argue
in favour of this will be not a good thing)

> accepted that the set of Erlang operators is what it is; since the
> language was first defined there can hardly ever have been a single day
> when it was widely accepted that it was what it should be.  Right at the
> moment, Joe Armstrong has a proposal for an additional operator, !!,
> which is *not* well defined, 

  Perhaps "well defined" is not a good description. I meant "well
known".

> Anyone who wants to pretend that + and * in Erlang do one and only one
> thing is living in fantasy land.  And you cannot use Erlang for long
> without discovering that X!Y does different things depending on what X is.
> (Related things, yes.  The same things, no.)

  I still don't know where I wrote that.

> 	  IMO, you need the operators to represent some actions you cannot
> 	easily write in the language.
> 
> There are no such actions for which OPERATORS are needed.  Any such actions
> can be defined using function call syntax, and MOST such actions in Erlang
> are defined using function call syntax.  Lisp is proof that operator syntax
> is not needed.

  Agreed, operators are not needed, maybe my "need" is too strong, I
should wrote "want".

> "functions are bound to programmers skills"?  I can make no sense of this.
> Perhaps that proves your point, whatever it is.

  When you are reading a program written by someone you can't assume 
all functions do what you suppose them to do. It is programmer
responsibility to write his functions right. However you can assume what
operators will do if the set of operators is defined by the language.

  You can think reading an unknown operator is like reading an unknown
function. I will not argue against that, it is only a personal point of 
view. I only want to point that, up to this moment, opening the set of operators 
will add more complexity to source code reading, and that can be worth doing it
on not.

> Do you *REALLY* think that
> 
> 	is_element(X, S)  union(S1, S2)   del_element(X, S)  match(X, P)
> 
> are better than
> 
> 	X `in` S	  S1 `union` S2   S `without` X      X `matches` P

   If they are not better they are, at least, the same. I should say again
"perhaps is a matter of taste" to use either one or the other, but I don't 
still see what the problem is with
    is_element(X, union(del_element(Y, S1), S2))
that is not in
    X `in` S1 `without` Y `union` S2

> 	Infix notation is ambiguous
> 
> This is simply untrue.  Infix notation in Erlang is not at all
> ambiguous and adding user-defined operators would not make it ambiguous.

  Languages are designed with a certain operator precedence to avoid the
ambiguity, because infix notation IS ambiguous. Prefix (functions) and postfix 
operators does not introduce such ambiguity in the language.

> 	>     Not familiar from school:
> 	> 	* (should be x) / (should be -:-)
> 	  Why / should be -:-? (just curious)
> 	
> I used  "x"  for U+00D7 MULTIPLICATION SIGN
>    and "-:-" for U+00F7 DIVISION SIGN
> because I still don't quite trust E-mail to deliver non-ASCII letters
> unmangled.  

  Yes, yes, my question was about the real meaning of /

> I'm old enough to remember when 2/6 was half a crown,
> feature of PL/I.)

  Oh! What function is supposed to be / then? (just curious, again)

> There may perhaps be reasons not to support user-defined operators in
> Erlang, and it would be good to hear them rather than scaremongering.

  I'm trying to set out my view, you can think I am a scaremonger if you
want. For me I'll keep thinking it's only I don't agree with you like you 
don't agree with me. 

-- 
 ---------------------
|	Samuel        |
 ---------------------