headers
tim | 1 Aug 12:00
Picon
Favicon

--no-parser options

My suggestion is that until the option is fixed

a) The option produce a warning that it's ignored
b) The documentation should reflect that it doesn't work.

One suggestion that was made was that you can use an alternative
skeleton file. However this is problematic because the name given is
added to the default skeleton path (which may be in a directory that
only the sysadmin/root has access to). While on a given system one can
work around this limitation, the solution is not very portable. Example

skeleton=../../../home/gcb/gcb/gcc/gcc/gcb/myskel.skel

If a distro decides to move the directory this will break. Hard to
maintain across time and distrobutions.

My suggestion is that 
c) If skeleton name given includes "/" or "\" it is assumed to be the
full pathname, otherwise it is assumed to be in the default directory.

Would you in principle accept a patch implementing the above? Do I need
to do anything to qualify to provide such a patch (which would be quite
small).

Regards,
Tim Josling
Permalink | Reply | 18 comments |
headers
Joel E. Denny | 3 Aug 06:51

Re: error_verbose yyoverflow conflict

On Mon, 23 Jul 2007, Christian Burger wrote:

> Defining both %error_verbose and yyoverflow under bison v2.3
> and compiling the generated code produces:
> 
> error: label 'yyexhaustedlab' used but not defined

Thanks.  I committed the following to fix that.

Index: ChangeLog
===================================================================
RCS file: /sources/bison/bison/ChangeLog,v
retrieving revision 1.1715
diff -p -u -r1.1715 ChangeLog
--- ChangeLog	29 Jul 2007 01:17:40 -0000	1.1715
+++ ChangeLog	3 Aug 2007 04:48:00 -0000
@@ -1,3 +1,11 @@
+2007-08-03  Joel E. Denny  <jdenny <at> ces.clemson.edu>
+
+	* data/yacc.c (yyexhaustedlab): Define it when YYERROR_VERBOSE is
+	true since it's then always used regardless of whether yyoverflow is
+	defined.  Reported by Christian Burger at
+	<http://lists.gnu.org/archive/html/bug-bison/2007-07/msg00031.html>.
+	* THANKS: Add Christian Burger.
+
 2007-07-28  Joel E. Denny  <jdenny <at> ces.clemson.edu>

 	* src/muscle_tab.c (muscle_percent_define_flag_if): In order to
Index: THANKS
===================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 4 Aug 04:18

Re: --no-parser options

On Wed, 1 Aug 2007, tim wrote:

> My suggestion is that until the option is fixed
> 
> a) The option produce a warning that it's ignored
> b) The documentation should reflect that it doesn't work.

It looks like that's been broken for a long time.  Did it ever work?  Do 
we need it?  Maybe Paul Eggert or Akim Demaille can comment.

> My suggestion is that 
> c) If skeleton name given includes "/" or "\" it is assumed to be the
> full pathname, otherwise it is assumed to be in the default directory.

This has already been implemented in CVS except it doesn't handle systems 
that use "\".  Again, I would like to hear Paul's or Akim's advice on 
whether Bison should worry about that.  I note that, even prior to this 
%skeleton change, Bison's output_skeleton function in src/output.c assumed 
that Bison's installation directory used only "/" as a directory 
delimiter.
Permalink | Reply | 17 comments |
headers
tim | 4 Aug 04:46
Picon
Favicon

Re: --no-parser options

On Fri, 2007-08-03 at 22:18 -0400, Joel E. Denny wrote:
> On Wed, 1 Aug 2007, tim wrote:
> 
> > My suggestion is that until the option is fixed
> > 
> > a) The option produce a warning that it's ignored
> > b) The documentation should reflect that it doesn't work.
> 
> It looks like that's been broken for a long time.  Did it ever work?  Do 
> we need it?  Maybe Paul Eggert or Akim Demaille can comment.
> 

--no-parser would be quite useful to me. I want to use the parse tables
in a lisp program. The less C code I have to filter out the better.

> > My suggestion is that 
> > c) If skeleton name given includes "/" or "\" it is assumed to be the
> > full pathname, otherwise it is assumed to be in the default directory.
> 
> This has already been implemented in CVS except it doesn't handle systems 
> that use "\".  Again, I would like to hear Paul's or Akim's advice on 
> whether Bison should worry about that.  I note that, even prior to this 
> %skeleton change, Bison's output_skeleton function in src/output.c assumed 
> that Bison's installation directory used only "/" as a directory 
> delimiter.

That's good - I'll start using the CVS version.

Tim Josling
(Continue reading)

Permalink | Reply | 16 comments |
headers
Joel E. Denny | 4 Aug 20:49

Re: --no-parser options

On Sat, 4 Aug 2007, tim wrote:

> On Fri, 2007-08-03 at 22:18 -0400, Joel E. Denny wrote:
> > On Wed, 1 Aug 2007, tim wrote:
> > 
> > > My suggestion is that until the option is fixed
> > > 
> > > a) The option produce a warning that it's ignored
> > > b) The documentation should reflect that it doesn't work.
> > 
> > It looks like that's been broken for a long time.  Did it ever work?  Do 
> > we need it?  Maybe Paul Eggert or Akim Demaille can comment.
> > 
> 
> --no-parser would be quite useful to me. I want to use the parse tables
> in a lisp program. The less C code I have to filter out the better.

Unfortunately, it looks like almost no implementation currently exists. 
Bison parses --no-parser (but not %no-parser despite being documented) and 
forgets it.  I just had a look in TODO.  It looks like Akim was also 
wondering whether we needed to keep --no-parser.

