On Tue, Mar 3, 2015 at 9:30 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Mon, Mar 2, 2015 at 2:05 PM, Matt Oliveri <[email protected]> wrote: >> >> > I certainly don't want to. What I can convince the parser to accept >> >> > f a b c >> >> > as >> > non-ambiguous syntax remains to be seen. >> >> I don't think this is a parsing issue. (f a b c) would infer you a type >> for f: >> fn 'arity 'a->'b->'c->'d >> which unifies with >> fn 1 'a -> fn 1 'b -> fn 1 'c -> 'd > > Please explain how the type unification rules have any bearing at all on > what the parser can be made to *parse* as an unambiguous syntactic > construct.
I guess I misunderstood. I thought Keean's question was whether we'd be able to use either (((f a) b) c) or (f a b c) to apply an (fn 1 'a->fn 1 'b->fn 1 'c->'d), for semantic reasons. My explanation was why I think the intended answer is yes. Of course you are right that we need to be able to parse it first. But since arity specialization doesn't seem especially helpful for programmer convenience if we still can't write curried-looking applications, I didn't think you really meant that "f a b c" might not be parseable. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
