On Sat, 14 Nov 2009 11:25:05 +0200, Yigal Chripun <[email protected]>
wrote:
I just saw this on the Go language site
from http://golang.org/cmd/gc/
gives the overall design of the tool chain. Aside from a few adapted
pieces, such as the optimizer, the Go compilers are wholly new programs.
The compiler reads in a set of Go files, typically suffixed ".go". They
must all be part of one package. The output is a single intermediate
file representing the "binary assembly" of the compiled package, ready
as input for the linker (6l, etc.).
The generated files contain type information about the symbols exported
by the package and about types used by symbols imported by the package
from other packages. It is therefore not necessary when compiling client
C of package P to read the files of P's dependencies, only the compiled
output of P.
/quote
notice that they removed the need for header files.
I'd like to point out that this is also what Pascal/Delphi have been doing
for a long while - units (*.pas files) are compiled to compiled units
(*.tpu for Turbo/Borland Pascal, *.dcu for Delphi) which contain compiled
code as well as type information. They can probably also contain code in
an intermediate format, since Delphi allows cross-unit inlining (a
function must be declared as "inline" in the interface section of the
unit).
Speaking of inlining, it doesn't look like Go's scheme would allow
cross-package inlining (not that DMD can do inlining across objects or
libraries, but LDC could change this).
I assume Go can also read type information from source files, otherwise
package circular dependencies would be impossible?
--
Best regards,
Vladimir mailto:[email protected]