Would an XML encoding of the .output file suffice for your purposes?  
I've seen many discussions expressing a desire for that implementation.
Permalink | Reply | 8 comments |
headers
tim | 5 Aug 12:46
Picon
Favicon

Re: --no-parser options

On Sat, 2007-08-04 at 14:49 -0400, Joel E. Denny wrote:
> On Sat, 4 Aug 2007, tim wrote:
> 
> > On Fri, 2007-08-03 at 22:18 -0400, Joel E. Denny wrote:
> > > On Wed, 1 Aug 2007, tim wrote:
> > > 
> > > > My suggestion is that until the option is fixed
> > > > 
> > > > a) The option produce a warning that it's ignored
> > > > b) The documentation should reflect that it doesn't work.
> > > 
> > > It looks like that's been broken for a long time.  Did it ever work?  Do 
> > > we need it?  Maybe Paul Eggert or Akim Demaille can comment.
> > > 
> > 
> > --no-parser would be quite useful to me. I want to use the parse tables
> > in a lisp program. The less C code I have to filter out the better.
> 
> Unfortunately, it looks like almost no implementation currently exists. 
> Bison parses --no-parser (but not %no-parser despite being documented) and 
> forgets it.  I just had a look in TODO.  It looks like Akim was also 
> wondering whether we needed to keep --no-parser.
> 
> Would an XML encoding of the .output file suffice for your purposes?  
> I've seen many discussions expressing a desire for that implementation.

XML encoding of .output would do the job fine. A small suggestion - XML
schemas often tend to be over-engineered - please resist the temptation!

By the way how seriously should I take the warnings not to write my own
(Continue reading)

Permalink | Reply | 7 comments |
headers
Joel E. Denny | 5 Aug 20:03

Re: --no-parser options

On Sun, 5 Aug 2007, tim wrote:

> > > --no-parser would be quite useful to me. I want to use the parse tables
> > > in a lisp program. The less C code I have to filter out the better.
> > 
> > Unfortunately, it looks like almost no implementation currently exists. 
> > Bison parses --no-parser (but not %no-parser despite being documented) and 
> > forgets it.  I just had a look in TODO.  It looks like Akim was also 
> > wondering whether we needed to keep --no-parser.

Unless I hear objections, I believe I will soon remove what little 
implementation and documentation of --no-parser and %no-parser there is.

> > Would an XML encoding of the .output file suffice for your purposes?  
> > I've seen many discussions expressing a desire for that implementation.
> 
> XML encoding of .output would do the job fine. A small suggestion - XML
> schemas often tend to be over-engineered - please resist the temptation!

I don't know when this implementation will happen, but I know many people 
have expressed interest.  Some people have proposed to work on it, but I 
can't recall now what became of those efforts.  If I do it, it likely 
won't be any time soon.  If you're thinking of trying it, you might wish 
to poll the mailing lists first to see if someone else has already made 
progress.

> By the way how seriously should I take the warnings not to write my own
> skeleton? How radical are future changes to the interface likely to be?
> 
> "These skeletons are the only ones supported by the Bison team.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Hans Aberg | 5 Aug 20:18
Picon
Picon

Re: --no-parser options

On 4 Aug 2007, at 04:46, tim wrote:

> --no-parser would be quite useful to me. I want to use the parse  
> tables
> in a lisp program. The less C code I have to filter out the better.

It sounds you want to generate a LISP parser. Have you thought of  
writing a skeleton file for generating LISP output, which might (some  
day) be included in the Bison distribution?

   Hans Aberg
Permalink | Reply | 6 comments |
headers
tim | 6 Aug 12:19
Picon
Favicon

Re: --no-parser options

On Sun, 2007-08-05 at 20:18 +0200, Hans Aberg wrote:
> On 4 Aug 2007, at 04:46, tim wrote:
> 
> > --no-parser would be quite useful to me. I want to use the parse  
> > tables
> > in a lisp program. The less C code I have to filter out the better.
> 
> It sounds you want to generate a LISP parser. Have you thought of  
> writing a skeleton file for generating LISP output, which might (some  
> day) be included in the Bison distribution?
> 
>    Hans Aberg

If that's feasible, it's probably what I will do. The alternatives would
be to write my own parser generator, or trawl through the bison output.
I've printed out the M4 manual so I can understand the skeletons.

Tim Josling
Permalink | Reply | 5 comments |
headers
Hans Aberg | 6 Aug 21:28
Picon
Picon

Re: --no-parser options

On 6 Aug 2007, at 12:19, tim wrote:

>>> --no-parser would be quite useful to me. I want to use the parse
>>> tables
>>> in a lisp program. The less C code I have to filter out the better.
>>
>> It sounds you want to generate a LISP parser. Have you thought of
>> writing a skeleton file for generating LISP output, which might (some
>> day) be included in the Bison distribution?

> If that's feasible, it's probably what I will do. The alternatives  
> would
> be to write my own parser generator, or trawl through the bison  
> output.
> I've printed out the M4 manual so I can understand the skeletons.

Bison has been changed in order to facilitate that, including adding  
M4, but it is hard to foresee the practical difficulties if you do  
with say Lisp or Scheme. Learning whole M4 is very ambitious: one can  
start tweaking the skeleton file, by comparing with the output. One  
hurdle is figuring out how to translate the rather imperative style  
of the parser (a so called push-down automaton to which Bison merely  
computes the states) into a functional language. The parser function  
checks if a new token is needed, and if there results in a reduction,  
the action is performed in a large "switch" statement, and then it  
loops back again, until the virtual end symbol arrives (the parser  
stack has completely been reduced). The parse stack has different  
components: state, semantic value, location, perhaps more, which can  
be implemented as a single stack, or several. At least in the past,  
the Bison skeleton file did the latter.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane