On Tue, Feb 17, 2015 at 9:52 PM, William ML Leslie < [email protected]> wrote:
> My concern, Shap, is that there are some cases where template > instantiation falls down, and one of those cases is where the meet > operation or let-polymorphism or branching does not adequitely describe the > property you're trying to maintain. > I do see why meet operations are a concern. As a concrete example, one could have two different return statements whose expressions have the same arity-abstract type but distinct arity-concrete types. How big a concern this should be seems like something we can only determine empirically. I suspect it's rare. On 18 February 2015 at 02:03, Jonathan S. Shapiro <[email protected]> wrote: > >> On Mon, Feb 16, 2015 at 2:57 PM, William ML Leslie < >> [email protected]> wrote: >> >>> I'm a bit uncomfortable with what happens in the case of let-bound >>> native-arity-polymorphic case: >>> >>> let f = choose_one x y z -- different arities >>> in f n m >>> >>> How do you choose a native arity for the callsite? >>> >> >> In a sense, you don't. The arity of f is determined at its definition. In >> this case, I cannot tell what it is, because I don't know what the return >> value of choose_one is. But it cannot depend on the dynamic branch taken in >> choose_one, because this isn't a lazy language. >> > > Please: native arity. The arity of f is 2. > OK. I see now why this confused me, and I thiink you are wrong about the native arity. Based on the "f n m" expresion, we can only infer 'a -> 'b -> 'c, which is an abstract arity. The concrete arity, in this case, is going to be determined by the return value of "choose_one". I can't see what that is, so I cannot determine the concrete arity of /f/ here. It certainly *could* be fn 'a 'b -> 'c but it could equally well be fn 'a -> (fn 'b -> 'c) Thus my statement that I don't think I have enough information to determine the concrete arity of /f/ in your example. > choose_one returns one of its arguments; and perhaps x has a curried > definition and y takes two arguments directly. They have the same type, of > course, so this is a perfectly reasonable thing to do. > This is incorrect, because that is *not* a reasonable thing to do. They have the same type. Therefore they are required to have the same concrete type, therefore the same arity. > But then what instructions do I emit to call f? It may need to be > called twice or once, how do we tell? > > The only reasonable answer is that choose_one makes a choice of arity for > you. But I can't figure out by your rules which arity it will choose. > Either x, y, and z will specialize to the same concrete arity, or the expression will fail to type check. > Simply propogating the native arity of the original function couldn't > work, because the native arity of the selected function depends on a > runtime value. > You say this because you are making different assumptions about the unification of concrete types than I am. But your question above was written before I sent out the "new and [allegedly] improved" description of behavior. Before I dig into this further, is it possible that email has answered your question already? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
