Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Writing a Parser

Reply
Thread Tools

Writing a Parser

 
 
Cesar A. K. Grossmann
Guest
Posts: n/a
 
      06-29-2004
Hi

I'm trying to build a parser for a file I create. The file format is as
follow:

IDENTIFIER = NUMBER STRING STRING;

COMPOSITE = STRING { ITEM [, ITEM, ...] };

ITEM = NUMBER IDENTIFIER|COMPOSITE

A file example is as follow:

eggs_with_bacon = 1 { 2 eggs, 1 bacon_strip };
eggs = 0.02 "Egg" "Unit";
bagon_strip = 0.04 "Bacon strip" "Unit";

(My idea was to use it as means to calculate costs of buildings, so you
can detail it to the level of bricks and mortar, and get the total price
of the building, but it can be used as a means to calculate any kind of
costs).

I have already started building a parser, using bison/flex, with rules:

(flex rules)

[[:digit:]]+("."[[:digit:]]*)? return NUMBER;
[:alpha:][[:alnum:]_]* return IDENTIFIER;
\"[^\"]\" return STRING;
\= return EQUAL;
\{ return LBRACE;
\} return RBRACE;
\, return COMMA;
\; return SEMICOLON;
^#.*\n$ /* eat comments */
[.\n]+ /* eat this */

(end flex rules)

(bison rules)

line: /* empty */
| line description;

description: short-description
| long-description;

short-description: IDENTIFIER EQUAL NUMBER STRING STRING SEMICOLON;

long-description: IDENTIFIER EQUAL NUMBER LBRACE items RBRACE SEMICOLON;

items: item
| items COLON item;

item: NUMBER IDENTIFIER;

(end bison rules)

I added some dummy actions to the bison rules, just to debug it, and I'm
getting "parse error" after the first line is parsed. I think there are
something I'm missing, the parser should get to state 0 after reading
the first rule, but it is going to other state, and gives the 'parse
error'. Can someone tells me what is wrong with the rules?

TIA
P.S.: Sorry for the "engrish".
--
..O. Cesar A. K. Grossmann ICQ UIN: 35659423
...O http://www.LinuxByGrossmann.cjb.net/
OOO Quidquid Latine dictum sit, altum viditur
 
Reply With Quote
 
 
 
 
Case
Guest
Posts: n/a
 
      06-29-2004
Cesar A. K. Grossmann wrote:
> Hi
>
> I'm trying to build a parser for a file I create. The file format is as
> follow:
>
> IDENTIFIER = NUMBER STRING STRING;
>
> <snip>
>
> (flex rules)
>


I must admit that Flex is great, but in this newsgroup C rules!

Case

>
> <snip>


 
Reply With Quote
 
 
 
 
Cesar A. K. Grossmann
Guest
Posts: n/a
 
      06-29-2004
Case wrote:
>
> I must admit that Flex is great, but in this newsgroup C rules!


There is a better group for this kind of question? The other groups
where flex/bison or lex/yacc are cited are about "writing a compiler",
and I think that this is not the case.

TIA
--
..O. Cesar A. K. Grossmann ICQ UIN: 35659423
...O http://www.LinuxByGrossmann.cjb.net/
OOO Quidquid Latine dictum sit, altum viditur
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      06-29-2004
Cesar A. K. Grossmann wrote:
> Case wrote:
>
>>
>> I must admit that Flex is great, but in this newsgroup C rules!

>
>
> There is a better group for this kind of question? The other groups
> where flex/bison or lex/yacc are cited are about "writing a compiler",
> and I think that this is not the case.


You'll get better advice in those groups than here.
True, you will have little interest in many of the topics
discussed among compiler writers -- but parsing *is* a
topic they're likely to know a good deal about, and if
you're nice to them they may share that knowledge.

comp.lang.c is (in)famous for its brush-offs and its
(uneven) insistence on topicality. Please understand that
there's an excellent reason for this, to wit: C is a powerful
language with wide applicability. It can be used (sometimes
with extensions) to implement device drivers, keep track of
your bowling league scores, manage the restocking schedules
for supermarket shelves, write "Quake," solve differential
equations, implement PostScript interpreters, and, yes,
parse languages according to grammars. If all these topics
were welcomed in comp.lang.c, the group would become useless,
effectively indistinguishable from alt.chat.anyoldtopic.

... and that's why comp.lang.c tries to avoid "domain-
specific" discussion: There would be far too much of it to
sift through. It would drown out our sober discussions
of how (rather than "where") to apply the language, not to
mention the flame fests and insult wars that are the group's
*real* raison d'etre.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      06-29-2004
Cesar A. K. Grossmann <(E-Mail Removed)> spoke thus:

> There is a better group for this kind of question? The other groups
> where flex/bison or lex/yacc are cited are about "writing a compiler",
> and I think that this is not the case.


comp.unix.programmer, maybe...?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
Mark F. Haigh
Guest
Posts: n/a
 
      06-30-2004
Eric Sosman <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
<snip>
> of how (rather than "where") to apply the language, not to
> mention the flame fests and insult wars that are the group's
> *real* raison d'etre.


