Taking this to a different subject line... On Tue, Mar 3, 2015 at 6:51 AM, Keean Schupke <[email protected]> wrote:
> > > On 3 March 2015 at 14:30, 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. >> >> 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. >> > > What are your requirements for the parser? > > You would think that would be easy to answer, wouldn't you. Generally: LR(1) or LL(1), with the customary "shift over reduce" ambiguity resolution convention. I would consider (reluctantly) a PEG parser. I no longer remember what caused the ambiguity when I tried to do curried application in Bison. It's probably irrelevant, since expressions are now handled in the [dynamic] mixfix parser in any case. I'm not saying it's a big problem. I'm saying I got bit on it once in a way I can't quite remember. We'll burn that bridge when we get to it. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
