Re: Bison-1.28: Doc Typo, Misc Bugs

[Akim Demaille]

| >Hans> -- I think that the skeleton file bison.simple could have some
| >Hans> prototypes like int yyerror(char* errstr); int yylex(); typedef
| >Hans> struct yyltype yyltype; so that one can put the definition of
| >Hans> those functions at the final segment of the .y file without
| >Hans> having to put the prototypes in the first segment.
| >
| >Nope, there are portability issues (KnR vs ISO for instance), and in
| >addition nothing forbids your yylex to be static etc.
| 
| I suspected this was the reason. But the documentation is rather poor at
| this point: I can guess what it should by checking what error messages I
| get from the compiler. Especially the hairy & YYLTYPE; I can guess that one
| should have something like
| 
| #ifndef YYLTYPE
| struct mytype {
|         clock_t timestamp;  /* Or whatever time you decide to use. */
|         int first_line, last_line, first_column, last_column;
|         char* text;
| };
| typedef struct mytype mytype;
| #define YYLTYPE mytype
| #endif
| 
| and then there are no C errors, but linker errrors that one should define
| yyrecover
| yymsg
| yyabort
| timeclock

I have no idea whether hairy is still functional.  And indeed there is
a problem in the design on Bison: it is never quite clear whether it
is the executable bison or the skeleton (bison.{simple, hairy}) which
should define things.  Here for instance you demonstrated that hairy
is less complete than simple.  Indeed we should do that.

The test suite should at least try to check that hairy compiles.
Maybe it will help us to use it.

And BTW, how come you used hairy?


| I have not checked the pure_parser yet, but the documentation only mentions
| the first_line, last_line, first_column, last_column fields for YYLTYPE. If
| the pure_parser also requires the timestamp and text fields, this is
| another doc bug.

Yes/no.  Since they are member of a struct, you don't need to know all
the fields.  Only if you define your own YYLTYPE, in which case RTFC :)



| >Hans> -- As a plugin, I had trouble with Bison's style of exit()'ing
| >Hans> as a replacement of a "return", as then the whole CW IDE
| >Hans> maintaining the plugin is picked down. Therefore I had to
| >Hans> implement a longjump construction, which diverts to a regular
| >Hans> "return".
| >
| >I don't understand what you mean.  You mean a pluggin shall never
| >exit?  Well, we are not interested in MacOS, and we will not clutter
| >the sources to address such limitations.
| 
| The CW IDE exits on several platforms, including UNIX, Windows, and MacOS X
| of course has Mach 2.5/4.4BSD. And if Gnu develops a similar IDE
| (Integrated development system), you will have the same problem as I with
| Bison.
| 
| The problem is more general, using Bison as a library: If a library
| exit()'s or abort()'s, one will also exit from the program using the
| library. :-) So, therefore, it seems me, a library should never exit or
| abort, unless it screwed up so badly that no possible recover is possible.
| :-)
| 
| Under C++, one can instead throw an exception, which the calling program
| can pick up. And when using a make, that is calling the system which is
| doing the program cleanup after the finish.

OK, thanks for the explanations!


| >But you can certainly solve this using some `main' and `exit' of your
| >own.  Just add `#define main my_main' in config.h (likewise with
| >exit), and voila, you can have you own main which implement the
| >longjump stuff.
| 
| This was how I solved it. :-)
| 
| I made a macro #define exit Exit, and Exit longjumps to the actual main(),
| where I can do some extra cleanup if necessary. For example, a library not
| closing files is nasty, as the files then remains locked for the next run.

IIRC `done ()' is the function you need to call.

| -- While I am it, I can mention that the CW IDE can, for the error/warning
| message display, take not only the file and file number, but also the token
| offset, token offset, selection offset and selection length. If one
| provides those, one can by a click get much closer to the error.

That's interesting: what the layout for such error messages?