[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a probablem with Bison
From: |
josephus |
Subject: |
Re: a probablem with Bison |
Date: |
Fri, 08 Jul 2005 18:56:28 -0500 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511 |
I have a debug version of bison 2.0a and I would like to know what you
have found about the problem. I can see the database complicates the
process.
So, I would like to know what you have found or status of the bug that
you have found. My grammar does not generate any errors, no shift or
reduce errors of any kind. But the parser still does not work.
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;
- Re: a probablem with Bison,
josephus <=