Questions about block parsing
[1/3] from: rudolf::meijer::telenet::be at: 21-Sep-2007 9:18
I was inspired to write this post by the following exchange: [REBOL] Re: rebol yacc parser generators From: greggirwin::mindspring::com at: 18-Apr-2002 10:46 Hi Bryan, << I'm wondering if there are any parser generators out there for rebol, something on the line of yacc? also is there any parser written in rebol for understanding asn.1? >> Have you played with the PARSE function at all? That's where you should start, and it might be where you stop. Who needs YACC? :) --Gregg I started to test REBOL block parsing as a tool for building a parser generator for REBOL dialects. In a first instance I want to convert the syntax rules for a language (of course this should be a REBOL dialect) into a set of rules for block parsing a string of the language (converted into a flat block of REBOL values) with actions added for creating the syntax tree of that string (in practice a nested block structure) to show how the parse went. To this end I started simply with inserting a diagnostic call to the ALERT function after each alternative of the rules. I noticed from the output that the way block parsing works is that all alternatives are tried until the first one is found that succeeds, and this recursively depth first. How then can we know during the visit of an alternative that this will end up being successful? It looks like we need a stack of our own to keep track. Any experiences? I have seen posts on string parsing, but I think this is still different. Furthermore, in order to add some semantic analysis to the parsing, I would like to be able to tell the parse function that a certain alternative should NOT succeed. Is there any way of communicating TO the parser while it goes on? Thanks for any insights and experience. Rudolf Meijer
[2/3] from: anton:wilddsl:au at: 21-Sep-2007 17:51
Hi Rudolf, Yes, I think you need a stack. I used a stack with parse some time ago. To cause a fail, we use the rule: end skip which can never succeed. So put that after the alternative you want to fail. Regards, Anton.
[3/3] from: robert::muench::robertmuench::de at: 21-Sep-2007 11:13
On Fri, 21 Sep 2007 09:18:39 +0200, Rudolf W. MEIJER <rudolf.meijer-telenet.be> wrote:
> I noticed from the output that the way block parsing works is that all > alternatives are tried until the first one is found that succeeds,
Hi, no, that's not true. The alternatives are checked top-down, hence I used the term "maximum match rules first" because the chances that a generic rule is true is much hier than a more specific one.
> How then can we know during the visit of an alternative that this > will end up being successful? It looks like we need a stack of our own > to keep track. Any experiences? I have seen posts on string parsing, but > I > think this is still different.
If you reach the end of a rule the rule is successful. You can't decide up front and you don't need to. PARSE works a bit different than normal parser generators. But it's extremly powerful and not that hard to understand.
> Furthermore, in order to add some semantic analysis to the parsing, I > would like to be able to tell the parse function that a certain > alternative > should NOT succeed. Is there any way of communicating TO the parser > while it > goes on?
This looks to me that you should try to seprate these. Remember, it's sometimes much simpler to use 2 or 3 PARSE in sequence. So, first parse on a high level, than take the result and parse it again with some more specific rules etc. This is sometimes simpler than writing one big rule. Robert