Re: Grammar for optional elements

Detlef Meyer-Eltz <Meyer-Eltz@t-online.de>
Wed, 20 Jun 2007 21:49:27 +0200

          From comp.compilers

Related articles
[6 earlier articles]
Re: Grammar for optional elements dot@dotat.at (Tony Finch) (2007-06-17)
Re: Grammar for optional elements torbenm@app-2.diku.dk (2007-06-18)
Re: Grammar for optional elements cfc@shell01.TheWorld.com (Chris F Clark) (2007-06-19)
Re: Grammar for optional elements dot@dotat.at (Tony Finch) (2007-06-19)
Re: Grammar for optional elements lowell@coasttocoastresearch.com (Lowell Thomas) (2007-06-19)
Re: Grammar for optional elements dot@dotat.at (Tony Finch) (2007-06-20)
Re: Grammar for optional elements Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2007-06-20)
Re: Grammar for optional elements cfc@shell01.TheWorld.com (Chris F Clark) (2007-06-21)
Re: Grammar for optional elements dot@dotat.at (Tony Finch) (2007-06-21)
Re: Grammar for optional elements lowell@coasttocoastresearch.com (Lowell Thomas) (2007-06-22)
Re: Grammar for optional elements cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-02)
| List of all articles for this month |

From: Detlef Meyer-Eltz <Meyer-Eltz@t-online.de>
Newsgroups: comp.compilers
Date: Wed, 20 Jun 2007 21:49:27 +0200
Organization: Compilers Central
References: 07-06-019 07-06-029 07-06-045
Keywords: parse, design
Posted-Date: 20 Jun 2007 20:39:43 EDT

>>>I need to create a parser for a language something like this.
>>>
>>>attribute1: value;
>>>attribute2: value;
>>>attribute3: value;
>>>
>>>All the attributes are optional but can occur only once...


> Parsing Expression Grammars are an interesting solution to the
> problem,
> but I don't think this one quite succeeds. In the term


> !(attr* attr1 attr*)


> it is my understanding is that the "*" operator is "greedy" and
> will always consume the entire remainder of the string,


> I would like to suggest an alternative. Using ABNF, which
> differs only slightly in this example in its repetitions and ranges,
> and
> adding line enders for readability of the input string:


> attr1 = name1 ":" value ";" CRLF !suffix1
> suffix1 = *(!name1 any) name1
> any = %d10-127
> CRLF = %d13.10
...


I'm not familiar with ABNF, but I suspect, that adding the line enders
is not only for readability, but is essential for the success of the
example code. Wouldn't a suffix otherwise always consume or at least
look ahead the entire remainder of the string too?




By the way I present a solution with TextTransformer
(http://www.texttransformer.com), using semantic and sytactic
predicates:


{{
int mask = (1 << 1) | (1 << 2) | (1 << 3); // setting the first three bits
}}


// if a bit is still in the mask, test for the according attr
WHILE(mask & (1 << 1) && attr1() ||
            mask & (1 << 2) && attr2() ||
            mask & (1 << 3) && attr3() )
(
        attr1 {{ mask &= ~(1 << 1); }} // deleting the first bit
    | attr2 {{ mask &= ~(1 << 2); }} // deleting the second bit
    | attr3 {{ mask &= ~(1 << 3); }} // deleting the third bit
)
END


attr1 = "attribute1" ":" VALUE ";"
...


In the WHILE-condition the productions attr1, attr2 and attr3 are
tested as look-ahead productions. No semantic code is executed thereby
and no text is consumed.


The bit-wise operators are just new in the TextTransformer 1.3.3.
interpreter, so I liked to play with them. In elder versions you could
use some booleans instead.


Regards


Detlef


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.