user-defined operators

[Samuel Rivas]

Richard A. O'Keefe wrote:
> I am really confused by this.
> By that definition, C++ and Java have overloaded symbols
[...]
> and Haskell and Erlang do not.  They just don't.  It really is beyond debate 
> that *by THAT definition*, they really don't.  I don't have to justify this; 
> anyone who doesn't believe it can check for themselves.

  This can be your opinion, but is not beyond debate:
    "There is one final feature of Haskell's type system that sets it
      apart from other programming languages. The kind of polymorphism that we
      have talked about so far is commonly called parametric polymorphism.
      There is another kind called ad hoc polymorphism, better known as
      overloading"
  From: http://www.haskell.org/tutorial/classes.html

[...]
> 	> 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?
> 	
> When you said that introducing user-defined operators would mean that
> you didn't know what operators (and you specifically mentioned + ++ *)
> meant any more.

  I haven't wrote that. I haven't say you will lose your knowledge about
built-in operators. And I only mentioned those (+ ++ *) operators to say
they are different 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".
[...] 	
> f/2 in that example has ONE definition.
> It is a CONFUSING function but not an OVERLOADED function.
> Erlang simply doesn't have any mechanism for overloading functions.

  f/2 is NOT ONE operation (so it must be several) and f/2 has ONE
definition. *Your* definition (p334 of a famous compiler textbook) says
that symbol is overloaded.

  This discussion about overloading is beyond of "user-defined operators"
and I won't continue it.
[...]

> 	> 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.
> 	
> It is a reasonable inference from what you wrote:
> (A) You were attacking user-defined operators as bad.
> (B) Specifically, you were attacking them on the grounds of "overloading".
> (C) You implied that the existing set of operators was OK.
> But if acting differently for different argument types is bad,
> and any existing operators act differently for different argument types,'
> then the existing set of operators (leaving aside ++ which you said you
> didn't like, although oddly enough ++ and -- do NOT have this property)
> cannot be good.

1) I don't attack user defined operators on the grounds of "overloading", I
   wrote that OPERATORS (in general) overloading is confusing. I know
   Erlang operators are overloaded and I know they do not the same thing in
   different contexts. And I wrote that in a mail that is not related to
   this subthread and I don't know how you have infered I said user-defined
   operators are bad because of overloading.
2) I can't see why a) + c) (even + b what I said that is not correct) comes
   to the conclusion that + and * do only one thing. 
> 
[...]
> 	> 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.
> 
> The () forms are quite clearly WORSE.
> we could argue about whether it is better for the words to be in
> the order that you would really like to say them,
> but it is not a matter of opinion that the operator forms have one
> great virtue for decoding:  you don't have to count the commas.
[...]
> When you see    A `f` B,  it can't possibly be a call to f/3.
  
  I don't see how you can confuse f(A,B) with f(A,B,C).

> 	  Languages are designed with a certain operator precedence to avoid the
> 	ambiguity, because infix notation IS ambiguous.
> 
> Ah, now I understand your form of argument.
> Every man is a cripple, because if he didn't have his legs, he would
> be a cripple.
> Every system of infix operators is ambiguous, because if it didn't
> have its system of precedence, it would be ambiguous.

  I didn't write "infix systems are ambiguous". I wrote "infix notation
is ambiguous".

  In short:

  - I didn't say user defined operators are worse than functions.
  - I didn't say user defined operators are bad because of overloading.
  - I didn't say built in operators will lose their meaning.
  - I said user defined operators (in my opinion) are not more readable
    than functions.
  - I say that there is a clear difference between operators and
    functions (in Erlang): function names set is infinite and operators
    set is not. It is not true operators and functions are the same (at 
    the moment).

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