headers
Albert Chin | 7 Jul 02:56

bison 2.3 test report

We've built bison-2.3 on a number of platforms with the native C, C++
compiler. All tests passed.

  Solaris 2.6/SPARC:
    137 tests were successful.
    21 tests were skipped.

  Solaris 7/SPARC:
    148 tests were successful.
    10 tests were skipped.

  Solaris 8/SPARC, 9/SPARC, 10/SPARC, 10/x86:
    151 tests were successful.
    7 tests were skipped.

  HP-UX 10.20:
    142 tests were successful.
    16 tests were skipped.

  HP-UX 11.00, 11.11:
    137 tests were successful.
    21 tests were skipped.

  HP-UX 11.23/PA, 11.23/IA:
    140 tests were successful.
    18 tests were skipped.

  AIX 4.3.3:
    140 tests were successful.
    18 tests were skipped.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Eggert | 7 Jul 09:21
Favicon

Re: bison 2.3 test report

Thanks for doing all those tests, and reporting the results.
Permalink | Reply | 0 comments |
headers
Anthony Heading | 10 Jul 13:16

trying out the c++ parser skeleton / b4_post_prologue

Hi,

Using a couple of hours on an airplane, I tried switching
some of my code to use the lalr1.cc c++ skeleton. It seems
natural to subclass the generated parser object, which
requires prologue code to be inserted _after_ the generated
parser declaration.  

The right point appears to be the b4_post_prologue macro,
but bizarrely this seems to be inaccessible unless the
parser uses %union.

src/reader.c:576
/*----------------------------------------------------------------.
| There are two prologues: one before %union, one after.  Augment |
| the current one.                                                |
`----------------------------------------------------------------*/

As proof-of-principle, I created a new directive (naturally
called "%no-union"!) which only flipped the prologue.  That
seemed to work OK, but I wonder if there's a better solution?

Anthony
Permalink | Reply | 8 comments |
headers
Joel E. Denny | 11 Jul 17:29

Re: trying out the c++ parser skeleton / b4_post_prologue

On Mon, 10 Jul 2006, Anthony Heading wrote:

> The right point appears to be the b4_post_prologue macro,
> but bizarrely this seems to be inaccessible unless the
> parser uses %union.

Thanks for the feedback.  We've been debating how to clean this behavior 
up.  A solution is actually implemented in CVS, but I'm not sure if that 
one will stick.  You should see some sort of solution in Bison 2.4.

Joel
Permalink | Reply | 1 comment |
headers
Hans Aberg | 11 Jul 23:31
Picon
Picon

Re: trying out the c++ parser skeleton / b4_post_prologue

On 11 Jul 2006, at 17:29, Joel E. Denny wrote:

> On Mon, 10 Jul 2006, Anthony Heading wrote:
>
>> The right point appears to be the b4_post_prologue macro,
>> but bizarrely this seems to be inaccessible unless the
>> parser uses %union.
>
> Thanks for the feedback.  We've been debating how to clean this  
> behavior
> up.

   http://www.wsu.edu/~brians/errors/churchill.html

>   A solution is actually implemented in CVS, but I'm not sure if that
> one will stick.  You should see some sort of solution in Bison 2.4.

>> As proof-of-principle, I created a new directive (naturally
>> called "%no-union"!) which only flipped the prologue.  That
>> seemed to work OK, but I wonder if there's a better solution?

The developers are currently settling for very simple C++, and there  
is little chance you will be able to do normal C++ code writing via  
Bison 2.4 or whatever.

There is an experimental %define directive which can be used to place  
C++ code correctly, some time in the future when it can be used to  
place code, except for 1-liners. So you (Anthony Heading) are on  
right track: one needs a way to place code more accurately in order  
to do C++. In fact, I have made my own tweaks of Bison for last
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akim Demaille | 12 Jul 09:13
Picon
Picon
Picon
Gravatar

Re: trying out the c++ parser skeleton / b4_post_prologue

>>> "Anthony" == Anthony Heading <news <at> ajrh.net> writes:

 > Hi,
 > Using a couple of hours on an airplane, I tried switching
 > some of my code to use the lalr1.cc c++ skeleton. It seems
 > natural to subclass the generated parser object,

Could you please detail why you'd like to do that?  For several
reasons, including recursion support, I think the proper way to extend
the parser is to couple it with a parsing driver.  See

http://www.gnu.org/software/bison/manual/html_mono/bison.html#A-Complete-C_002b_002b-Example

for an example.
Permalink | Reply | 5 comments |
headers
Anthony Heading | 12 Jul 15:22

Re: trying out the c++ parser skeleton / b4_post_prologue

Akim Demaille wrote:
> Could you please detail why you'd like to do that?  For several
> reasons, including recursion support, I think the proper way to extend
> the parser is to couple it with a parsing driver.

Yes, I did read the example in the docs, and thought it an odd design.
Perhaps you also could expand on those reasons - here are my thoughts as
an end-user.

