Unfortunately there is little reason to believe that the target audience are reasonably knowledgeable programmers.
The level of programming knowledge in the forum participants varies a great deal, no doubt about that.
As an aside, the Meta-2 PDF that I attached was originally published in 1964. When I started using it for teaching in about 1985 I thought that was ancient... and that was 35 years ago. But it's still useful.
I haven't read all of it yet but, had a quick look. While the concepts have been "polished" and expanded over time, those presented in that documented haven't really changed that much. Thank you for sharing!.
You may take a look at mselang, the Pascal compiler of LLVM.
https://github.com/mse-org/mselang
I'll have a look at it. Thank you for pointing it out.
If possible, I'd like to contribute.
Definitely possible and most definitely welcome!.
Wirth <snip> favoured recursive /ascent/ (Irons et al.).
I have not used recursive ascent to any significant extent. I'll stick to recursive descent because it is very simple, very easy to explain and visualize and, I happen to know it quite well, as a result, I might be able to provide a clear and simple explanation. A very desirable characteristic in a tutorial.
FWIW, I'd also like to see this tutorial made. It'd would be invaluable if it were made easy to understand for programmers with little formal training, whatever the level of experience needed.
I firmly believe that if someone _really_ understands something, they can explain it in terms that just about anyone can understand.
One of my favorite things to ask mathematicians is "why does minus times minus equal plus?"... the explanation is _trivial_ if you understand it. If you want to _understand_ why, watch the videos found at
http://www.dimensions-math.org/Dim_tour_E.htm If memory serves, I believe it was in chapter 5 where they made it obvious. You'll be amazed at how much math you can learn when the person who explains it actually understands what he is talking about. If such explanations pique your interest, look for James Tanton on youtube. He is great.
Also very interesting are the book series, "proof without words" from Roger Nelson and some from James Tanton. Warning: the Nelsen books are often quite overpriced. Tanton's stuff is excellent and usually very affordable (a lot of it free on youtube.)
The saddest part is, while schools teach all kinds of stuff, they don't teach their students _how to think_. Paul Zeitz has an excellent class, description and availability at
https://www.thegreatcourses.com/courses/art-and-craft-of-mathematical-problem-solving.htmlHTH.
I've tried to understand quite some books on compiler design and building and while I did learn quite a lot in the end I failed mainly because most (all?) of them seem to assume you're an university student/graduate of some kind and use difficult-to-parse terminology and lots of difficult-to-follow maths.
I can relate. Very often the language, in this case Math, used to "explain" a problem is more difficult to understand than how the solution to the problem is derived. The minus times minus equal plus is a good example of that.
It's not just- in my opinion- that compiler texts assume that you're a graduate with good comprehension of maths. They appear to go out of their way to be obtuse, and to insist that "if you're not one of us (which you can be by studying this text) then you're not good enough to know about this stuff".
Playing devil's advocate, while I feel the same way, one of the principal reasons for the "obtuse" explanations comes from wanting to be extremely accurate and precise, i.e, leave no room for ambiguity (which is desirable, if not downright required.) That's often not easy to accomplish and, too often collides with simplicity.
I'm not so confident that FORTRAN and COBOL as understood in the 1950s are quite so tractable, and the necessity of considering those might have complicated the field quite a lot.
The first FORTRAN compiler was a mess and, that is what triggered the thought: "there's got to be a better way of doing this", leading to the definitions of grammars, their characteristics, expressive abilities, etc.
I think that the problem lies in that most texts emphasize the "theory" part,
True. Again, playing devil's advocate, they focus on explaining the power of a particular concept (in this case grammars) not how to use them. It is (unfortunately) presumed that once the reader understands the power of a parsing technique and its limitations, that the reader will be able to use that knowledge to apply it correctly, effectively and when appropriate.
Most people learn best by example and contrast. Theory books are usually lacking in those areas.