[Prev][Next][Index][Thread]

Re: function signature type checking


"Ray Blaak" <blaak@telus.net> wrote in message
m3vgfvv3sc.fsf@blight.transcend.org">news:m3vgfvv3sc.fsf@blight.transcend.org...
> Kim Barrett <kab@camellia.org> writes:
> > limited(<function>, ...) seems like the right approach.  However, I
think
> > there are people who would dispute that "quite easily".
>
> Things might be easier if signatures are not considered to be functions,
since
> they cannot be executed after all.
>
> This is the kind of thing I would like to be able to do:
>
>   define signature <accumulator> (sum :: <number>; n :: <number>)
>     => result :: <number>;

You don't need anything magic here.  This signature is "just"

  limited(<function>,
             required-parameters: #[<number>, <number>],
             result-type: #[<number>])

Unfortunately, what I just wrote is not enough to do the job, because
there are a bunch of other things to worry about.

>   define method accumulate (a :: <accumulator>; c :: <collection>)
>       => result :: <number>
>     let sum :: <number> = 0;
>     reduce(a, sum, c);
>   end method;
>
>   define constant f = method (sum :: <number>; n :: <number>)
>       => result :: <number>;
>     sum + n;
>   end method;
>
>   accumulate(f, #(1, 2, 3));
>
> These relations would hold:
>
>   instance?(f, <function>)
>   instance?(f, <accumulator>)
>   instance?(<accumulator>, <signature>)

The first two hold using limited(<function>), and the third is meaningless
chaff.

> The type "wierdness" of signatures vs functions comes about with:
>
>   instance?(<accumulator>, <function>) == #f
>   subtype?(<accumulator>, <function>) == #f
>   subtype?(<signature>, <function>) == #f
>
> The supertype of <signature> is anyone's guess.

Again, with limited(<function>), you need not worry about these so much,
because the relationship between a <function> and a limited(<function>)
is completely clear.

> This kind of thing seems (in my ignorance) to be easy to do, mainly
because
> signature matching is an ability already in the compiler. I don't know if
there
> are type classification "gotchas" that such a signature scheme would
cause.
Follow-Ups: References: