On Sun, Feb 15, 2015 at 4:16 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Sun, Feb 15, 2015 at 11:53 AM, Keean Schupke <[email protected]> wrote: >> In this case "fn" would appear to be a comonad? > > That was not my intention. 'fn' here is syntactic noise. In the absence of > some identifier or reserved word to signal the start of the type, parsing > this is a mess. I did not intend anything more complicated than that. I was > simply converting Geoff's syntax above into a syntax that does not have > parse ambiguities.
What is the parse ambiguity? I don't deny that there is one, I just can't tell what it is. Heuristically, it seems like it'd be unambiguous for a similar reason that application is. > I do not believe that > parenthesizing the application is a good choice, because in an expression > like > > ((f a), (g b)) > > where g has arity 1, the programmer cannot tell whether the parens are > forcing a curried call or merely serving to override the usual precedence > rules (in this case, on g, unnecessarily). Offhand, I think I would prefer > some form of operator for this. Is this referring to my proposal? There is no curried call in ((f a), (g b)). In my proposal, parens just group expressions, as usual. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
