On Wed, Apr 1, 2015 at 10:19 AM, Matt Oliveri <[email protected]> wrote:
> > So by my reading Shap and I abandoned thinking about mixed arrow > notation as actually being binary type constructors, even though they > look like they are. The problem is that (int -n-> int) is a weird > type. It's a "function", but you can't call it, because one arg isn't > enough, but it cannot take more than one either. Yes and no. I agree that once -n-> is added to the picture we can no longer simply think of multi-arrow types as a shorthand for nested simple arrow types. But that said, many of the processing behaviors in the type inference and checking mechanisms can still follow the simple arrow intuition. Shap decided that trying to be careful > about how types get instantiated--to avoid things like (int -n-> > int)--wouldn't work well, so we now think of function types as being > grouped based on the known call arrows, and a function type whose > final arrow isn't a call arrow is not expressible. shap is definitely concerned about this issue, but I wouldn't say that I've "decided". Rather, it's on my list of things that need to be considered in the final choice of surface syntax. The main thing is that we have the issue thoroughly identified and the solutions characterized. How we spell the result isn't all that important. :-) But I thought of a simple-minded alternative. We could just consider > types like (int -n-> int) to be undefined. They have no intro or elim > rules. There's no need to avoid them, but they're basically useless. > Would you prefer binary arrows with silly ones to afn-like grouping? I'm torn. I don't like the AFN syntax at all, but I'm concerned that if we re-purpose the arrow notation then the result will be confusing to people coming from Haskell, O'Caml, or F#. This seems like a social design issue rather than a technical design issue. I think we need to get the technical issues wrapped up first and then put up a list of candidate concrete syntax approaches to choose from as a separate matter. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
