bug-bison
[Top][All Lists]
Advanced

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

Re: 3.3 Grammar Rules Issues


From: Domingo Alvarez Duarte
Subject: Re: 3.3 Grammar Rules Issues
Date: Sun, 12 Jun 2022 20:57:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

Hello slipbits !

I forgot to also mention that I did some extensions to bison here https://github.com/mingodad/lalr-parser-test/blob/main/bison/bison-3.8.2-dad.diff that some of then can be incorporated in the official source code.

===

+  -e                            generate RREBNF //to be viewd at https://www.bottlecaps.de/rr/ui +  -n                            generate naked grammar // remove all comments/actions/C code +  -N                            generate lemon grammar // somehow convert to lemon grammar +  -s                            generate sql // generate a SQL databsse from the grammar

===

Cheers !

On 12/6/22 20:40, slipbits wrote:
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 ...






reply via email to

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