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. We're going to need to, because we require that hidden function type for purposes of specializing our generics. Including, mind you, any variables having function type, because those need to be monomorphic w.r.t. both the "true" type and also the "shadow" type. 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
