I love this. I often come back, time and time again, to just re-read this when I have nothing else to do and just want to relax. It’s a very inspiring and educational read, I cannot get enough of it.
As the author of this blog post, I find this statement interesting. Can you expand upon the sentiments expressed in your statement? Also, by 'read this', do you mean just the blog post, or contents of the works by Jim Roskind?
As the author of the blog post, would you be willing to change its title to "The Jim Roskind C and C++ Grammars"? The text makes it very clear that you know that C and C++ are separate languages, and that the archives actually contain separate grammar files for these separate languages. As they should.
From past experience I find "C/C++" a very grating term. Back when I was reading comp.lang.c, "C/C++" was used in questions by particular brands of people, who tried to compile C++ with a C compiler, or compile C with a C++ compiler, or use C++ features in what they thought was C, or in general were confused about the fact that there is no single language called "C/C++", but rather two separate, incompatible languages called "C" and "C++". Anyway, wouldn't it be good to not add to the (potential) confusion?
hah, because you care so much, I'll go ahead and make that change. It's probably better for SEO anyway. I made the change on my local copy. It will get pushed next time I re-build the site.
> In addition to these groups, there is a semi-official C/C++ liaison group consisting of people who
are members of both the C++ committee and the C committee....
I can provide you more papers from the same author, maybe you feel like educating Bjarne Stroustrup on how to write it.
# Getting back to your example, since you copied the grammar from the ANSI
# Standard, your grammar is probably wrong. To expose the problem, try
# parsing:
#
# typedef int A, B(A); /* my bet is you get a syntax error*/
#
# When correctly parsed, the above is equivalent to:
#
# typedef int A;
# typedef int B(A);
#
# or simply:
#
# typedef int A;
# typedef int B(int); /* B's type is function taking an int
# returning and int */
This stuff seems pretty famous and worthy of being preserved, so why is that someone like @historicalcode on GitHub hasn't put it into a repository yet? Some licensing issues?
I doubt there are licensing issues (or at least that is how I TRIED to write the license I included)... but if there are, please contact me on LinkedIn. Are you suggesting I should just put it all on Github as a publicly readable repo? I could probably do so.
First of all, I have to say that your work on the C/C++ grammars is amazing.
My comment was mostly a reaction to this section of the blog post:
> I could only find a single mirror where I could download [the archives c++grammar1.1.tar.Z and c++grammar2.0.tar.Z].
If you happen to have the spare time to set up a public repo (GitHub or whatever), I think it would be great. It would surely help with long-term availability of the files, and people would have a somehow "canonical" link they can reference when they want to cite your work.
Big aside from the actual content, but is there a name for the formatting in the text files like `freegrm4.txt`? Each line has a number of distributed extra spaces so that every line ends with the ending of a word. It makes it really pleasant to read, kind of like a newspaper.
fmt, par, and nroff are common unix utilities that can justify text (in order of complexity). I've been told that fmt was the disk formatter on at least one oddball unix. Or maybe it's just an urban legend to keep people from running unknown commands as root.
I did my PhD work in the late 90s/early 2000s on a C++ parser. In my PhD thesis, I give credit to Roskind for the "lex hack" and cite his 1989 grammar. We reference this posting, basically: https://compilers.iecc.com/comparch/article/90-06-049 Very cool to see this history preserved.
It is an honor to see my grammars still being discussed.
These days I work at Amazon, but I can be found on LinkedIn. If contacted with a comment about the grammars (as opposed to a spam missive from a head hunter), I'll typically respond.
What I really need to (finally) do someday is publish my hacks that I added to byacc to increase usability (I think I called it jryacc).
I've always felt that yacc's "error reports" are kindred to having a compiler error listing limited to:
"you have 7 severe errors, 3 errors, and 23 warnings,"
and a reference:
"to understand the issues, please read the machine code."
:-)
With yacc, verbose output suggests (at best) that you read the "state transition diagrams" <ugh> to make sense of "n shift reduce, and m reduce-reduce conflicts."
jryacc provided the shortest sequence of terminals to reach any state, identifies any non-terminal that is both left and right recursive (a common malady in grammar construction, which ensures ambiguity), the shortest sequence of terminals to construct each non-terminal, etc.
...oh... and not to fear... I have copies of the grammars and files mentioned... so hopefully they won't be too lost too soon.
20 comments
[ 3.5 ms ] story [ 50.2 ms ] threadFrom past experience I find "C/C++" a very grating term. Back when I was reading comp.lang.c, "C/C++" was used in questions by particular brands of people, who tried to compile C++ with a C compiler, or compile C with a C++ compiler, or use C++ features in what they thought was C, or in general were confused about the fact that there is no single language called "C/C++", but rather two separate, incompatible languages called "C" and "C++". Anyway, wouldn't it be good to not add to the (potential) confusion?
You want a link? Here are several,
https://www.arm.com/products/development-tools/server-and-hp...
https://software.intel.com/content/www/us/en/develop/videos/...
https://docs.microsoft.com/en-us/cpp/cpp/c-cpp-language-and-...
https://www.ibm.com/products/xl-cpp-aix-compiler-power
https://developer.amd.com/amd-aocc/
Ah, from ISO as well, no problem, can I start with one paper from Bjarne?
https://isocpp.org/blog/2020/06/thriving-in-a-crowded-and-ch...
> In addition to these groups, there is a semi-official C/C++ liaison group consisting of people who are members of both the C++ committee and the C committee....
I can provide you more papers from the same author, maybe you feel like educating Bjarne Stroustrup on how to write it.
Thanks,
Jim
My comment was mostly a reaction to this section of the blog post:
> I could only find a single mirror where I could download [the archives c++grammar1.1.tar.Z and c++grammar2.0.tar.Z].
If you happen to have the spare time to set up a public repo (GitHub or whatever), I think it would be great. It would surely help with long-term availability of the files, and people would have a somehow "canonical" link they can reference when they want to cite your work.
It is an honor to see my grammars still being discussed.
These days I work at Amazon, but I can be found on LinkedIn. If contacted with a comment about the grammars (as opposed to a spam missive from a head hunter), I'll typically respond.
What I really need to (finally) do someday is publish my hacks that I added to byacc to increase usability (I think I called it jryacc).
I've always felt that yacc's "error reports" are kindred to having a compiler error listing limited to:
"you have 7 severe errors, 3 errors, and 23 warnings,"
and a reference:
:-)With yacc, verbose output suggests (at best) that you read the "state transition diagrams" <ugh> to make sense of "n shift reduce, and m reduce-reduce conflicts."
jryacc provided the shortest sequence of terminals to reach any state, identifies any non-terminal that is both left and right recursive (a common malady in grammar construction, which ensures ambiguity), the shortest sequence of terminals to construct each non-terminal, etc.
...oh... and not to fear... I have copies of the grammars and files mentioned... so hopefully they won't be too lost too soon.
Thanks again for the interesting comments.
Jim