On Fri, Mar 20, 2015 at 1:23 PM, Matt Oliveri <[email protected]> wrote:
> On Fri, Mar 20, 2015 at 1:10 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > > I agree it's weird, but that's not *quite* what I'm saying. I see the > point > > you are making, and I agree with it. My qualifier is that there are > *other* > > things that can cause it to be instantiated. E.g. if > > > > a-?->b > > c=>b > > > > unify for some reason, then it's okay to fix the variable. More > generally, > > it's okay to fix the variable to "does-return", without knowing the > return > > type, but not necessarily okay to fix the variable to "does-not-return". > > Which makes sense, because that arrow might, in fact, return. > > Right, basically we would need some restrictions to prevent ('a-n->B) > from arising, where B is a concrete, non-function type. Because that > type is nonsense. To me this is a symptom of bad type syntax. > Perhaps. But if so, then I think that the bad type syntax lies in the multi-arrow function type notation. The source of the problem is that the "length" of the type (the number of arrows) is indeterminate until the final rightmost type variable is specialized. > > But another way to look at it might be that 'a -n-> 'b tells us that 'b > > *must* be a [multi-]arrow type that eventually includes a constituent => > > arrow somewhere. That is: the existence of a -n-> arrow is effectively a > > constraint requiring that some return must occur somewhere to the right > of > > that same arrow. > > I suppose that perspective is workable, but I really don't like it. > What's so bad about afns, which avoid this issue entirely, that you'd > rather invent a new kind of constraint? > I haven't considered afn's at all yet. At this point, I'm trying to wrap my head around the issues. I'm planning to look at afns, but I find that I internalize things best when I think about one alternative at a time. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