Really? Are you trying to ignite a flame fest yourself?

Hmmm. That would be an interesting one, a flame fest regarding
whether or not the raison d'etre of c.l.c is flame fests.

On second thought, though, there's fertile enough ground discussing
hypothetical C implementations written by brilliant, delusional mental
patients on hardware with destructive-read magnetic core memory with
integer trap representations that transform entire continents into
radioactive wastelands...


Mark F. Haigh
(E-Mail Removed)
 
Reply With Quote
 
Richard Harnden
Guest
Posts: n/a
 
      06-30-2004
Christopher Benson-Manica wrote:
> Cesar A. K. Grossmann <(E-Mail Removed)> spoke thus:
>
>
>>There is a better group for this kind of question? The other groups
>>where flex/bison or lex/yacc are cited are about "writing a compiler",
>>and I think that this is not the case.

>
>
> comp.unix.programmer, maybe...?
>


comp.compilers is probably better, if only for the moderator.

--
rh
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      06-30-2004
Cesar A. K. Grossmann wrote:

> Case wrote:
>>
>> I must admit that Flex is great, but in this newsgroup C rules!

>
> There is a better group for this kind of question?


comp.compilers.

> The other groups
> where flex/bison or lex/yacc are cited are about "writing a compiler",
> and I think that this is not the case.


It is nevertheless true that comp.compilers will handle questions about
flex/bison & family. (And grammars.)

And the other obvious choice is comp.unix.programmer.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html
 
Reply With Quote
 
Rob Thorpe
Guest
Posts: n/a
 
      06-30-2004
"Cesar A. K. Grossmann" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Hi
>
> I'm trying to build a parser for a file I create. The file format is as
> follow:
>
> IDENTIFIER = NUMBER STRING STRING;
>
> COMPOSITE = STRING { ITEM [, ITEM, ...] };
>
> ITEM = NUMBER IDENTIFIER|COMPOSITE
>
> A file example is as follow:
>
> eggs_with_bacon = 1 { 2 eggs, 1 bacon_strip };
> eggs = 0.02 "Egg" "Unit";
> bagon_strip = 0.04 "Bacon strip" "Unit";
>
> (My idea was to use it as means to calculate costs of buildings, so you
> can detail it to the level of bricks and mortar, and get the total price
> of the building, but it can be used as a means to calculate any kind of
> costs).
>
> I have already started building a parser, using bison/flex, with rules:
>
> (flex rules)
>
> [[:digit:]]+("."[[:digit:]]*)? return NUMBER;
> [:alpha:][[:alnum:]_]* return IDENTIFIER;
> \"[^\"]\" return STRING;
> \= return EQUAL;
> \{ return LBRACE;
> \} return RBRACE;
> \, return COMMA;
> \; return SEMICOLON;
> ^#.*\n$ /* eat comments */
> [.\n]+ /* eat this */
>
> (end flex rules)
>
> (bison rules)
>
> line: /* empty */
> | line description;
>
> description: short-description
> | long-description;
>
> short-description: IDENTIFIER EQUAL NUMBER STRING STRING SEMICOLON;
>
> long-description: IDENTIFIER EQUAL NUMBER LBRACE items RBRACE SEMICOLON;
>
> items: item
> | items COLON item;
>
> item: NUMBER IDENTIFIER;
>
> (end bison rules)
>
> I added some dummy actions to the bison rules, just to debug it, and I'm
> getting "parse error" after the first line is parsed. I think there are
> something I'm missing, the parser should get to state 0 after reading
> the first rule, but it is going to other state, and gives the 'parse
> error'. Can someone tells me what is wrong with the rules?
>
> TIA
> P.S.: Sorry for the "engrish".



Also consider posting to the flex mailing list (E-Mail Removed).

That said, I'm not sure its got anyone awake on the other end these days.
 
Reply With Quote
 
Cesar A. K. Grossmann
Guest
Posts: n/a
 
      06-30-2004
Rob Thorpe wrote:
>
> Also consider posting to the flex mailing list (E-Mail Removed).


ftp://mail.gnu.org/help-flex/2004-05

That list is full of SPAM. But thanks to all of you.

[]s
--
..O. Cesar A. K. Grossmann ICQ UIN: 35659423
...O http://www.LinuxByGrossmann.cjb.net/
OOO Quidquid Latine dictum sit, altum viditur
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
import parser does not import parser.py in same dir on win Joel Hedlund Python 2 11-11-2006 03:46 PM
import parser does not import parser.py in same dir on win Joel Hedlund Python 0 11-11-2006 11:34 AM
XML Parser VS HTML Parser ZOCOR Java 11 10-05-2004 01:58 PM
XMLparser: Difference between parser.setErrorHandler() vs. parser.setContentHandler() Bernd Oninger Java 0 06-09-2004 01:26 AM
XMLparser: Difference between parser.setErrorHandler() vs. parser.setContentHandler() Bernd Oninger XML 0 06-09-2004 01:26 AM



Advertisments