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] |
Telford Tendys <telford@eng.uts.edu.au> writes: > 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. When we get the module system and have factorized Guile, it will of course be a simple thing to choose which modules should be pre-loaded. I say this only to indicate that there is no hurry in the debate over this question---the design of the new `set!' won't be affected. Also, it is not yet decided exactly what code should be pre-loaded and what should not. What I say below is not the developers' policy, but my own view only. It seems clear that there should exist a pure RnRS module. Could we, in fact, let libguile be only an RnRS module? No. In order to implement the RnRS functionality with an internal architecture which allows efficient extension to the basic features that we want Guile to support we need code which can be "published" and is useful on the Scheme level in its own right. Example: The predicate `thunk?' is used internally for argument checking, but can be useful in user programs, so it is published as a Scheme procedure as well. Another example is the machinery around error handling, like `catch' and `throw'. Also, there is some basic extra functionality which is useful enough to grant a place in the "standard" Guile language and therefore should be distributed with libguile. Examples: `defined?', `getenv', records. So, libguile should clearly consist not of a single module, but of a set of modules. But then one could still have the RnRS module as an initial environment, and let the user choose what other modules to add, no? One goal of Guile is to be a practical Scheme implementation. It is aimed at using Scheme in applications. The core Scheme functionality is too small to be useful directly in applications programming---it needs to be complemented by library functions. Now, most libraries should of course be explicitly loaded, but I would get mad if I had to load the list module every time I wanted to remove an element in a list with the `delq' operation. I think `delq' is an example of an operation which should belong to a core Guile language. In practise, we could decide what operations apart from the RnRS ones which should belong to the practically useful core Guile language, and put them (or import them) into a `guile-extensions' module and import and reexport the bindings in the `RnRS' and `guile-extensions' modules from the `guile' interface. There is a third thing to consider: The needs of a program are different than the needs of the user regarding the environment. The user needs to easily set customization options or use session support utilities like `apropos'. The program doesn't need this. Therefore, my view is that there should be bindings imported from a session support module as well, so the default bindings in an interactive session should come at least from three different modules: RnRS, guile-extensions and session-support. Given that we support generalized locations a la new `set!', I think they should belong to the core language. Regarding OO extensions: There is only some minimal OO support required in libguile, and none of this needs to be visible at the Scheme level. This minimal support (like a few lines extra in eval.c) is needed in order to support a fast OO system. /mdj