[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.3 Grammar Rules Issues
Domingo Alvarez Duarte
Re: 3.3 Grammar Rules Issues
Sun, 12 Jun 2022 20:57:33 +0200
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
that some of then can be incorporated in the official source code.
+ -e generate RREBNF //to be viewd at
+ -n generate naked grammar // remove all
+ -N generate lemon grammar // somehow
convert to lemon grammar
+ -s generate sql // generate a SQL databsse
from the grammar
On 12/6/22 20:40, slipbits wrote:
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.
On 6/11/2022 5:25 PM, Kaz Kylheku wrote:
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.
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:
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.
As a side note. This is really a great feature. I have used it on my
own grammar to good effect.
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).
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,
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
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:
But of course that grammar has no actions and other clutter.