Related articles |
---|
Repetitive tokens christopher.f.clark@compiler-resources.com (Christopher F Clark) (2023-06-16) |
From: | Christopher F Clark <christopher.f.clark@compiler-resources.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 16 Jun 2023 01:09:37 +0300 |
Organization: | Compilers Central |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="83852"; mail-complaints-to="abuse@iecc.com" |
Keywords: | parse, design |
Posted-Date: | 15 Jun 2023 22:31:01 EDT |
Please don't take this the wrong way. You simply have some learning to do.
While I cannot understand most of your posting, I can tell one thing
from what you have written.
You are storing the items in the list at the wrong level. Don't store
the items in the list at the token level. At that level just put the
values on the parser stack. Then, when you have written a rule for a
complete pattern use the yacc $variables, i.e. $1, $2, etc. to put the
items into the appropriate lists. If you try to do it at the token
level, like you are trying to do, you will have a mess, like you have.
That's because you are trying to do the parsers job at the lexical
level. That's way too hard to do.
At the token level, your goal is to keep things as simple as possible.
That means you don't try to add them to the various lists at that
point. This is why your code is so hard and so filled with ifs and
variables tracking things. Parse a whole pattern before putting your
values into the lists. If there are sub-patterns in your patterns,
you can use rules to collect them into lists that you keep on the
parser stack. But, until you have something unambiguous as to "what
is what" (i.e which list some specific integer (say the fifth one in
your pattern, thus $5) goes into, don't try to put it anywhere but on
the parser stack.
Also, get yourself a book on compiler design. I would recommend
Robert Nystom's "Crafting Interpreters" which is available for free on
the web. You will see that [almost] no one attempts to do it the way
you are trying to do it.
--
******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------
Return to the
comp.compilers page.
Search the
comp.compilers archives again.