Re: Bison-1.28: Doc Typo, Misc Bugs

[Hans Aberg]

At 09.38 +0200 0-10-03, Akim Demaille wrote:
>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.

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?

>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.)

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

>| 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.

>| >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() { }
    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.

>| -- 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.

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 |...|.


-- 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.

  Hans Aberg