[eeps] Multi-Parameter Typechecking BIFs

[Vlad Dumitrescu]

On Tue, Feb 24, 2009 at 10:14, Kenneth Lundin <kenneth.lundin@REDACTED> wrote:
> 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.

FWIW, I was just thinking about the same thing. But I think the right
thing to use is not -spec, but -type.

-spec is global for a function, while what we need is an annotation at
the clause level (because the generated guards depend on the clause's
patterns, obviously)

"The Right Way"(tm) to handle types in a language is by including the
type description in the language itself.

So if we have a -type specification (extended so that it can handle
"{X, Y} when X<Y" and such), let's say
  -type(date(Y, M, D), is_integer(Y), etc...
then we would like to be able to write
  ..., {Y, M, D}, ... when is_date(Y, M, D)
and get the pattern match and clauses inlined.

We can alternatively have
  -type(date({Y, M, D}), is_integer(Y), etc...
and
 ..., {Y, M, D}, ... when is_date({Y, M, D})
but the former is more flexible and should be allowed because it can
also be used for example in the case of
  ..., Y, M, D, ... when is_date(Y, M, D)


Quick quiz: what does this usage of -type remind you of?
Hint:   ..., {Y, M, D}, ... when '#date'(Y, M, D)

Yes, this is yet another useful application for abstract patterns!

So what we would need for this is:
- implement APs. I'm not sure if a full implementation of APs is
needed for this, I think it's sufficient with the deconstruction
patterns.
- allow APs in the guards (I think this isn't mentioned in the paper)
- compile -type specifications to APs

Could that be something that both works and pleases everybody? [*]

best regards,
Vlad

[*] According to a Murphy law corrolary ("Price, speed, quality. Pick
two") there is still something important that this suggestion will
fail at fulfilling... I'm curious to find out what that is :-)