Re: moving guile-core stuff into dynam. modules

[Tel <telford@eng.uts.edu.au>]

> What does one have to do in order to move a module that is currently compiled
> into the guile-core from there into a dynamically loadable module? Some
> here already complained that the core is too much bloated with stuff that
> should not go there, like sockets etc. and most other non-r*rs stuff.

OK, I know I shouldn't say this because it has already been said so many
times but the first thing that you need is a _working_module_system_.
Perhaps one answer is to go for the simplest possible method and
provide a system for adding stuff to the base namespace only. This in itself
would be good enough for many applications and would give new users an
easy way to get into the action without stressing over a lot of details.

A few well chosen hooks installed in the base code could then leave the
door open for development of fancier layered namespaces and objects and
other things that go beyond R4RS. These hooks could either be C variables
that point to functions or some key symbols defined in the base namespace.
This would allow steady and thoughtful development of extensions to R4RS
with less pressure from people who's main requirements are `functional'
and `simple' (like myself).

	- Tel

PS: look at what is happening in libguile/init.c as guile jams various
    chunks of itself into its base namespace. This is roughly the technique
    that I have been using to jam things into the base namespace but I'm
    using gh_new_procedure(). Theoretically, files such as libguile/posix.c
    could be in their own DLL and could be activated when required by
    calling init_posix() same as what happens in libguile/init.c

    For the time being I'd completely avoid things like scm_add_feature()
    until they have a well-defined meaning.

	- Tel