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. Given the problems I had with it in the BitC v0 parser, I'm not yet convinced that I can get the parser to accept the curried-style application syntax. It's a PARSE problem, not a type problem. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
