Re: 3.3 Grammar Rules Issues

slipbits <[email protected]> Sun, 12 Jun 2022 11:40:22 -0700
Newsgroups gmane.comp.parsers.bison.bugs
Message-ID <[email protected]>
Hi Kaz;

I'm sorry about the delay in replying, but I wanted to complete a 
summary table of the %define Directives, I hope that this gets through 
the input filters at the "bug" site, but if it does or doesn't I think a 
copy will get to you. I am sending the pdf version. The original was 
composed using LIbreOffice. and if you'd like, I'll send that.

I don't think that I made clear my intent in all the nonsense I've sent. 
I am editing the Bison User's Manual. Let me first say that the 
development of SLR(1) and then LALR(1) parser generators was a 
magnificent addition to the lore of Computer Science. Astounding, 
astonishing, the culmination of about 15 years of effort, and wonderful 
The Yacc, then the Bison versions are truly great. They lead the way and 
show an astonishing ability for growth. We owe the developers, each and 
every one of them, a thanks. The Bison User's Manual is no credit to the 
program. It is in serious need of editing, some reorganization, and the 
addressing of some technical areas. That's what I have started to do. 
The Bison team can ignore it, modify it, follow it, laugh at it, trash 
it, sneer at it, or do anything else. That's up to the team. My 
contribution is more humble.

Some comments are given below with the body of your email.

Ok. what's bothering me. You have one of the most enduring, useful, and 
innovative program from the earliest period of modern computer science. 
It is iconic. I'm proud of this program Your User's Manual doesn't show 
that you're proud of it. It bewilders me.

Let's look at syntax. The document clearly says that it's going to 
address Bison syntax (3.3.1 Syntax of Grammar Rules), and then doesn't.

Look, if the team is not interested in any editing, I'll just pull up my 
skirts and go away (sulking in private to be sure); If the team wants to 
start a dialog, then I think I have something to say which may prove 
useful. Give a ring.

art

On 6/11/2022 5:25 PM, Kaz Kylheku wrote:
> On 2022-06-11 13:38, slipbits wrote:
>> You nowhere define the syntax and grammar of Bison in one place.
> Ah, but that is only the case if we are talking strictly about
> documentation. There is a grammar of Bison given in Bison
> in the source tree:
>
> https://git.savannah.gnu.org/cgit/bison.git/tree/src/parse-gram.y
>
> So the good news is that the grammar is formally specified
> as a grammar.
>
> Maybe a document version of this could be automatically extracted
> from the source via some text processing or something.
The Grammar reference is not suitable for incorporation in the Bison 
User's Manual (BUM - I just couldn't pass this one up). The reference 
shows an implementation not an explanation. The surrounding comments are 
specific to the implementation .  Scraping the comments would not be a 
suitable vehicle to define the Bison grammar in the BUM. Further, the 
syntactic rules are not provided which means only the tokenized use is 
identified.
> How about: add a grammar pretty-printing facility into Bison itself,
> and that can then be applied to the file to geenrate a version that
> is pulled into the document.
>
> Now there is a form of pretty-printing in Bison: it can produce
> a report file ("y.output" in Yacc mode).
As a side note. This is really a great feature. I have used it on my own 
grammar to good effect.
>
> This y.output contains a listing of all the rules, without the
> actions, reformatted.  The grammar could perhaps be text-scraped
> out of that file, or some additional knobs could be implemented to
> bend that reporting feature into pretty-printing.
>
> There might be hacks in the grammar though to resolve ambiguities.
> There is a famous ambiguity in the Yacc grammar involving the
> terminating semicolon of a rule, which is actually optional.
>
> So that is to say, this is a valid grammar fragment, without
> the semicolon terminating either rule:
>
>    a : b
>      | c
>
>    d : e
>
> The "d" is interpreted as the left nonterminal of a new rule, rather
> than a continuation of the a : c rule.
>
> That sort of thing needs explaining, if it happens not to follow
> from the grammar alone, but some tricks are used.
>
>> It is very important that all syntax and grammar rules be defined,
>> and equally important that definition be aggregated and complete,
>> and put into an accessible location. The scatter-shot revelation of
>> grammar and syntax should be avoided.
> A subset of Bison conforms to the POSIX Yacc specification. POSIX does
> have a Yacc grammar all in one place, expressed in Yacc.
>
> See the "Input Grammar" section here:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html
An excellent piece of work, but not suitable for incorporation into the 
BUM. It is specific to the execution of Yacc, so would need to be Bison 
specific, does not address syntax and does not contain detail that would 
be expected in a User's Manual,
>
> But of course that grammar has no actions and other clutter.
>
>
> Cheers ...
>
>
>
3.7.14_Summary.pdf (application/pdf, 35.5 KB) - not displayed