On Mon, Mar 30, 2015 at 10:08 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Mon, Mar 30, 2015 at 4:17 AM, Keean Schupke <[email protected]> wrote: >> On 30 March 2015 at 11:50, Matt Oliveri <[email protected]> wrote: >>> On Mon, Mar 30, 2015 at 2:54 AM, Keean Schupke <[email protected]> wrote: >>> > As such the function concretization pass only has to deal with fully >>> > determined arity abstract types. >>> >>> What exactly is fully determined about an arity-abstract type, whose >>> arity is--by definition--not yet determined? >> >> IE we know the whole type: >> >> a -> b -> c >> >> where c cannot be further expanded to (d -> e). > > Oh. Oh dear. I think you have a bad assumption. Even if we are doing > assembly-grain compilation, there are cases where we cannot know this. In > particular, we may be a consumer of a function supplied by some other > module/assembly whose type is 'a->'b->'c. In that case we don't know any > restriction on the potential expansions of 'c.
Although Keean didn't say this, maybe what he has in mind is to specialize all the type variables before doing any arity specialization. So he's assuming some concrete types a, b, and c, where c is not a function type. Then (a -> b -> c) is a pattern you could match against concrete types. Here, "concrete" means no type variables, but still possibly arity-abstract function types. But the type system still doesn't seem to be capturing the constraints on grouping arguments into calls. It's not clear how this system handles either apply2 or choose_one. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
