[eeps] Multi-Parameter Typechecking BIFs

[Kenneth Lundin]

Let us sum up what we have here:

We have the current way of writing:

foo(_,{A,B,C},_) when is_integer(A), is_integer(B), is_integer(C) -> ...

Proposal 1)
Whe have a proposal from James that it should be possible to write like this:

foo(_,{A,B,C},_) when is_integer(A, B, C) -> ...

The reasoning behind this is to make the code shorter and clearer by
reducing the number of times the type guard
has to be repeated.

Proposal 2)

We also have the counter-proposal from Mats which introduce the possibility
to embed the type checking guards within the pattern. Note that it is
not suggested that
everything that can be expressed in guards should be moved into the pattern.
I have myself suggested the same thing with a slightly different
syntax a couple of years ago.

The reasoning behind this is to make code shorter and clearer by
reducing the number of times a variable name
has to be repeated. Encourage the use of type guards by making them
easy to write.

foo(_,{A::integer, B::integer, C::integer},_) -> ...


Now the examples above illustrated the different syntaxed with one
letter variable names. Mats point which seems to be misunderstood is
that "real programs" tend to have mnemonic names for the variables
with a common length of say
5 to 10 characters. Lets take the examples again with realistic variable names.

Current situation)

foo(_,{Width,Height,Depth},_) when is_integer(Width),
is_integer(Height), is_integer(Depth) -> ...

Proposal 1)

foo(_,{Width,Height,Depth},_) when is_integer(Width, Height, Depth) -> ...

Proposal 2)

foo(_,{Width::integer, Height::integer, Depth::integer},_) -> ...


It may very well be so that there are weak point in proposal 2 but I
don't buy the arguments that
Richard have against it. For me it seems that he has looked himself
into one view and refuses to see
the problem from another angle. Maybe there is also a misunderstanding
in that everything currently expressed in
the separate guards should be moved into the pattern and that is NOT
what is suggested.

On very valid reasoning behind Proposal 2 apart from the short
notation is that it is more important to avoid repeating
variable names since they are just "variable" and making them more
difficult to remember and spell than the well known
"fixed" names of the type guards which can be seen as part of the language.
Because of this it is more important to avoid repeating variables than
is is to avoid repeating type guards.

Another reasoning with Proposal 2 is that today some  types can easily
be expressed in the pattern while other can not.
It is for example easy to match:
 a list  like this [_|_]
 a 2-tuple like this {_,_}
 a 3-element list like this [_,_,_] etc. directly in the pattern
but not possible to match any integer or any float (only specific ones).


I think that Proposal 2 is far better than Proposal 1 from James and
we should either go for Proposal 2 or not
take any of these suggestions.

A third proposal could perhaps be to take advantage of the newly
introduced -spec syntax and making it possible
to tell the compiler to generate runtime guards according to the
-spec, but that is just a wild idea that for sure
has it's own problems. But I think it is in the right direction since
we want to avoid writing/expressing the same thing
many times and in different ways.

/Kenneth, Erlang/OTP Ericsson