bison-patches
[Top][All Lists]
Advanced

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

Re: YYDEBUG and so forth


From: Akim Demaille
Subject: Re: YYDEBUG and so forth
Date: 03 Jul 2002 13:49:58 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

>>>>> "Paul" == Paul Hilfinger <address@hidden> writes:

>> We should really stop using YYDEBUG, YYERROR_VERBOSE and so forth
>> in our skeletons.  yacc.c has to, since that specified by POSIX.
>> But the other skeletons should rely only on %directives.

Paul> Akim,

Paul> I'm not quite sure what you mean here.  If you are saying that
Paul> we ought to control the presence/absence of debugging code by
Paul> %directives, that's fine.  

Yes.  Bison ought to stop relying on CPP.

Paul> But one way to do that is to have conditionalization code in the
Paul> skeleton, controlled by symbols like YYDEBUG, which are in turn
Paul> set according to directives in the .y file.  

That's right, but in that case you are providing an undocumented
interface that users will rely on.  We might pay this in the future.
Similarly for ERROR_VERBOSE.

There are already things such as PARSE_PRM etc. which interface is
very unfortunate, and we will have to stop supporting it (for
instance, it makes it difficult to pass to sub routines in case of
pure parsers etc.).

YYLTYPE is also an error I think.

Paul> The only difference with yacc.c is then that you don't document
Paul> (and therefore don't guarantee) that these symbols are present
Paul> in the generated code.  They are simply parts of the
Paul> implementation, in that case.

I understand your point.

Paul> So perhaps you could clarify precisely what change you have in
Paul> mind.

Those you understood.  I'm just afraid of what users might think of as
implicit contracts between Bison and them.



reply via email to

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