Hello Barry,
first, thanks for taking the time to explain things at length. As
usually I'm learning a lot from reading your posts.
> Yes, but that would require you to thread the type you are
> discriminating the template instantiation by throughout the program,
> from the compiler driver through to the code generator, solely to take
> advantage of template specialization for this very low-level (in terms
> of the abstraction stack) task. Essentially, every method on the call
> chain would need to be templated.
FWIW, I don't like this either, but in fact this is how many C++
libraries are implemented; this is what "modern C++" is considered
today. If you have a look at Boost, you see that most of the libraries
are implemented in the header files only, even the really large ones -
Spirit, Graph, Regex (mostly), not to speak of pathological examples
such as MPL or Preprocessor.
I dislike this as much as everyone who isn't used to fighting swordplay
during compilation. Points are: a) this is not uncommon in C++ code,
and b) it /can/ be of advantage performance-wise.
> When programmers start thinking about performance, odd things start
> happening in their heads. Implementations they are familiar with from
> past experience become much more desirable than implementations that
> are alien to them, or even implementations they haven't thought much
> about.
Yes, I admit that I didn't yet try to implement a compiler in LISP. I
guess I should :)
> * Functional: use sum types for the data structures and
> pattern-matched functions for the operations. This way, the
> operations are separated from the data structure definitions, but the
> implementation is free to use e.g. the C-style approach of a lookup
> table for the actual implementation.
>
> The functional approach enables the combination of better type safety
> than the C approach (it's easy to muck up your discriminated unions in
> C), better modularization in terms of separating code from data (the
> code could be one of many analysis passes, wouldn't want to include
> every possible pass in the data structure definitions etc.), but
> without the double indirection penalty of the OO approach.
Do you have any pointers for further reading, or even an example? This
sounds very interesting, and I'd love to learn how to better leverage
functional approaches for well-known problems.
Pattern matching - is that like specialized templates in C++, but being
dispatched at runtime?
> With respect to dcc32's speed, it has grown from maintenance such that
> it is hard to disentangle various threads to optimize particular
> aspects independent of semantics. C's lack of abstractions hasn't
> helped. For example, dcc32 uses hash codes of 1 byte - an unsigned
> char - throughout for symbol tables. It's particularly obvious in
> compiling Windows.pas - compilation slows down dramatically towards
> the end of the unit as the hash bucket chains grow to silly lengths.
> (This is a reason to keep the Windows unit early in the uses list, as
> symbol lookups are performed in reverse order of uses.) Fixing this
> hash code issue would mean changing large portions of the source;
> most of the hash code lookups are hand-coded directly, rather than
> encapsulated in any reasonable way. A simple comparison of e.g. MS C#
> compilation speed against dcc32 using roughly transliterated code -
> just parsing of declarations, with empty method bodies - is
> revealing: dcc32 is usually slower. Dcc32 can win in other ways, as
> it can save unit state to DCU while C# must recompile all .cs in an
> assembly every time, but it is certainly clear that dcc32 is no
> longer benefiting so much from all the assumptions baked into it back
> in the early 90s, when machines were less powerful and programs much
> smaller.
Ah, I see. I didn't specifically compare DCC's speed to the speed of cs
or javac. My assumption was mostly based on BCC which probably is the
fastest contemporary C++ compiler out there. I used to tribute this to
it's relatively low-level implementation (as Keimpe stated at
http://home.comcast.net/~spacedomain/spacedomain/resume.html,
preprocessor and character scanner are plain x86 assembly) - but
perhaps I'm wrong :)
--
Moritz
"Hey, it compiles! Ship it!"