Re: Recursive namespace

[Marius Vollmer]

Alex Shinn <address@hidden> writes:

> Of course, this makes compiler optimizations much more difficult.

I'm not sure.  First, I don't think we want aggressive, automatic,
unguided optimization across module boundaries anyway.

Exploiting knowledge about the internals of a module runs counter to
the purpose of a module.  We should have ways for the compiler to make
far-reaching decisions at compile time, but we should guide the
compiler with declarations.  We should say explicitely, "Compiler, it
is OK if you assume that FOO holds, hopefully it helps you produce
good code.  If FOO happens to be violated, that's my problem and I'll
live with the consequences."

The consequences can drastic, but should be safe, of course, like
failing to load a certain body of compiled code, complaining that its
interface assumptions are violated, or not picking up changes to a
function that has been inlined.  A violated declaration should not be
able to confuse Guile.

Even for a static, compile-time module system, we must make sure that
reasonable things happen, when a module that is used by another module
changes after that other module has been compiled.  Do we want to
force a recompilation of all modules that use the changed module?  I
don't think so, unless the user has declared that it will tolerate
that, in exchange for more efficient code.

I think we can provide the needed declarations for a static, as well
as for a dynamic module system, with little difference.


Oops, gotta run, more on this topic on request...