[Top][All Lists]

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

Re: Bison version 1.875e available for testing

From: Hans Aberg
Subject: Re: Bison version 1.875e available for testing
Date: Wed, 15 Dec 2004 18:36:08 +0100
User-agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.6

At 08:54 -0800 2004/12/15, Kelly Leahy wrote:
>That being said, you can make your own function, say
>"myparse()" that you call instead of yyparse() and
>define it as follows:
>int myparse() {
>  localtype local1;
>  localtype local2;
>  return yyparse(&local1, &local2);
>then use %parse-param to add these parameters to the
>yyparse specification, and voila - pseudo-locals!
>These would still be hidden from the "outside world"
>but would look local in parse-param for all intents
>and purposes.

I think this is a typical developing-Bison discussion, similar in structure
to other ones we have had here in the past:

Akim Demaille argues that, as there are clearly such workarounds, no
augmenting of Bison is needed: It will just add another feature to maintain.

Against this stands the principle that a correct programming language
should, as far as possible, admit one to write the code as intended, without

What is changing over time is the cost of implementing a feature relative to
the need of it. Programs are now becoming more complicated. And with a %code
<...> {...} like feature, which I recall Akim said Bison already has some
experimental form of, the actual implementation will be straightforward.

So I think what will happen is strong objections against what is perceived
as "featuritis". But once the %code <...> {...} like feature is in place,
that will change.

  Hans Aberg

reply via email to

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