user-defined operators

[Samuel Rivas]

Richard A. O'Keefe wrote:
> 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.
> 
> Let me quote a famous compiler textbook (exercise for the reader:
> which book?):
> 
>     p330:	An "overloaded" identifier can have a set of possible
> 		types.  [They really mean "signatures", and really.]
>     p334:	A symbol that can represent different OPERATIONS in
> 		different contexts is said to be "overloaded".
> 		[This is the "multiple definitions in scope at once"
> 		 definition I used, and is different from the one on		
> 		 p330].  Overloading may be accompanies by coercion
> 		 of types.
>     p344:	A DISTINCT NOTION from overloading is that of
> 		"polymorphism".
> 
> It invites confusion to talk about types in this context, because
> Erlang doesn't have them.  A function like
> 
>     f(X, Y) when integer(X), integer(Y) -> X + Y;
>     f(X, Y) when list(X), list(Y) -> X ++ Y.
>     
> is a *single* definition which reacts differently to different
> run-time values, just like
> 
>     f(X, Y) when X >= 0, Y >= 0 -> X + Y;
>     f(X, Y) when X < 0, Y < 0 -> X * Y.
> 
  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.

>  An operator which is confusing because it is bound to a function
>  that has a confusing definition is not confusing because it is an
>  operator but because the function that defines it is confusing;
>  using it as an operator does not introduce ANY kind of polymorphism
>  that is not already present or ANY kind of overloading that is not
>  already present.

  You are not adding more polymorphism or overloading, you are mapping
the problems of functions to the operators. 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).
 
> Adding user-defined operators to Erlang WOULD NOT AND COULD NOT
> introduce any kind of polymorphism or overloading that Erlang doesn't
> already have.  If you don't like those kinds of polymorphism or
> overloading or witchcraft or whatever you call it, blame EXISTING
> Erlang for that, not operators.

  IMO, you need the operators to represent some actions you cannot
easily write in the language. With those operator and other functions
you can write more functions. So functions are bound to programmers
skills to do them readable. Operators do not, unless you allow user
defined operators. That's why I think you are introducing more
confusing to the language.
 
> Having used several languages with user-defined operators, I have to
> disagree strongly.  User-defined operators (especially alphabetic
> ones) can dramatically improve the readability of code.  They have
> absolutely no effect on the *semantic* simplicity of a language,
> and only trivial effect on the *syntactic* simplicity (one extra
> grammar rule).

  Perhaps is a matter of taste, but I don't think the use of
user-defined operators (neither alphabetic or non-alphanumeric) improve 
the readability of the code. Infix notation is ambiguous and we only use 
it for historic reasons. So if programmers have become used to use
function(argA, argB) instead of argA function argB I don't see why to
return to the imperfect notation. 

>     Not familiar from school:
> 	* (should be x) / (should be -:-)
  Why / should be -:-? (just curious)


Best regards.
--
 ---------------------
|	Samuel        |
 ---------------------