On Wed, Feb 25, 2009 at 8:02 AM, Jonathan S. Shapiro <[email protected]> wrote: > The BitC s-expression syntax is now showing a lot of strain. While > s-expressions make a great deal of sense as an expression syntax, they > aren't that great for declarations. The most recent example is that we > wanted to discriminator tag values in unions, and there doesn't seem to be > any graceful way to do it. > > You all know that I've done some preliminary work toward a post-sexpr > surface syntax. Most of it looks straightforward. There are two issues that > I have run into: > > 1. I am having difficulty coming up with a sensible syntax for loops. The > statement-style syntax doesn't seem to lend itself to a functional > (non-stateful) loop idiom. I would appreciate suggestions on this. > > 2. I'm increasingly convinced (however reluctantly) that mixfix is important > in a non-sexpr surface syntax. The problem with this is that (a) there are > no parser generators that seem to support this and (b) writing a parser for > the non-sexpr syntax by hand is probably not the best way to coverge on a > syntax. Once the syntax is stable it's not a problem, but hand-written > parsers do not tend to be easily modified or easily validated. > > Can anyone point me at a parser generator that can be made to handle mixfix, > or suggest some means by which an existing parser generator might be kludged > into service at the semantic actions level? As a concrete example, I have > considered a parse strategy in which the parser builds a list rather than a > tree and the semantic action pass decides how to recover a tree from the > result. Are there examples of this sort of thing being done successfully?
I may be misunderstanding the issue, but couldn't this be solved with a simple feedback loop between the lexer and the parser? E.g., the set of infix expression tokens would be something like INFIX0 ... INFIX100, one for each precedence level. The parser would gradually produce a map from strings to precendence, and the lexer would use the most recent map to produce future tokens. This would work as long as you can guarantee that the lexer doesn't get too far ahead of the parser, and doesn't require any extra intelligence in the grammar. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
