Programming Forums > Application Development > C++

The Dark · May 26th, 2006, 7:48 PM

You would need some more definitions than that, as that only seems to cover how to get from the input to the tokens.
If you have something like:
<compound> ::= begin <stmt-list> end

Then the recursive descent parser code would look something like:

(Toggle Plain Text)

   function parseCompound()
   {
     if (currentToken == begin)
     {
        getNextToken();
        parseStmtList();
        if (currentToken != end)
          throw error
        getNextToken();
      }
    }

You don't need to use throw and catch, you can use error codes instead.

programmingnoob · May 26th, 2006, 8:21 PM

Quote:

Originally Posted by DaWei

sorry, i think i started assuming again that people can read my mind

well ... i have scanner class already coded ... which basically is used to look at a stream and return tokens.

now what does the parser do? it looks at the tokens.. cool ... but how? ...

also ... it evaluates whether the given expression is a valid one ... but how does it knw when one expression ends and the another one starts?

DaWei · May 26th, 2006, 8:46 PM

An expression begins and ends when defined begin and end conditions are met, or when an intolerable error (failure to meet expectations) occurs. Consider C/C++ and the 'if' statement. The expression begins with the first '(' after the 'if' and ends with the ')' preceding the first statement. You can see that an improper number of parentheses tokens, or some other things, can bung up the detection of that series of events. The detection of a '{', which is not required in all cases, could help, if it were.

PL/Z, on the other hand was entirely free form, in that anything could continue over any number of lines. That required a greater number of defined tokens. The 'if' expression begin following the 'if' and continued until a 'then' was encountered, wherever that might me. The 'then' block terminated with either an 'else' or a 'fi'. So, on it went.

Consider, then, a scientific calculator employing RPN and a stack. Sequence is important, not just tokens. There are many colors of frogs.

The workings of your parser, then, depend entirely upon your definitions of what constitutes a what, when it's allowed and when it's not, and whether or not its meaning might change with sequence or context. A whore defined as a saint will never be stoned. Well, that's not true, saints get stoned, but you see what I mean.

