Re: 3.3 Grammar Rules Issues

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