[eeps] Proposal for /\ and \/ operators

[Richard O'Keefe]

On 26 Feb 2009, at 10:47 pm, Richard Carlsson wrote:
>  But it is also apparent that this
> notation is not at all obvious to many people, so it would take
> some time for them to get used to it.

There's a thread on the Erlang mailing list about the beauty
of functional languages and how some people just don't get it.
I very nice example of synchronicity.

> If I consider how often I've written my own local definitions of
> min and/or max, it might turn out to be on the order of one in
> three modules. Now, I would have been happier if these functions
> had been built-ins to begin with, but I can live with the current
> situation. It's a bit of a bother, but does it warrant adding
> more operators, if those operators will only occur occasionally

We have no reason to believe that they will only occurr
occasionally.  On the contrary, someone who finds themselves
rolling their own for one in three modules is *already* using
them far more frequently than the lamentable -- operator.
The use of max and min is being artificially depressed by the
lack of a standard notation for them.

Let's not lose sight of the big picture.
The operatIONS are useful, however notated.
We would all benefit from a common notation for them.

Whatever form that notation takes should not break existing
code.  That rules out using 'max' and 'min' as operators,
and makes it tricky (but not entirely impossible) to add them
as built-in functions.  Perhaps "if max/2 and min/2 are not
defined in a module, they are built in; if they are defined,
they're yours, but you will get a compiler warning" might work.

> and will have a good chance of confusing people? Erlang is not
> an operator-heavy language; if it were, I might be less hesitant.

How can you look at bit syntax and say Erlang is not operator-heavy?
Erlang has context-sensitive operators!

Is there _anything_ about Erlang that doesn't "have a good chance
of confusing people"?  The use of '->' for something that is not
implication?  The use of '=' for something that is neither
mathematics' symmetric equality nor Fortran's assignment?  The
requirement to write '=<' rather than '<='?  The use of '==' and
'=:=' as well as '=', where the first two are the same spelling
as Prolog operators, but with the opposite meanings?  The
existence of three different ways to say "and" (the shortest of
which is almost always the wrong one)?  The fact that f == g is
legal when f and g are function names, but doesn't call f or g?
The difference between f(X) and ?MODULE:f(X)?  The fact that
function clauses end with a dot except when they don't?

If we rejected every part of Erlang that might confuse someone,
just about all that would remain would be 1+1.  No, wait, the
full stop at the end is confusing....

>
> Another possibility would be to make the compiler handle the
> existing lists:min/1 and lists:max/1 functions more efficiently
> when the argument is a literal list, as in lists:min([A, B]).

Do that and the lists module is no longer hot-loadable.
This really seems wrong.  It's like defining arithmetic
by appealing to peano:ack/3 and saying that the compiler
will special-case calls that it recognises as addition,
multiplication, or power.  Legend has it that a number of
Prolog implementations got good benchmark results by
having the compiler recognise append/3 under various
disguises so that it could generate special code that
wasn't normally attainable.  This smacks of that.  Why
lists:min([A,B]) and not lists:sum([A,B])?

The point of the EEP is to try to get something that says
DIRECTLY "I want the meet of these two things" (or the join).


Could we reach a consensus on

	erlang:max/2
	erlang:min/2

Callable without the prefix if and only if there is no locally
defined function with the same name?