Extending arithmetic

Shawn Pearce <>
Mon Feb 10 17:50:51 CET 2003

Joe Armstrong <> wrote:
>   Yes - this is the *opposite* of overloading - under-loading :-)
>   If we allowed infix ops then you could have who families of +'s
>   Id *much* prefer one + for integers and another for floats.
>          1.0 f+ X.
> 	{1,2,3} m+ {2,3,4} 

This is in the style of Matlab to some degree I think.  Matlab will
do many different types of math operations, but sometimes uses
different operaters for similiar operations but on different types.

I see nothing with requiring that + act as it does today, and that
f+ always uses floating point math, but can only take floating point
values, and v+ does vectors, etc.

The problem becomes in handling the many different cases:

	{1,2,3} v+ 12
	12 v+ {1,2,3}

are both legal, or as an optimization does order matter?  I think both
have to be legal for it to work out for the user, otherwise it becomes
difficult to remember.

Then we might get into:

	{1.2, 2.2, 3.3} v+ 18.7

Does the operator change to "fv+" in the second example because all
numbers are floating point?

So long as the operator names are very short (1-3 characters) and
very simple mnemonics for the actual action, I see little wrong with
making new operators.  It just makes Erlang more grotty, like Perl.  :)

Perhaps this goes to some discussion earlier about using guards to
do type checking, and then the compiler being able to get type
information from the guards for later optimization:

domath(Vector, SimpleNum) when vector(Vector), integer(SimpleNum) ->
	Vector + SimpleNum.


More information about the erlang-questions mailing list