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] |
> > 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