Jonathan S. Shapiro wrote: > Sorry. Couldn't resist that subject line. > > Okay. It's emerging that n-ary functions and curried-style application > syntax do not get along. It impacts both type declarations and > function application. The issue is that given: > > f1 a f2 . b > > the parser can't figure out whether this is (f1 a (f2 b)) or (f1 a f2 > b). This cannot be resolved with associativity rules in most parsers, > because most parser generators only have a notion of associativity for > tokens.
Support for associativity/precedence declarations in a parser is just a convenience; anything that can be done with them can also be done without them by using an operator precedence grammar. This kind of grammar is uglier if separate productions are used for every precedence level (see the ECMAScript spec for an example), but that shouldn't be much of a problem if you are only doing it to work around lack of parser-supported precedence/associativity for a whitespace "apply" operator. -- David-Sarah Hopwood ⚥ _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
