On Wed, May 13, 2015 at 7:38 AM, Jonathan S. Shapiro <s...@eros-os.org> wrote:
> type Parser<'TResult, 'TUserState> = CharStream<'TUserState> -> > Reply<'TResult> > > But there is nothing magical about this definition. While the developer > *can* introduce new compositing operators, they typically do not do so. If > we take the list of compositing operators as non-extensible, I guess i'm not sure how mixfix fits into this, It seems like with mixfix you'd want to check for ambiguity at the time the parser is compiled, but then also at the time when the mixfix operators have been collected? does mixfix not fall into this realm of /they typically do not do so/, or maybe its just a case of reserved words are used in such a way that mixfix cannot introduce an ambiguity, anyhow it isn't clear to me, but it seems being able to extend ambiguity checking post-parser generation is one way to go about it. _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
