This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

O-O in guile (Re: Suggestion: New Guile mailing list)


> >  I don't much care about O-O extensions to Scheme, because I think
> > it works fine without them, and because they are a subject of much
> > obscure argument with no theorem at the end.  I do care about Guile,
> > and would hate to see it crufted up.
> 
> We'll minimize extra cruft.  However, object orientation is an
> important and useful programming paradigm, so it is clearly worth the
> sacrifice of a few extra bytes in libguile.

Just to add my push, the really really important thing is the module
system. If this happens to also provide foundation for O-O extensions
then well and good but it must at least provide a clean way of separating
namespaces so that people can get on with publishing extension libraries.

Once that is done we could support a dozen different paradigms, all in
on-demand libraries and none of which pour cruft on those that don't
want them. Getting the module system operational and documented and usable
is far more important than any other particular extension.

> When the new module system arrives and Guile is factorized, there will
> be an RnRS module.  That will contain a "pure" `set!'.  The default
> user environment in Guile will however include additional modules
> which will export the extended `set!'.  The module system facilities
> should make it possible to use the pure `set!' if that is the user's
> wish.

Doesn't this sound a bit backwards? Surely the default situation with
no modules loaded is to get the most pure and primitive behaviour.
I expect that new users are easily enough confused without telling them
that you have to load extra modules in order to get less functionality.

I can understand gcc having a ``strict ansi'' flag (that reduces the
extended functionality) with extended being the default -- the difference
is that gcc is not a modular system but guile (hopefully) will be.

Maybe part of what the module system must address is a bootup time
method of specifying which set of modules should be automatically loaded.
This would allow an application to specify which modules it feels are
suitable and which are not. This could allow a common interpreter to
be a lot more flexible with respect to a range of applications.

> Since the new `set!' is a natural generalization of the "pure" `set!'
> it is natural to give it the same name.
> 
> What we get with the new `set!' is a useful and natural generalization
> of `set!'  at low cost of implementation with few restrictions on the
> interpreter and compiler and which is possible to compile to efficient
> code.

Sounds good to me, I'm not against extensions it is just the *core* that
should be as simple as possible and the *extensions* that get added on by
those who see them as useful.

Also, putting the extended set! into a module allows those particular
extensions to be documented in a logical place rather (i.e. under that
module heading) rather than producing a hacked up version of RnRS with
extra ifs and buts.

	- Tel