From: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Patch for BISON.SIM for C++
Date: 8 Aug 1997 07:34:09 GMT
Organization: The National Capital FreeNet
Lines: 54
Message-ID: <5sei5h$jm3@freenet-news.carleton.ca>
References: <5s6hhe$p8f AT freenet-news DOT carleton DOT ca> <33e91bec DOT 2700158 AT news DOT dorsai DOT org>
Reply-To: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host: freenet5.carleton.ca
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


Peter J. Farley III (pjfarley AT dorsai DOT org) writes:
> The original names, if I remember correctly, are "bison.simple" and
> "bison.hairy", the difference being something to do with complex vs.
> simple grammars.  The .SIM and .HAI extensions were obvious MSDOS
> substitutes.  There may have been a command-line switch that told it
> to use the hairy instead of the simple parser.  Or was that a
> difference in the #includes one used?

Well, I had grepped for bison.sim and found it referred to in some exes
and in djgpp.env which has some lines like
BISON.SIMPLE=%DJDIR%/LIBS/BISON.SIM and likewise for BISON.HAIRY and
BISON.HAI, so I'd gathered that much.
I have never seen bison.hai(ry) get included in my code, though, even
though I have made fairly complex parsers with multiple semantic types,
and stuff. (Like, a parser designed to read standard chemical formulas
like CH3(CH2)10CH=CHCH2CH2CH=OOH, which is some unsaturated fatty acid or
another... that was what I would call quite the "hairy" job making a parser
for that, but it used bison.sim(ple) all the same...)

> <Sigh*> It's been too long, sorry I don't remember what it was,
> exactly.  Even the file bison.texinfo (in the source dist) doesn't
> mention it, nor the man-page nor the regular info file.

I had noticed the lack. This suggests that it must be an internal thing,
which the user doesn't need to know much about besides that they should
point those DJGPP.ENV lines at the appropriate 2 files. Like, this
molecular modeller is going to expect to share its directory with
ELEMENTS.DAT and POVRAY.LOC but the user won't need to know the difference
between these or what they do... (Yes, that explains the parser and the
long chain carboxylic acid...) I noticed some mention of re-entrant
parsers in the docs, perhaps that could be it. (I guess this is for a
parser to read say a file and for the parser to call another parser to
read certain file chunks, or perhaps to call itself recursively for
includes? I myself do include directives in parsed files by making the
directive cause the filename to add on a stack, and the lexer to read
tokens from the file at the top of the stack until EOF, after which it
closes that file and drops down the stack, ending parsing only when the
stack is empty. That handles nested includes nicely, with a fairly simple
stack that is really easy in C++, and without too many hassles. I was
under the impression this was how the CPP program in DJGPP worked also, by
using the lexer to handle the nested files so the parser transparently saw
only one "file" or continuous stream of tokens. Certainly, CPP's output is
one single intermediate file for cc1plus with all the #included things
that didn't come out in the wash like #defines, physically in the file.
I.e. a quick test program #including stdio.h produces intermediate files
that physically include the prototypes and structs in stdio.h, followed by
my code.

--
    .*.  Where feelings are concerned, answers are rarely simple [GeneDeWeese]
 -()  <  When I go to the theater, I always go straight to the "bag and mix"
    `*'  bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh