[Prev][Next][Index][Thread]
Re: function signature type checking
>From: Kim Barrett <kab@camellia.org>
>At 1:45 PM -0500 11/26/01, Andreas Bogk wrote:
>>Ray Blaak <blaak@telus.net> writes:
>>
>>> It seems that the right way is to declare the type of the parameter or result
>>> to be <function>.
>>> Is there a way to further specialize this?
>>
>>No, there isn't.
>>
>>I think it could be added to the language quite easily using
>>limited(<function>, ...). The question is whether it would be worth
>>the trouble.
>
>limited(<function>, ...) seems like the right approach. However, I think
>there are people who would dispute that "quite easily". Several people at
>Apple and Harlequin (and maybe CMU too, I don't remember off hand) spent
>some time working on this, because it seemed like a serious hole in the
>Dylan type system. However, it seemed that every attempt at a specification
>got arbitrarily hairy around variadic parameter lists and return types.
>I have memories of a whiteboard densely covered with small print purporting
>to describe all the possible permutations...
You might be recalling my whiteboard -- I certainly recall writing lots of fine
print and staring at it with you, anyway. All the cases for limited <function>
types had to be worked out, since the Harlequin compiler at that time used this
internally for type inference purposes. I think Gail might have written a
proposal on this subject while still at Apple, too.
As I recall, it was hairy for reasons to do with all the combinations of #key
args, #all-keys, #rest args and the various multiple-value returns. It wasn't
fundamentally difficult, just that there were a lot of cases to go through (on
the order of 30 or so?).
Also, the covariance/contravariance rules were simple, but tedious to explain.
<type-estimate-limited-function> and the associated type algebra were in the
Harlequin compiler ca 1998.
>If someone is really interested in pursuing this, I could probably be
>persuaded to dredge up any discussions I have archived.