On Sun, Feb 15, 2015 at 1:47 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Sun, Feb 15, 2015 at 12:59 AM, Matt Oliveri <[email protected]> wrote: >> >> >> Anyway, how is this business of using different inter-module types any >> >> better than using an arity-aware type system for compiled modules, or >> >> automatically tuplizing functions under the hood? >> > >> > Hmm, the type system is arity aware, the exact arities are encoded in >> > the >> > types using tuples. >> >> OK, I can use that point of view. The comparison I was asking for is >> essentially the same, whether you use arities or unboxed tuples under >> the hood. > > Tuple-based encoding remains ambiguous, but we can certainly find *some* > encoding that will work. > > My problem here is that now we seem to be carrying a "true" function type > and a "hidden" function type. Not just for function definitions, but also > for variables, fields, and parameters of function type.
Good point. But still, this is how F# basically works, no? The hidden type is the CLI type. When the original F# type cannot be unambiguously determined from the CLI type it compiled to, we need to remember it too. > And won't it seem damned strange when a > variable > > f_var :: int -> int -> int // having shadow type with arity 2 > > is not assignable from a function > > f :: int -> int -> int // having shadow type with arity 1 > > Arity can't be hidden this way unless we start introducing shadow coercions. > Shadow coercions are typically allocating, and it's absolutely not OK for > assignment to entail an allocation. Very good point. This does seem to be a problem for Keean's proposal. I guess F# handles this by not mapping such different types to the same CLI type? Or what? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
