[Chicken-hackers] What to do with default modules?

[Peter Bex]

Hi all,

Now that we have a 5.0.0pre4 development snapshot, I wanted to clean up
some stuff.  The most important cleanup is the mess of toplevel symbol
definitions at the end of library.scm.

I noticed that if I remove that, the environment for "eval" is empty.
It turns out that the default eval environment used to contain the
identifiers from scheme and chicken, but that was sort-of by accident,
because they were available on the toplevel.

In "csi" we now explicitly perform these two imports:
(eval `(import-for-syntax ,@default-syntax-imports))
(eval `(import ,@default-imports))

I tried putting these two at the end of eval.scm, which worked (we could
then get rid of these in csi.scm).  Unfortunately this breaks the tests,
because the (import)s cause the import libraries for "chicken.base" and
"chicken.syntax" to be loaded dynamically, but that's not available when
the binary is compiled statically.  Scheme is built-in to modules.scm,
so that doesn't require loading an external library.

Now I see two basic approaches:
- We remove the chicken.base.import.scm and chicken.syntax.import.scm
   files and move the definitions into modules.scm, like we do for
   "scheme" and a plethora of srfi modules.
- We figure out if we can link these import files into libchicken.

Both of these raise the question if we should also do that for other
modules, and if so, how to decide which ones?  Note that chicken.syntax
is not from library.scm, so we could also decide to remove this from the
default eval imports instead, because otherwise you can't link a
custom-built binary without the "expand" unit.

A third approach would be to keep the toplevel definitions, but I think
that's not really an option.  That would be too much of a mess and
asking for trouble.  Sometimes it might even be desirable to have a
completely empty toplevel (like with -explicit-use).  Just having the
imports clearly indicated is much better.

One small concern: How big will the import library tables be?
In CHICKEN 4, symbols are at toplevel and if we don't load any import
libraries, the symbols are directly bound to their values.  In the
approaches I describe above, we add to that more alists for the modules,
plus extra (longer, because prefixed with "chicken.base#"!) symbols.
I'm not sure this is even worth thinking about (especially now we can
GC any other symbols much better), but I just wanted to point it out.

Cheers,
Peter

signature.asc
Description: PGP signature