On 19 May 2008, at 14:02, immanuel litzroth wrote:
It is of a formal grammar, since it does not define a sentence
symbol, nor does it specify context dependencies. For the formal
definition of a grammar, see books on compiler construction, for
example Waite & Goose, "Compiler Construction".
Please stop pretending you are have to educate me on the technical
aspects. The C++ formal grammar ...
You obviously don't know what you are speaking about, when calling it
a "formal grammar".
while not up to mathematical precision is formal enough to base
implementations on.
And it is obviously not possible to do that unless have the grapevine
information about what the sentence symbol.
It is what you get in computer science and the general idea is that
it could be made precise but that is just not worth the trouble.
It doe not do that, because the effort attempting to do so have not
been successful.
implementation contains a preprocessor capable of macro
substitution,
conditional compilation, and inclusion of named files.
I could not even find preprocessor in the index, just preprocessing
directive. Care to give a page reference with this quote?
I gave a quote from Bjarne Stroustrup's book. It is a common informal
lingo used by all C/C++ programmers I know of, and also sometimes by
others who run it before compiling other languages.
This is what I am saying: one runs the preprocessor to get a
translation unit, which then define what I call the "language
proper".
I don't care what *you* call it. Most people agree that source
files hold the language constructs.
That is not the common C/C++ lingo.
So what does that statement imply about order of module
imports,
making sure one is not loaded more than once even called for, in
the
module declarations and recursive modules?
Yes, indeed. They do not seem to mention any of this, maybe because
these things are not defined in the language.
Try to replace the "import" in some Haskell modules calling each
other with "#include" and run the C preprocessor and then compile the
output in Haskell, to see what happens.
Hans
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
