On Tue, Mar 31, 2015 at 1:06 AM, Jonathan S. Shapiro <[email protected]> wrote: > One of Matt's points in advocating AFN is that if the developer writes an > *explicit* arrow type, The fact that it's an afn has the effect that the > return position is *required*, and that no further specification of the 'ret > type can remove that call/return position. In that view, we simply *can't* > write the type a->b, but must instead write a=>b. > > Now if we adopt that view, then the whole concern about arrow types > "expanding" on the right goes away. In fact, the need for => can be made to > go away. The alternative is to simply say that given a type: > > a->b->c->'ret > > we should understand it as an afn type where the *last* arrow is interpreted > as a =>, and the 'ret is understood to be wrapped in elided parenthesis. The > parenthesis can be elided so long as 'ret is not an arrow type. So in this > view, if 'ret turns into e->f, we'd rewrite as > > a->b->c->(e->f) > > and the parens are actually semantically significant. I'm not advocating any > of this. I'm simply saying that we could abuse existing notation to mean > what we need. > > If we try to unify a->b->c->'ret with a->b->'ret, we would get > a->b->(c->'ret), which is consistent with what we've been saying before. > It's equivalent to what I have previously written as a->b=>c=>'ret. > > The rule that the rightmost thing is understood as parenthesized also > resolves what happens when programmers write these types explicitly.
I understood what you were saying, FWIW. But Keean says he really meant plain old HM arrows. >> I disagree, I don't care if a function returns a function, as long as I >> have enough arguments to make the call. > > You do care, because you can end up with **too many** arguments. Given > > f a b c > f a b > > you really need to know that f can be called without a closure construction > given only two arguments. You need to know this without yet knowing the > concrete arity of f. Heh, I challenged Keean with essentially the same example. If he replies to you, I'll let you two work it out. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
