Pal: Good summary. On Mon, Feb 23, 2015 at 3:57 PM, Pal Engstad <[email protected]> wrote:
> Shapiro has pointed out that function definitions has to be concrete, > since we’re interfacing with foreign modules of which we have no control. > That is one reason, but not the most important reason. The most important reason is that the choice of arity dictates the conditions under which an application may need to allocate a closure. Programmer decisions about allocation are prescriptive, not elective. In consequence, the programmer's declaration of arity is prescriptive unless we can show that a change at a given allocation site does not lead to an allocation that did not previously exist. > Throughout the discussion, there’s been misunderstandings due to the > relationship with subtyping. Subtyping in this context (arity subtyping) is > a little unusual, in that it does not come up in most languages. In order > to be able to sub-type, the compiler has to be able to use a value of a > type that is a sub-type of another. So, for instance, if the compiler > allows turning an x:uint64 to a float64, and sqrt: fn 1 float64 -> float64, > then `sqrt x` is sound, since we can “cast” uint64 to a float64. We say > that uint64 <: float64. > I agree that it's unusual, and this is one reason that I haven't framed the arity issue as a subtyping issue. I think it's cleaner to view it as an inequality constraint. But I could be convinced. > So, it all boils down to if we have enough information at specialization > time. But note that if a function takes as arguments or return value > general-arity functions, we will not be able to get complete information. I > think this is the crux of the matter as it stands. I am not convinced that > we can solve this problem without resorting to disallow general-arity > functions as arguments to functions. > It's a good thing you are wrong! :-) What you say is true in the same sense that we don't know the type of x in: def id x = x We know it's some abstract type, but not the concrete type. However, any particular application of /id/ will ultimately specialize to a fully concrete type. Parameters having function type work the same way. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