The accumulation of tokens is merely a small part. You might even have to disburse them in different piles and fetch them in different orders, depending upon YOUR (or your teacher/boss/client's) definition of how things work.

I can't think that this post is much help, at all. Perhaps it can stir a few thoughts, but you are going to have to gather your requirements and make some sense of them. Breaking the job into small pieces is a good approach, but it's worthless if you break it into meaningless pieces that have no ultimate applicability.

programmingnoob · May 26th, 2006, 8:54 PM

Quote:

Originally Posted by The Dark

You would need some more definitions than that, as that only seems to cover how to get from the input to the tokens.
If you have something like:
<compound> ::= begin <stmt-list> end

Then the recursive descent parser code would look something like:

(Toggle Plain Text)

   function parseCompound()
   {
     if (currentToken == begin)
     {
        getNextToken();
        parseStmtList();
        if (currentToken != end)
          throw error
        getNextToken();
      }
    }

You don't need to use throw and catch, you can use error codes instead.

i am not even sure what throw and catch means
as far as i know, if an expression is not valid, the program is just supposed to tell the user that it's invalid ... thats it, right?

DaWei · May 26th, 2006, 10:19 PM

If you check your oil, you may catch an error. That's an error code. If you forget about it and the engine throws a rod, that's an error indication you can catch, but it was actually arranged by the designer of the engine. Sort of.

programmingnoob · May 27th, 2006, 6:01 AM

http://www.ross.net/funnelweb/refere...er_parser.html
^the link above sorta clears my doubts
but it also indicates that i coded my scanner wrong

(which i was sorta worried about from the very beginning)

what my scanner does is it returns tokens, it also stores them in a hash table called symbol table, but there is no way of telling the order the tokens were stored in the table....
so .... when the main function in main.cpp calls the scanner class and the class returns a tokens ... maybe I should have a function in main.cpp to store the tokens etc in the order they are received, no ??

i have attached my full working code for scanner so that you would know what's going on ... coz i am not good at explaining things ... i try though

mikaoj · May 27th, 2006, 6:20 AM

I'm also wrting a compiler, but a little different way.

programmingnoob · May 27th, 2006, 6:54 AM

Quote:

Originally Posted by mikaoj

I'm also wrting a compiler, but a little different way.

different in what sense?

mikaoj · May 27th, 2006, 7:12 AM

The scanner breaks the source to tokens. Every single token will be added to a symbol table. The parser will try to assemble tokens to statements, and generate output code of the parsed tokens.

programmingnoob · May 27th, 2006, 4:49 PM

Quote:

Originally Posted by mikaoj

The scanner breaks the source to tokens. Every single token will be added to a symbol table. The parser will try to assemble tokens to statements, and generate output code of the parsed tokens.

how? tokens are added to the symbol table, but there is no way of knowing in what order, so how does that work?

May 26th, 2006, 7:48 PM	#11
The Dark Expert Programmer Join Date: Jun 2005 Posts: 893 Rep Power: 4	You would need some more definitions than that, as that only seems to cover how to get from the input to the tokens. If you have something like: <compound> ::= begin <stmt-list> end Then the recursive descent parser code would look something like: (Toggle Plain Text) function parseCompound() { if (currentToken == begin) { getNextToken(); parseStmtList(); if (currentToken != end) throw error getNextToken(); } } function parseCompound() { if (currentToken == begin) { getNextToken(); parseStmtList(); if (currentToken != end) throw error getNextToken(); } } You don't need to use throw and catch, you can use error codes instead.

May 26th, 2006, 8:46 PM	#13
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	An expression begins and ends when defined begin and end conditions are met, or when an intolerable error (failure to meet expectations) occurs. Consider C/C++ and the 'if' statement. The expression begins with the first '(' after the 'if' and ends with the ')' preceding the first statement. You can see that an improper number of parentheses tokens, or some other things, can bung up the detection of that series of events. The detection of a '{', which is not required in all cases, could help, if it were. PL/Z, on the other hand was entirely free form, in that anything could continue over any number of lines. That required a greater number of defined tokens. The 'if' expression begin following the 'if' and continued until a 'then' was encountered, wherever that might me. The 'then' block terminated with either an 'else' or a 'fi'. So, on it went. Consider, then, a scientific calculator employing RPN and a stack. Sequence is important, not just tokens. There are many colors of frogs. The workings of your parser, then, depend entirely upon your definitions of what constitutes a what, when it's allowed and when it's not, and whether or not its meaning might change with sequence or context. A whore defined as a saint will never be stoned. Well, that's not true, saints get stoned, but you see what I mean. The accumulation of tokens is merely a small part. You might even have to disburse them in different piles and fetch them in different orders, depending upon YOUR (or your teacher/boss/client's) definition of how things work. I can't think that this post is much help, at all. Perhaps it can stir a few thoughts, but you are going to have to gather your requirements and make some sense of them. Breaking the job into small pieces is a good approach, but it's worthless if you break it into meaningless pieces that have no ultimate applicability. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

May 26th, 2006, 10:19 PM	#15
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	If you check your oil, you may catch an error. That's an error code. If you forget about it and the engine throws a rod, that's an error indication you can catch, but it was actually arranged by the designer of the engine. Sort of. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

May 27th, 2006, 6:20 AM	#17
mikaoj Programmer Join Date: Aug 2005 Location: Norway Posts: 56 Rep Power: 0	I'm also wrting a compiler, but a little different way. __________________ Heh.

May 27th, 2006, 7:12 AM	#19
mikaoj Programmer Join Date: Aug 2005 Location: Norway Posts: 56 Rep Power: 0	The scanner breaks the source to tokens. Every single token will be added to a symbol table. The parser will try to assemble tokens to statements, and generate output code of the parsed tokens. __________________ Heh.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Programming Forums > Application Development > C++

writing a parser in c++