From: | ArarghMail609@Arargh.com |
Newsgroups: | comp.compilers |
Date: | 11 Sep 2006 15:52:24 -0400 |
Organization: | Ripco Communications Inc. |
References: | 06-09-02906-09-035 06-09-039 06-09-042 06-09-043 06-09-045 |
Keywords: | parse |
Posted-Date: | 11 Sep 2006 15:52:24 EDT |
On 11 Sep 2006 09:12:51 -0400, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:
>On 11 Sep 2006 08:39:39 -0400, ArarghMail609@Arargh.com wrote:
<snip>
>> It can be useful. As part of constant expression reduction, I had to
>> scan the expression tree as if I were interpreting it. But that was
>> added later.
>
>Why? It is an integral part of the recursive descent parser. At some point
>the parser expects an expression, so it calls to Get_Expression, which
>scans up to the right bound of the expression (generating tree as a side
>effect). Of course, it would be silly to design Get_Expression itself this
>way, but that is no different from Get_Identifier or Get_Literal
>subprograms. Expression is just a "token" for the parser.
Several reasons. Some of the reasons are here:
http://www.arargh.com/basic/history.html
a) At the time I wrote the expression tree routines, I didn't really
know what I was doing. I was learning. I still am. Also, I wanted
the trees to reflect the source exactly, so that I could find errors.
b) BCET was developed in a limited 16-bit IDE. There simply wasn't
room to get too fancy. Still isn't.
c) Since the code generator has to desend the trees anyway, constant
expression reduction was added there. Although, it was added as a
seperate routine, which allows it to be turned off.
--
ArarghMail609 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
Return to the
comp.compilers page.
Search the
comp.compilers archives again.