Re: Bison version 1.875e available for testing

[Hans Aberg]

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

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