Re: How `export' could be useful
Andrei Alexandrescu (See Website For Email) wrote:
Walter Bright wrote:
But D can do it differently. Preparsing works in D template bodies
because the language is designed to be parseable without semantic
knowledge. The semantic analysis is done at instantiation time.
My opinion is a bit different. To summarize it: it's best to do
semantic
analysis (the more the better) when seeing the template body. It's bad
that C++ needs semantics just to be able to parse.
Being able to parse the template bodies is not that big a deal in and of
itself, the important thing is to parse it at some point at compile
time. When in the compilation process it is done doesn't really matter.
The big deal, however, in being able to parse without a symbol table is
that one can write tools that can analyze source code without having to
build a full blown compiler. Being able to parse the code *correctly*
without needing to spend 10 years first building a compliant front end
opens up a big door to all kinds of tools that can be written that can
manipulate source code.
More details: It is best to be able to do semantic analysis when
you see
the template definition, but not for C++'s reasons (getting the parse
right). Parsing indeed should be doable without much, or any, semantic
analysis. It's best to do "early" semantic analysis to encourage
separate compilation, separate analysis, and separate reasoning
(both by
humans and by machines) about code. Perhaps the biggest leap in
software
productivity was the introduction of entities that had the same
semantics regardless of the code they were used in. That has since
become so obvious, we tend to forget about it.
Ideally, it should be enough for a compiler to see a template
definition
to figure out the following:
(1) What exact requirements a type is expected to meet to be proper
for
instantiating the template;
(2) Which parts of the template impose each of those requirements.
Point 1 is necessary for separate compilation, point 2 is necessary
for
meaningful error messages (that could also help the template author to
relax the requirements).
I think the requirements a template parameter should meet (i.e.
"constraints") should be specified by the template author in the
interface to the template (analogously to how function parameter types
must be explicit). Having the compiler figure them out for you I'm not
sure of the utility of.
So if D defers all of the hard work to instantiation time,
Ironically, in C++ parsing is the hard part. In D, parsing is the easy
part <g>.
paint me unimpressed. That's just C++ cleaned of the C-inherited
ambiguities that
led to the "typename" ab(d)omination.
Fixing the name lookup rules is far from the only thing improved in D
templates. My aim is to make templates as easy to write as ordinary
classes or functions are - cleaning up the syntax and the rules is a
necessary step for that. Templates should be writable by mortals, not
just the gods <g>.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]