[Top][All Lists]

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

Re: Bison-1.28: Doc Typo, Misc Bugs

From: Akim Demaille
Subject: Re: Bison-1.28: Doc Typo, Misc Bugs
Date: 04 Oct 2000 10:11:16 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

Please, keep the CC to the list!

| >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.
| Unless you can get hairy documented and working, I think you should take it
| out of the main distribution.

OK, go and discuss about this with RMS :)

I actually already sent him some messages about this issue, I'm
waiting for his input.  After that, I'll try to contact the original
author of Bison.

| BTW, at the subversions.gnu.org CVS, what's the difference between "MAIN"
| and "HEAD"? Is "HEAD" the latest beta distribution & and "MAIN" the latest
| regular distribution?

No idea.

| >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?
| It came in the distribution, and I wanted my plugin be as complete as
| possible. I think that hairy might be of interest to that are interested in
| writing compiler-compilers, or parsers with special features (I do not know
| what a "semantic parser" is, which makes me curious.)

Nothing on the web about this (but numerous references to natural
language processing).

| -- About the simple parser, I noticed it was not overly difficult to
| compile it as C++ code.

Nope, indeed.  I do that myself.  See also a project named CMix where
they have a Bison parser used in a C++ project.


        C-Mix is an automatic partial evaluator for the ISO/ANSI C
        language. It transforms generic programs into more efficient,
        specialized versions. For an introduction, read the short
        paper C-Mix: Making Easily Maintainable C-Programs run Fast.


| >| 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 :)
| In hairy, the parser that Bison writes calls those fields, so one gets a C
| compiler error unless those fields are added to the YYLTYPE struct.

Hm, OK, I had not realized YYLTYPE was not defaulted in hairy as it is
in simple.  Another rather surprising thing about hairy is that
yyerror is a variable there!

| >| >Hans> -- As a plugin, I had trouble with Bison's style of exit()'ing
| >| >Hans> as a replacement of a "return",
| ...
| >| 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.
| The exit() function is actually called at a couple of more places; there
| was also an abort(), which I changed to exit(-1) (or Exit(-1) when the
| macro has been expanded).
| Under C++ (which is the lowlevel PL I otherwise use), one might write
| something like
| namespace Bison {
| class Exit {
|     int code;
|     string message;
| public:
|     Exit(int s, const string& m) : status(s), message() { }

Throwing `m' away here.

|     int status() { return code; }
|         string what() { return message; }
| };
|     // At exit point
|     ... throw Exit(12, "core screwed up");
|     // Main code: creates a Bison::main()
| int main(...) {
|     try {
|     ...  // main program code
|     } catch (Exit& ex) {
|         if (ex.status())  cerr << ex.what() << endl;
|         return ex.status();
| }   }
| }  // Namespace Bison
| Just making something up. But as Bison is in its own namespace, it is
| already ready to be used as a library.

That's interesting, thanks!

| >| -- 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?
| typedef struct CWMessageRef
| {
|   CWFileSpec sourcefile;      /* file containing error                    */
|   long       linenumber;      /* error linenumber in file                 */
|   short      tokenoffset;     /* offset into errorline of token underline */
|   short      tokenlength;     /* length of error token to be underlined   */
|   long       selectionoffset; /* start of error for text selection        */
|   long       selectionlength; /* length of error for text selection       */
| } CWMessageRef;
| The CWFileSpec is the file spec struct used on the specific platform
| (MacOS, Windows or UNIX). The IDE will underline the token indicated by
| (tokenoffset, tokenlength) str2 of the in the messagewindow. In the file in
| question, on the line linenumber, it will highlight the area indicated by
| (selectionoffset, selectionlength.

How does it work for multiline symbols?

| When sending a message one also has an enum of the form
|     enum {
|         Info,
|         Warning,
|         Error
|     };
| and two strings str1, str2, the first and second line of the message. If
| one does not want some or any of the CWMessageRef data, a field or the
| whole of it, or any of the two strings, one sets whatever excluded to 0 (or
| NULL). A typical message will look like
|     <>|<Warning:>|<Error:> str1
|     <filename> <linenumber>: str2
| If one clicks on the entry, the file with its underline/selection will pop
| open.
| For example:
| Warning : Bison Compiler-Compiler
| rpcalc.y line 43   symbol lines is used, but is not defined as a token and...
|                                    ----
|                                    ^
| Underlining displayed by the IDE --|
| The idea is that the first line str1 should be a description of the
| problem, and the second str2 a segment of the failing code, where the
| failing token is pinpointed. Here is a C-error:
| Error   : undefined identifier 'foo'
| Bison Plugin.c line 244   cwMessageRef.tokenoffset = foo;
|                                                      ---
| And the part from the file "Bison Plugin.c" window will look like:
|         ....
|         cwMessageRef.linenumber = lineno;
| =>      cwMessageRef.tokenoffset = |foo|;
|         cwMessageRef.tokenlength = 0;
|         ...
| where I have simulated the displayed selection using |...|.

Actually my question was more `how should a tool display the location
of symbols to be understood by your IDE'.  IIUC, it is not a matter of
printing an error msg this or that way, but it's actually by filling a

| -- BTW, if one should check progress on Gnu implementations on MacOS X, the
| one with Mach2.5/4.4BSD, whom should one contact? There is a Tenon
| Mach2.5/4.4BSD, which I used to run on my Mac, which one adds on top of the
| pre-X MacOS, and it has all the Gnu/BSD stuff, GCC, Bison, Flex, Emacs,
| X-windows, etc. So this stuff has been implemented before on Mac's. But
| Tenon say they will no longer do that stuff as they expects others to
| implement it.

I have no idea.


reply via email to

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