First, it is very natural in C++ for a programmer to link in some
types of application-specific code by providing an implementation of
an abstract interface. See e.g. Stroustrup C++PL ch. 24, MFC, Qt, etc.
I was surprised to find, for example, that in this bison-c++, the
interface to the lexer is not created as an abstract virtual function
for the end-programmer to implement, but instead remains a C macro.
Obviously this isn't wrong per se, but there has been a decade of
aggregate common thinking (agree with it or not) about how ideally
C++ code should differ from C, and the bison-c++ design differs
enough in many areas from this convergence of practice that I found
it unintuitive and hard to use. Therefore I chose to ignore the
documentation example, and instead read the skeleton source code.

Your parsing-driver suggestion leads the semantic action code to be
filled with references to a driver handle.  
        | TOKEN_IDENTIFIER  { $$ = driver.variables[*$1]; }

This is the main reason for my attempt to subclass.  To me, this is
unacceptable - the programmer should totally own the scope in
which the semantic actions are being executed.  Yacc has always
allowed this.  But in C++, there is the huge benefit that this
(Continue reading)

Permalink | Reply | 4 comments |
headers
Akim Demaille | 12 Jul 16:19
Picon
Picon
Picon
Gravatar

Re: trying out the c++ parser skeleton / b4_post_prologue

>>> "Anthony" == Anthony Heading <ajrh <at> ajrh.net> writes:

hi Anthony,

 > Akim Demaille wrote:
 >> Could you please detail why you'd like to do that?  For several
 >> reasons, including recursion support, I think the proper way to extend
 >> the parser is to couple it with a parsing driver.

 > Yes, I did read the example in the docs, and thought it an odd design.
 > Perhaps you also could expand on those reasons

The main reason is to provide a reentrant parser, and that requires a
lot of interaction with the rest of the environment.  It proved to be
much simpler that capture the environment within the so-called driver,
which is passed to the parser.

Another issue was how to pass additional members to the parser, so
that they could be used in the user actions.  Trying to extend the
parser class directly is difficult and does not fit nicely with the
current interface (in particular because one has to extend the
constructor of the parser with constructors to the new members).
Obviously you can't add these new members in a subclass, since the
user actions are run in the superclass.  There was a time when we
provided the user with a means to define a *superclass* of the parser
class, letting him initialize his members this way.  But it was also
very inconvenient.

In the end, after having tried several approaches, the driver pattern
proved to be not only simpler, but also much more flexible and more
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Eggert | 12 Jul 20:03
Favicon

Re: problem with installation on cray x1e system

Thanks for reporting that, though as Hans Aberg notes it's better to
report bugs to bug-bison <at> gnu.org.  I installed the following patch.
By the way, I suggest you use Bison 2.3 rather than 2.1, as it should
be a bit more reliable.

2006-07-12  Paul Eggert  <eggert <at> cs.ucla.edu>

	* data/lalr1.cc (YYCDEBUG): Use 'if (yydebug_) (*yycdebug_)'
	rather than a for-loop that declares a local bool variable.  This
	should work around a compatibility problem with a Cray x1e C++
	compiler reported by Hung Nguyen in
	<http://lists.gnu.org/archive/html/help-bison/2006-07/msg00022.html>.
	The for-loop was introduced in the 2004-11-17 change but I don't
	know why it was needed.

--- data/lalr1.cc	9 Jul 2006 20:36:33 -0000	1.137
+++ data/lalr1.cc	12 Jul 2006 18:00:15 -0000
@@ -336,9 +336,7 @@ b4_defines_if([
 #define YYUSE(e) ((void) (e))

 /* A pseudo ostream that takes yydebug_ into account.  */
-# define YYCDEBUG							\
-  for (bool yydebugcond_ = yydebug_; yydebugcond_; yydebugcond_ = false)	\
-    (*yycdebug_)
+# define YYCDEBUG if (yydebug_) (*yycdebug_)

 /* Enable debugging if requested.  */
 #if YYDEBUG
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anthony Heading | 13 Jul 13:58

Re: trying out the c++ parser skeleton / b4_post_prologue

Hi Akim,

This is very informative - thanks!

You wrote:
> Obviously you can't add these new members in a subclass, since the
> user actions are run in the superclass.

Ah - I was certainly assuming a solution to that problem:  to achieve
what I was aiming for it would be necessary to have the actions run
with those members in scope.  

> In the end, after having tried several approaches, the driver pattern
> proved to be not only simpler, but also much more flexible and more
> powerful.

OK.  My complaints are:
  1)  The pattern is not so intuitive - the simplicity is maybe relative
  2)  The scope in which the semantic actions run seems to be wasted -
      it's not utilisable by the end-user for anything except a single
      "driver" variable.

>  > I was surprised to find, for example, that in this bison-c++, the
>  > interface to the lexer is not created as an abstract virtual function
>  > for the end-programmer to implement, but instead remains a C macro.
> 
> Right.  Valid or not, the point was simply to avoid an indirection.

Very fair, and I probably agree with that call.  I meant it only as an
example where following conventions could increase ease-of-use.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane