|
From: | josephus |
Subject: | Re: a probalem with Bison |
Date: | Sat, 11 Jun 2005 03:22:24 -0500 |
User-agent: | Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511 |
Paul Eggert wrote:
sorry, overlooked it. I attached it. it is just a little file. it is a basic algol program template. Flex tokenized it just fine. Flex build a s scanner. I turn off line numbers because it simplifies identifying source lines. It is awkward trying to find a line in the included bison parser that is listed in the .Y files. The debugger has a problem with instantiation. I have been looking at the 'but' and trying to guess what BISON is doing. Bison collects lists of token occurrences. It would make me think that LALR uses the same algorithm I do, I picked up each token and evaluated it in order. BISON seems to process differently. I know the SLR does not fold states, but it does eliminate duplicates.josephus <address@hidden> writes:the program, you built should parse 10% or more of test.alg It does not.The set of files that you sent in <http://lists.gnu.org/archive/html/bug-bison/2005-06/msg00019.html> do not contain a test.alg file. So I can't reproduce your problem. You can find a copy of your submission here: http://lists.gnu.org/archive/html/bug-bison/2005-06/tariX3bPLs0iE.tar Please send a single, self-contained test case, including the source code, a makefile to build the program, test data, and instructions about how to run the program to use the test data, showing why an older Bison works but Bison 2.0a doesn't. Please don't send .o files or executables; just source code and a simple way to reproduce the problem. Also, please don't ask me to stich together parts of previous bug reports, as I probably will make mistakes in doing so. Just send a self-contained test case.do not change the lexical parser. You will have to fix the EOF problemSorry, I don't know what the "EOF problem" is.I also add left out tokens because I changed the grammar. This is just a way of doing things.Sorry, I don't know what this is either.The problem has been isolated in BISON.Not necessarily. It could, for example, be a bug elsewhere, that is triggered by substituting one version of Bison for another. Until we know what the problem actually is, we don't know whether it's a bug in Bison or in some other part of your system.
I think BISON is not quit sane. it does not build rational parser tables. My grammar has 6 shift/reduce faults. The parser should not be perfect, but it should work as long as possible. It is my problem if the language is not covered. I have some issues with GCC but it works and will compile and link without problems. GDB will not look at data tables. I haven't figured out how to determine if the tables are correct.
It is not clear to me why BISON needs M4 processing. I am not building a restartable grammar. I really need only one parse. I use a minimum configuration. My grammars are simple and right regular. The language is small and extensible. This is why I am building an ALGOL.
I even have a C grammar that used to work.ABOUT EOF: when flex build a parse table, it will not terminate. I dont need to process include files so I can just terminate on END OF FILE. Without the patch the program will run away and not terminate.. It keeps restarting the flex parse. apparently FLEX's I/O is stream oriented. the definition of I/O is sufficiently fuzzy that the code is not quit rational. My files are discrete and I do not parse from the command line. I can imagine how it might work with complex multi-parsing, but I dont use it that way.
begin own integer i,j,k,l; own string a,b,c; long array mass[1000000]; long array x[1000000],y[1000000],z[1000000]; procedure work(integer I,integer J,integer K); begin own integer array list[0:1000000]; return ( I * J + k ); end ; own integer i,j,k,l; own string a,b,c; long array mass[1000000]; long array x[1000000],y[1000000],z[1000000]; do i = 1 to 1000000 begin j = i+j; end; end;
[Prev in Thread] | Current Thread | [Next in Thread] |