I thought the fn was needed to differentiate from a polymorphic type like 'm 'a -> 'a
Where m is for example a monad? (I used comma's for this which would be an infix argument combinatorial): 'm, 'a -> 'a But this: fn 'm 'a -> 'a Seems okay, except you have to disallow any user datatype being called 'fn'. I'm not too keen on this because it is neither a prefix nor infix operator, but something else. It's not a strong objection however. Keean. On 17 Feb 2015 06:44, "Geoffrey Irving" <[email protected]> wrote: > On Mon, Feb 16, 2015 at 10:32 PM, Matt Oliveri <[email protected]> wrote: > > On Mon, Feb 16, 2015 at 5:59 PM, Keean Schupke <[email protected]> wrote: > >> Are we saying arrows only take one left parameter and one right, so they > >> remain a binary operator on types, and that 'fn' builds an "argument > pack", > >> like this: > >> > >> (fn a b c) -> d > > > > The "fn" is just a meaningless keyword, Keean. It doesn't do anything > > but help the parser find the beginning of the type expression. We are > > not applying arguments to some mystical "fn" entity. In particular, I > > suspect it would be a syntax error to parenthesize it like you did > > above. > > > > I think the "fn" is really ugly and I'd like to talk about whether > > it's needed, and if so, what we can do instead. > > I don't believe "fn" is needed in terms of grammar ambiguity. It > doesn't generate ambiguity in terms of general CFGs, and even if we > were to restrict ourselves to a LALR(1) parser the "a b c -> d" syntax > can be parsed by treated it as arity 1 and then unwrapping any bare > juxtapositions on the left hand side. > > Whether it is desirable to have out of the box LALR(1) for purposes of > human readability is a different question. I slightly prefer the > non-fn version, but it seems mostly a question of personal preference. > > Geoffrey > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
