[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Guile-user] Re: and module system

From: Mikael Djurfeldt
Subject: [Guile-user] Re: and module system
Date: 02 Sep 2000 01:31:12 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7

address@hidden (Carl R. Witty) writes:

> When I hear "separate compilation", it makes me think that individual
> modules can be compiled, modified, and recompiled in any order.

I don't know if there exists a common definition of "separate
compilation", but it seems to me that the most important requirement
to be called like that must be that it's possible to compile a
compilation unit separately.  Exactly what you put into "separately"
can vary.

In any case, yes, it's certainly better to be able to compile in any
order, and we'll be able to achieve that in our module system.

> Skimming through the paper, it appears to require that later modules
> are recompiled whenever any earlier module is recompiled (in the
> module dependency DAG).

Do you deduce this from the section I quoted, or from some other
considerations?  Can you explain why compilation must be ordered?

> > > I think this is necessary because all module connections are rewritten
> > > into a low-level import primitive and their import primitive refers to
> > > the module itself, not to an abstract interface as in MZ Scheme for
> > > example.
> > 
> > But the module in itself is an abstract interface.  Everything about
> > modules can be resolved at compilation time.
> In my opinion, to call something an abstract interface, it must be
> possible to change the underlying implementation without changing the
> interface; saying "the module in itself is an abstract interface"
> makes no sense.  (The module may be an interface, but it is certainly
> not abstract.)

I should have been clearer on this point.  Note that we were talking
about reasons in the *implementation* why or why not linking is
dependent on previously compiled output.  I should have said that from
the point of view of the implementation, the module is only a
syntactic abstraction which at compile time can be resolved to an
interface (which looks the same regardless of the underlying

> > > In "C" the compiler examines interfaces, not object files, no?
> > 
> > Some C compilers precompile the headers.  I think we should compare to
> > that situation.
> The difference is that in C, you can change the implementation without
> changing the header file, and compilation of subsequent modules
> depends only on the header file, not on the implementation.

It seems to me that it should be possible to create a name mangling
scheme so that names are created deterministically, so that all names
needed for linking can be determined only by scanning the source.

If we want, we can invent our own conventions for how interfaces
should be specified---just as we are free to place a C preprocessor
macro in a header file rather than in a .c-file, we should be able to
place our interfaces separately if this is something we want.

As I said, I think the reason why they look at object modules in their
implementation is that it's smart----then they can execute compiled

But I may be wrong on this point.  Maybe they actually use a name
substitution scheme which make them dependent on object files.

Anyway, what we should be concerned with is the intrinsic limitations
of their specification rather than their implementation.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]