[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
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.
http://www.diku.dk/research-groups/topps/activities/cmix/
| >| 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
CWMessageRef.
| -- 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.
Akim