[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a probalem with Bison

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:
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
do not contain a test.alg file.  So I can't reproduce your problem.
You can find a copy of your submission here:


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 problem

Sorry, 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.

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.

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.

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);
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
j = i+j;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]