Re: [Chicken-hackers] [PATCH] Fix #1133

[Felix Winkelmann]

> I've replaced extras by ports to fix the dependency stuff.  I think it's
> time we started making a more concrete plan on how to make the core
> system use proper modules instead of "units", while still maintaining
> separate compilation of course!  If we use modules, this kind of bug
> will be easily detected because the module refuses to compile.  It will
> also make the system cleaner in general because names won't "leak out"
> unless explicitly imported.  Anyway, this is a long-term project that
> will probably require fixing #1131 (kill ##sys#alias-global-hook) first.

A few remarks:

- Modules are a namespace-specific concept, units are a
  loading/linking concept. Are you really comparing these here?

- The possibility of static linking needs to be preserved. Units
  provide static entry-points for compilation units, which will be
  needed for this. Static linking can currently not be simply dropped
  because of the restrictions that mobile OSs have (android with its
  fixed table of dynamically loadable libraries, iOS with its complete
  lack of dynamic loading).

- The module system is currently optional - one can just use core
  procedures in a toplevel program without using modules at all.  The
  machinery to make this work is admittedly ugly, but still I consider
  it a feature. Forcing pervasive use of modules is noit by itself a
  bad thing, but need to be thought out thoroughly.

- It's possible that I misunderstand your intentions, considering the
  many meanings of the word "module" used in this context. But another
  issue that comes to mind is bootstrapping: if you change the
  imports/exports of a module that represents a core library unit, how
  can we prevent screw-ups due to mixing up of the
  import/export-information (import libraries) between the chicken
  that compiles and the chicken that is compiled? This can get very
  tricky.


felix