On Sun, Feb 15, 2015 at 10:47 AM, 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. 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.
Looking over this discussion, I'm quite partial to Matt's solution, summarized as (correct me if I'm wrong): 1. Parse "f x y z ..." with n+1 juxtaposed terms as an arity n function applied to n things. 2. Require parentheses to indicate fancier arity. "(f x y) z" means f has arity 2, "f x y" has arity 1. 3. Ban nullary functions in favor of arity-1 functions taking an empty tuple, or similar. 4. Types would probably look like "x y z -> w"? No hidden types, easy to read off the arities from the code, no frightening type inference fanciness required. It requires a few more parentheses than Ocaml/Haskell, but strictly less than C, and the extra parentheses convey information about weird arities. The calling convention for nullary functions can match C if we treat zero-size types appropriately. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
