guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading Guile `Extensions'


From: Marius Vollmer
Subject: Re: Loading Guile `Extensions'
Date: 20 May 2001 19:22:25 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

thi <address@hidden> writes:

>    From: Marius Vollmer <address@hidden>
>    Date: 20 May 2001 03:07:27 +0200
> 
>       Normally, there is no pre-registered function.
> 
> there used to be scm_register_module_xxx (or something like that).  this
> was deprecated and now another standardized programming interface is
> being proposed.  could you compare this approach with the previous one?

With scm_register_modules_xxx you would register a function for
initializing a module, while with scm_register_extension, you register
a function for initializing some arbitrary body of code, that does not
need to have any relation ship to a module.

The latter approach is more modular and as a consequence simpler to
describe and understand.  It decouples the act of getting compiled
code into the running process from how it will be made available as
modules, if at all.  It decouples library names from module names, and
makes it more obvious how to put multiple modules into a shared
library or how to compose one module from multiple shared libraries.

Basically, didn't want the module system to autoload shared libraries
any longer.  We felt that that would be too smart and wanted to put
the user more into control.  We also didn't want to have too much
explicit module system operations in C.  That resulted in the
recommendation to implement the module skeletons in Scheme and use
explicit dynamic-call/dynamic-link to fill them with bindings.

Then I convinced myself that the dynamic-call/dynamic-link combo
deserves to be abstracted into a single operation, `load-extension',
and on the way we could solve the problems of people who want to use
static linking for their or other peoples extensions.  Libtool has
support for hiding the non-existence of dynamic linking, but it feels
hairy to me.  `scm_register_extension' is also a very simple thing.

> i wanted to raise this kind of flag when identity -> id -> identity,
> but it seemed sort of too trivial to bother.  however, C integration
> (esp., in light of a scheme-defined module system) is more of a pain
> for people to jump through hoops for, so (externally visible)
> interface changes should be of substance (reflecting substantial
> changes in semantics) and not merely cosmetic.

I understand your position and I think I do have a resistance to
changes myself.  However, even mere cleanups are of importance in my
view since a fissured and fractal API has technical disadvantages
compared to a clean and `orthogonal' one.  I think with the
deprecation machinery, we have a way to transition people quite
smoothly.

But, you are very right, flip-flopping between alternatives at a high
rate, where it is not clear which alternative is better, speaks of
poor judgement and organization.

Many different people have hacked on Guile in its history, with no
single strong guiding hand and I think this shows.  Recently, a good
number of people have joined the development which are very much
interested in cleaning up what we have and building a solid
foundation, instead of tacking on yet another fancy feature.  I don't
think we should try to stop these kind of contributions, they are very
important for Guile.  Already, the maintenance problem of the
evaluator are legendary, or the hair when using the pre-cleanup type
predicates (when you had to know when to insert an extra SCM_NIMP).
The module system was tacked on in a clever but peripheral way, which
lead to inelegancies in the symbol and variable APIs of Guile.

Well, I don't think I really need to defend the recent cleanups with
their assorted API changes here.  The real problems arise when these
cleanups are uncoordinated and lead to gratuitous changes that are
hard to understand.  We must try hard to follow a clear and straight
line when changing the API of Guile.  I'm not saying we are very good
at that, but I hope we are at least acceptable.

Careful auditing by old-timers can help a lot, I think.

Ok, well, I didn't mean to rant on you.  Just to show that I do care.
Err.

> being able to thrash the programming interface is the developer's
> server-given right, no doubt, but gratuitous breakage w/ little
> functionality gain is less than optimal.  people who must change code
> to keep up w/ the interface-of-the-week game will mark the development
> team as immature -- guaranteed.

Yes, maybe it's even the truth.  Maybe I (foremost) are immature when
it comes to turning principles into practice.  So any specific advise
is very welcome.

Should we un-deprecate `id'?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]