[eeps] Multi-Parameter Typechecking BIFs

[Richard O'Keefe]

There is a major defect in the idea of things like
	func({_,X::float,_,Z::float}, [{_,Y::float,A::float} | _]) ->...

I'm finding it astonishingly difficult to explain, but it's
very important.  The thing is that it misrepresents a relation
between a collection of variables as a property of each variable
separately.  This is one of the things that guards get right;
they make it plain that the *whole* head has to satisfy some
relationship.

Take again the very common case of "this argument is an
{M,F,A} triple".

Right now, people write out, every time,

	f(...{M,F,A}...)
	when is_atom(M), is_atom(F), is_integer(A), A >= 0
	-> ...

Writing this as

	f(...{M::atom,F::atom,A::integer}...)
	when A >= 0
	-> ...

(A) Makes it much much harder to *see* the triple.
(B) Splits the condition on A into two pieces, one of which
     can be written as an inlined type test and the other of
     which cannot.  Yes, this can be fixed, but I have never
     yet seen it done readably.  Without some such extra
     complexity, the effect on programmers is to encourage
     them to write less precise conditions.
(C) Kicks abstraction in the teeth, beats it in the head with
     an iron bar, and steals its notecase.  Where does it say
     {M,F,A}::names_a_function?  This is a very very low level
     way of describing what you want.

What we want, of course, is to say that the *whole* triple
satisfies a named condition.  And we can do that, right now,
with macros.

	-define(mod_func_arity(M, F, A),
	    is_atom(M), is_atom(F), is_integer(A), A >= 0).

	f(...{M,F,A}...) when ?mod_func_arity(M,F,A) ->

>  With inline (type) guards there would be no rationale for James' EEP.

Thanks to macros, there isn't right now.
Abstract patterns would be better, but macros *can* do the
job of naming *relations* to be used in guards.
>
>
>> Inline guards are not intended to replace the standard guard syntax,
>
>  Type checking in standard guard syntax would be obsolete, and could
>  (should, in the long run) be removed.

Guards are good.  I have had the misfortunate to have to read
"Prolog" code written in a dialect that allowed type tests in
patterns.  Never again.