On Tue, Feb 24, 2015 at 1:23 PM, Jonathan S. Shapiro <[email protected]> wrote:
> On Mon, Feb 23, 2015 at 3:57 PM, Pal Engstad <[email protected]>
> wrote:
>
>> So, it all boils down to if we have enough information at specialization
>> time. But note that if a function takes as arguments or return value
>> general-arity functions, we will not be able to get complete information. I
>> think this is the crux of the matter as it stands. I am not convinced that
>> we can solve this problem without resorting to disallow general-arity
>> functions as arguments to functions.
>
>
> It's a good thing you are wrong! :-)
>
> What you say is true in the same sense that we don't know the type of x in:
>
> def id x = x
>
> We know it's some abstract type, but not the concrete type. However, any
> particular application of /id/ will ultimately specialize to a fully
> concrete type. Parameters having function type work the same way.
I think the getFoo example shows that this is not exactly the case (in
SML anyways)
that is the return value of getFoo returns a partially specified type,
and we only get a fully concrete type when calling the function
returned by getFoo. The consequences are really the same though from
any particular application of getFoo we must be able to infer a fully
concrete type. I'm not exactly sure if there is anything in bitc that
would allow a partially specified type though.
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
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
