Re: Missing core functions

[Gary Houston]

> From: Martin Grabmueller <address@hidden>
> Date: Tue, 06 Mar 2001 09:15:22 +0100

> > To reduce the perception of code bloat it's probably about time to
> > place the system call wrappers into separate modules.  This can be
> > done without moving them out of libguile -- see the (ice-9 rdelim)
> > experiment.
> 
> With `code bloat' I meant the actual size of libguile, what do you
> mean?  The number of primitives available without using modules?

More or less the same thing, but moving code into separate modules
makes it easier to reduce the size of libguile where this is actually
useful.  e.g., maybe it would be possible to add configure options
to change the default choice of which modules are included in libguile
and which modules are built at all.

I'm not convinced that it's worth giving every module with compiled
code its own shared library in the default installation.  For modules
that are almost always used, it probably just increases start up time
and memory usage.  However the guy running guile on a router may find
it useful to be able to change the default.

Moving code into modules has another benefit that it could reduce the
backwards compatibility problems that interpreted scripts tend to
suffer when upgrading the interpreter.  Modules could be renamed when
the behaviour changed incompatibly and old versions placed in a
guile-compat package.  It's better that a script fails immediately
with a module-not-found error than to fail in a branch that's only
taken when the circumstances are already dire (the last step before
router-core-meltdown perhaps.)

> > When adding new interfaces it's a good time to consider what modules
> > could be created, since there's no backwards compatibility problem
> > with requiring a use-modules statment.
> > 
> > > Otherwise, I would like to implement them.
> > 
> > That would be great.  Good luck with ioctl.
> 
> I thought about snarfing some of the ioctls from the system headers as
> with the signal and error numbers and then support some of the ioctl
> calls available under Linux and Solaris (the systems I have access
> to), but now that I visually grepped thru the headers I must admit
> that it probably was not a good idea.
> 
> Now I think that if someone needs a Scheme wrapper for a particular
> ioctl, she is better served by writing a small shared object Guile
> module and implementing it in C herself.  This is not difficult and
> someone dealing with ioctls is probably clever enough to do that.
> 
> In case someone thinks ioctl in Guile is a good idea anyway, please
> tell me and I will think more about it.  Another option is to make
> such a C module and include it as an example/in the documentation.

The libffi/ffcall technique would be another option.