Writing a Parser

Discussion in 'C Programming' started by Cesar A. K. Grossmann, Jun 29, 2004.

  1. 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
     
    Cesar A. K. Grossmann, Jun 29, 2004
    #1
    1. Advertising

  2. Cesar A. K. Grossmann

    Case Guest

    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>
     
    Case, Jun 29, 2004
    #2
    1. Advertising

  3. 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
     
    Cesar A. K. Grossmann, Jun 29, 2004
    #3
  4. Cesar A. K. Grossmann

    Eric Sosman Guest

    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.

    --
     
    Eric Sosman, Jun 29, 2004
    #4
  5. Cesar A. K. Grossmann <> 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.
     
    Christopher Benson-Manica, Jun 29, 2004
    #5
  6. Eric Sosman <> wrote in message news:<>...
    <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
     
    Mark F. Haigh, Jun 30, 2004
    #6
  7. Christopher Benson-Manica wrote:
    > Cesar A. K. Grossmann <> 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
     
    Richard Harnden, Jun 30, 2004
    #7
  8. Cesar A. K. Grossmann

    Chris Dollin Guest

    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-newsgroup/comp/comp.lang.c.html
    C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
     
    Chris Dollin, Jun 30, 2004
    #8
  9. Cesar A. K. Grossmann

    Rob Thorpe Guest

    "Cesar A. K. Grossmann" <> wrote in message news:<>...
    > 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 .

    That said, I'm not sure its got anyone awake on the other end these days.
     
    Rob Thorpe, Jun 30, 2004
    #9
  10. Cesar A. K. Grossmann, Jun 30, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bernd Oninger
    Replies:
    0
    Views:
    772
    Bernd Oninger
    Jun 9, 2004
  2. ZOCOR

    XML Parser VS HTML Parser

    ZOCOR, Oct 3, 2004, in forum: Java
    Replies:
    11
    Views:
    831
    Paul King
    Oct 5, 2004
  3. Bernd Oninger
    Replies:
    0
    Views:
    829
    Bernd Oninger
    Jun 9, 2004
  4. Joel Hedlund
    Replies:
    2
    Views:
    521
    Joel Hedlund
    Nov 11, 2006
  5. Joel Hedlund
    Replies:
    0
    Views:
    313
    Joel Hedlund
    Nov 11, 2006
Loading...

Share This Page