On Sat, Feb 14, 2015 at 9:36 PM, Matt Oliveri <[email protected]> wrote:
> So I guess what you're saying is to use tuplized functions at module > boundaries. Then > > On Sat, Feb 14, 2015 at 2:35 PM, Keean Schupke <[email protected]> wrote: > > > > On 14 Feb 2015 16:39, "Jonathan S. Shapiro" <[email protected]> wrote: > >> > >> On Fri, Feb 13, 2015 at 12:35 PM, Keean Schupke <[email protected]> > wrote: > >>> def f (g : 'a -> 'a -> 'a) x = g x > >> > >> > >> Note that all you have for g here is it's type, which (per your desire) > >> does not convey arity. We know enough to apply g to x. We don't know > enough > >> to know whether that application allocates or not. This is true because > we > >> don't have enough information to know whether it is a partial > application. > > > > We know the native arity of 'g' from the module import statement. > > Which module import statement? g is not imported from another module, > it's a local parameter. If you mean other modules' imports of f, then > what is f's inter-module type so that it knows the native arity of its > argument? > Exactly. The fact that g is a parameter was critical to my example. I certainly understand that if we can statically resolve the identifier to its definition, we can infer arity independent of type.We need to design rules for that, and assign a calling convention, but it can be done. In this case, I intentionally used a variable - g - that *cannot* be statically resolved. We have absolutely no idea where g comes from. We know it's type, but since Keean proposes that arity should not be associated with type, we are explicitly *denied* knowledge of its arity. The ocmpiler does not know how to call this function, in the sense that it does not know it's calling convention. Worse, the compiler is unable to determine which invocations will allocate and which will not. Relying on a statically visible definition for arity inference is not sufficient to let us determine arity in all cases. > 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? That is an interesting point. In effect, Keean seems to be suggesting that he will admit arity awareness, but only when dealing with "foreign" functions, whose import only occurs at module top level. Offhand, I think his proposal inadvertently relies on the fact that C does not have first-class functions. If we were importing from a language that did, then given import 'otherLang' (int32, int32) -> int32 -> int32 as {whatever} I *still* don't know the native arity, because I don't know which of those arrows constitutes the "natural" procedure return. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
