On Mon, Mar 30, 2015 at 1:28 PM, Keean Schupke <[email protected]> wrote:
> On 30 March 2015 at 14:27, Jonathan S. Shapiro <[email protected]> wrote:
>> I'm less comfortable with using curried types for abstract function types,
>> because there remains this issue of needing to track where required returns
>> occur even while the function type is not yet concretized. This is driven by
>> allocation constraints in BitC, so I'm not sure if it is an issue in your
>> language or not.
>
> I don't see why we need to track that. If the value returned is never used,
> we don't care if its a function, and we certainly don't need to know its
> arity.
Huh? Who says the return value is not used?
So for example, we get some function f from outside the compilation
unit, and we apply it like
f a b
and
f a b c d
And both results are passed to other functions outside the unit. What
type is f, and how do we know that when we specialize these
applications, we don't insert any lambdas? (This is Shap's example.
It's a slightly harder version of apply2.)
I figure f has type ('a->'b->'c->'d->'r) in your system. The problem
is that this seems to have ('a 'b 'c 'd=>'r) as an instance, and we
can't apply that to two arguments without inserting a lambda.
If you have a problem with the type variables, suppose a through d are
integers, and 'a through 'd and 'r are int.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
