Re: Good practical language and OS agnostic text?

On 4/17/2012 2:28 PM, compilers@is-not-my.name wrote:
> Guys, I'm having a bear of a time finding a good practical language
> and OS agnostic text on writing a compiler. I'm weak in math and not
> interested in the theoretical details. I want to understand the hows
> and whys of compiler writing. Everything I've found is either
> gobbledygook equations or "let's use C/C++/Java on UNIX" or things
> that are so trivial and focused they don't explain general cases and
> can't be extended to anything useful.


<snip>


this is a hard thing to ask.


There is a lot of possible variation between languages, all of which may
have notable impact on the "best" compiler design.


I have not as of yet seen much of anything which tries to address all
this, and most focus more narrowly on "a C or Java like language
compiling directly to native code and using a C-style calling
convention". if designing a dynamic language, or having a "VM layer", or
a language with notably different requirements, then it may make sense
to vary the compiler design as well.


OS and CPU architecture can impact a fair amount as well, so it could be
similarly hard to address all of this without making at least some
assumptions on these fronts.


for example, do they use x86 or ARM as the example? ...




Otherwise, I guess, the book would probably be more of a "survey of the
field and lists of assorted design trade-offs" (or like a topic-focused
encyclopedia or similar), which although likely still useful, is
probably not likely to seem as "refined" or sell nearly as well.


Since many people seem to more like being told "this is how it is and
this is how you do it" than being handed something which more resembles
an encyclopedia.


like with "authority": many people play "follow the leader", others play
"oppose the leader", but both are likely pointless.


a person actively "doing their own thing" will not likely play that
game, and may not really care what the leader thinks, but will in turn
seem to at times be "following the leader" and "opposing the leader",
not because they actually are, but because not everything "the leader"
does is necessarily either right or wrong.




> [Sorry to burst your bubble, but I knew people writing compilers for
> DOS, and they understood parsing theory just fine. Although I agree
> that some compiler texts are more readable than others, the math isn't
> there to be obscure, it's there because understanding how state
> machines and LL and LR work makes writing fast and reliable scanners
> and parsers vastly easier. As far as the language they use for
> examples, you have to use something. If you can find a copy of
> Holub's "Compiler Design in C", and the errata list which is essential
> due to the incredible number of errors in the published edition, you
> might be able to work your way through that. -John]




I don't entirely agree (not being as much of a fan of math either).
the problem isn't so much about "understanding the topic", so much as
people often trying to throw mathematical notation at pretty much
everything.


often it could be explained easily enough using either natural-language,
some kind of pseudo-code, or some other specialized (presumably
non-esoteric) notation.


it is kind of defeats the point if a person needs a math degree to even
figure out what exactly this glob of notation is supposed to be (or even
what sort of math this is even supposed to be, as it becomes more the
"find a match the greek letters and other symbols" game).




it is much like people throwing set notation at everything.
yes, the concept of sets can be used.


but people throw it at nearly everything, often in cases where:
there is another notation and/or formalism which can express the topic
better (such as predicate logic, or even good old algebraic notation);
it has little to do with the topic (such as statistics or newtonian
mechanics, and more obscures the topic than it helps);
...




the end result is the same, the actual topic is buried under a pile of
mathematical gobbledygook.

Return to the comp.compilers page.
Search the comp.compilers archives again.