On Tue, Feb 17, 2015 at 12:06 AM, Jonathan S. Shapiro <[email protected]> wrote:
> On Mon, Feb 16, 2015 at 12:54 PM, Geoffrey Irving <[email protected]> wrote:
>>
>> On Mon, Feb 16, 2015 at 12:49 PM, Jonathan S. Shapiro <[email protected]>
>> wrote:
>>
>> >
>> > In this scenario, we have adequate information at the definition site
>> > and in
>> > the written form of the type to determine what the arity must be, but we
>> > do
>> > NOT have enough information at the application site. Given a procedure:
>> >
>> > def perverse f a b = f a b
>> >
>> > we cannot determine whether f has type fn 'a -> (fn 'b -> 'c) or
>> > alternatively has type fn 'a 'b -> 'c
>>
>> It might be reasonable to extend this as you say to support automatic
>> conversion, but it does introduce a weird asymmetry where *fewer*
>> arguments are disallowed but *more* arguments are fine. If more is
>> fundamentally easy to implement and understand, while fewer is not,
>> this asymmetry might be reasonable, but it seems odd.
>
>
> I'm not seeing that. However the application is parenthesized due to arity,
> the number of arguments present still must satisfy the function type.
I actually ran into this in SML by currying its record field access thing...
#a {a=1};
fun getFoo(field) = fn record => field record;
let val x = {a=1,b=2};
val y = getFoo(#a);
in () end
val getFoo = fn : ('a -> 'b) -> 'a -> 'b
foo.sml:2.1-4.10 Error: unresolved flex record (hidden)
type: {a:'Y; 'Z}
let val x = {a=1,b=2};
val y = getFoo(#a);
in y x end
val getFoo = fn : ('a -> 'b) -> 'a -> 'b
val it = 1 : int
that is the getFoo only has a partial view of the type {a:'Y; 'Z}
and so cannot know about the type unless it gets called, the solution
was to either not do this, or pass in a dummy value that calls the
returned function at the time that getFoo(#a) is called...
which i find intriguing because it allows me to write code with only a
partial understanding of the type.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
