Kristian Kilpi wrote:
On Sun, 22 Mar 2009 14:14:39 +0200, Christopher Wright
<dhase...@gmail.com> wrote:
Kristian Kilpi wrote:
#includes/imports are redundant information: the source code of
course describes what's used in it. So, the compiler could be aware
of the whole project (and the libraries used) instead of one file at
the time.
That's not sufficient. I'm using SDL right now; if I type 'Surface
s;', should that import sdl.surface or cairo.Surface? How is the
compiler to tell? How should the compiler find out where to look for
classes named Surface? Should it scan everything under
/usr/local/include/d/? That's going to be pointlessly expensive.
Such things should of course be told to the compiler somehow. By using
the project configuration, or by other means. (It's only a matter of
definition.)
For example, if my project contains the Surface class, then 'Surface s;'
should of course refer to it. If some library (used by the project) also
has the Surface class, then one should use some other way to refer it
(e.g. sdl.Surface).
Then I want to deal with a library type with the same name as my builtin
type.
You can come up with a convention that does the right thing 90% of the
time, but produces strange errors on occasion.
But my point was that the compilers today do not have knowledge about
the projects as a whole. That makes this kind of 'scanning' too
expensive (in the current compiler implementations). But if the
compilers were build differently that wouldn't have to be true.
If you want a system that accepts plugins, you will never have access to
the entire project. If you are writing a library, you will never have
access to the entire project. So a compiler has to address those needs, too.
If I were to create/design a compiler (which I am not ;) ), it would be
something like this:
Every file is cached (why to read and parse files over and over again,
if not necessary). These cache files would contain all the information
(parse trees, interfaces, etc) needed during the compilation (of the
whole project). Also, they would contain the compilation results too
(i.e. assembly). So, these cache/database files would logically replace
the old object files.
That is, there would be database for the whole project. When something
gets changed, the compiler knows what effect it has and what's required
to do.
All this is helpful for developers. It's not helpful if you are merely
compiling everything once, but then, the overhead would only be
experienced on occasion.
And finally, I would also change the format of libraries. A library
would be one file only. No more header/.di -files; one compact file
containing all the needed information (in a binary formated database
that can be read very quickly).
Why binary? If your program can operate efficiently with a textual
representation, it's easier to test, easier to debug, and less
susceptible to changes in internal structures.
Additionally, a database in a binary format will require special tools
to examine. You can't just pop it open in a text editor to see what
functions are defined.
