Re: a probalem with Bison

[josephus]

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

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;