Re: [Chicken-hackers] simplifying loading/linking/import (long)

[John Cowan]

Felix Winkelmann scripsit:

> * "import" incorporates bindings into the current environment, either
>   globally or inside another namespace (module). We want to
>   _automatically_ make the code associated with that namespace
>   available, regardless of the nature of the compilation unit that
>   contains that code. Is this interpretation correct?

That's what I'd like to see, yes.  However, there are certain perverse
circumstances in which it won't work.  For example, if "a.scm" includes
module "b" and vice versa, then neither (use a) nor (use b) will succeed,
although it is possible to get both modules loaded and imported by messing
with the low-level operations.

Use (and its synonym require-extension) essentially involve loading a named
body of code and importing a module of the same name.  If either of those
operations fail, `use` fails.  But it does not require that the code loaded
actually provides the module!

> * The last 2 points are important if we want to support static
>   linking. Loading is in this case the simpler operation, as the
>   entry-point always has the same name. For static linking the
>   entry-points need to be named differently (there might be ways
>   around this limitation, but to keep things simple, let's not
>   consider that right now.)

It seems easy to provide them with unique entry points for static
purposes, provided the name of the entry point can be deduced from the
name of the loadable chunk.

> * So, if we create a "registry" of linked/loaded compilation units,
>   "import" can consult this registry and check whether a compilation
>   unit of the same name is already registered and, if not, default to
>   loading a ".so" or ".scm" with the same name. If the latter is not
>   found, we have an error. If it is found, add it to the registry.

Just so.

> * "import" incorporates bindings from a set of available modules, also
>   registered somewhere, specifically in ##sys#module-table. Should it
>   also handle compilation-units for which no bindings exist (i.e. all
>   bindings are unqualified)? This is only useful at toplevel, or, in
>   other words, not inside a module. This will also bring up the
>   question whether such a behaviour might lead to head-scratching in
>   case a module should exist, but the binding-information is
>   unavailable for some erroneous reason.

The obvious reason would be a failure to compile with -j or -J.  It's
probably surprising to newbies that it's not enough to write (module foo
...) in a file "foo.scm" and then say "(use foo)" at the REPL; you have
to compile "foo.scm" with -J at the very least.

> 
> * libchicken contains a number of entry-points, one for each library
>   unit that comes with the core system. The registry must already have
>   entries for these. Users might want to have to use a similar
>   physical structure of their code, so we will have to provide means
>   to add "default" registry entries, I think (I'm not completely
>   sure right now - the resolution of the entry-points happens
>   automatically by the linker, but we have to make later "import"s
>   aware of this.)

IMO this should be a special case for libchicken.  I see no reason why
ordinary users should bundle multiple modules into a single .so file.

> * Currently "(declare (unit ...))" calls the entry-point,
>   _initializing_ the compilation unit. Later "import"s will just
>   incorporate the bindings. Do we want to initialize the compilation
>   unit on the first "import"? If yes, we need to separate the notions
>   of declaring an externally available entry-point and calling it, the
>   latter being done (we hope) transparently by "import".

Well, that is what `use` already does, no?

-- 
John Cowan          http://www.ccil.org/~cowan        address@hidden
Principles.  You can't say A is made of B or vice versa.
All mass is interaction.  --Richard Feynman