This is the mail archive of the guile@sourceware.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]

initial modules.texi


greetings guile folks,

i've taken the liberty of appointing myself the module system scribe.
my role will be to document relevant discussion on this list as we
hammer out the module system design.  the way i see it, the process
includes: wishlist, criteria, debate and finally specification.  the
output of the process is documentation and implementation.  ideally,
very soon after things are Decided, both of these artifacts would appear
simultaneously.

towards the documentation goal, i've started modules.texi, appended
below.  you'll note familiar text in it since much of the process is
fueled by your words (i'm just the scribe).  once things are Decided,
i'll submit this in for inclusion as guile-doc/sources/modules.texi.
(i hope this effort is eventually worthy of CVS write privs.)

feel free to indicate in your posts to the mailing list or by private
email the suitability (or non-suitability) of any particular text for
this documentation.  by default i will aim for inclusiveness, w/ minimal
editorial impact, but please don't take an omission or a misconstrued
summary as a sleight of any kind; just let me know and i'll fix the
problem.

i'm also mildly open to input on the document structure, etc.  please
send such meta discussion to ttn@netcom.com directly, to avoid clutter
here.

thanks!
thi


----------------------------
@node Module System
@chapter Module System

@c Written by Thien-Thi Nguyen, self-appointed module system scribe,
@c with lots of help from members of the guile mailing list.

This chapter describes the module system.  As of January 2000, the module
system is still in design phase.

@menu
* Module System Interface::     
* Examples of Using the Module System::  
* Design Notes::                
@end menu

@node Module System Interface
@section Module System Interface

@node Examples of Using the Module System
@section Examples of Using the Module System

@node Design Notes
@section Design Notes

Because module systems design is an area of active research and development in
the Scheme community, many different features are possible.  This section is a
historical record of the selection process used by the Guile module system
developers.  See @xref{Module System Interface}, for programming information.

@menu
* Wishlist::                    
* Selection Criteria::          
* Rationale Statements::        
* Specification::               
@end menu

@node Wishlist
@subsection Wishlist

In the mailing list @code{guile@@sourceware.cygnus.com}, discussion resulted
in the following desirable traits.  Note that some of these contradict each
other.

@itemize @bullet

@item
support separate compilation

@item
hierarchical module names

@item
support relative references within the module name space (so that a
module within a package can use a sibling module without knowing the
prefix of the module name)

@item
support re-use of code (the same implementation can be presented to
the world through several interfaces)

@item
support individual and group renaming of bindings when using other
modules

@item
easy to import and re-export entire interfaces (so that a main
interface in a package can function as a "relay" and publish
bindings from many modules in the package)

@item
support both variable and syntactic bindings (these should be
clearly separated, though) and mesh well with hygienic macro
systems

@item
hygienic implies that we shouldn't need to care to export bindings
which an exported macro introduces at the point of its use

@item
autoloading

@item
unmemoization protocol

@item
cleanliness

A module should be able to be totally clean.  There should be no
need to have *any* extra bindings in a module (a la
%module-interface or `define-module').

Therefore, we should have at least one dedicated "command" or
"config" or "repl" module.

It would probably be a good idea to follow other good Scheme
interpreters' lead and introduce the ,<command> syntax for walking
around modules, inspecting things, entering the debugger, etc.
Such commands can be looked up in this repl module.

If we insist on not using ,<command> syntax, we are forced to let
the module use list consist of a "sticky" part and the rest, where
the "sticky" part is only available at the repl prompt and not to
the code within the module, and which follows us when we walk around
in the system.

@item
well integrated with the translator framework

We should be able to say that a module uses a different syntax or
language.

Note here the nice config language of the Scheme48 module system
where it is possible to separate code from module specification: the
module specification can use scheme syntax and rest in one file,
while the module itself can use the syntax of another language.

This config language also supports re-use of code in a neat way.

@item
examine connection with object system: how easy is it to support
Java and other class-centered object systems?

@item
easy to export the same module under several different names

@item
easily supports both compiled and interpreted modules

@item
compiled modules can by dynamically loaded or statically linked in
(libltdl might provide this automatically)

@item
convenient syntax for referencing bindings in modules that are
loaded but not used

(Assuming this distinction exists.)  But maybe group renaming is a better
solution to a similar class of problems.

@item
ability to unuse a module (and have it get collected when there are
no more references)

@item
orthoganality between source files, directories and modules. i.e.  ability to
have multiple modules in one source file and/or multiple source files in one
module

@item
backward compatibility

@item
whenever possible the module's meta-information should be stored
within the module itself (only possible for scheme files)

@item
the compiler stores the meta-information into a single file and updates it
accordingly

(FIXME: per module, per package, directory?, per project?)  This
meta-information should still be human readable (Sun's EJB use XML for their
deployment descriptors).

@item
use the file system as module repository

Since guile is a GNU project we can expect a GNU (or Unix) environment.  That
means that we should use the file system as the module repository.  (This
would help us avoid modules pointing to files which are pointing to other
files telling the user "hey, that's me (the module) over there".)

@item
every module has exactly @emph{one} owner who is responsible for the
module @emph{and} its interface (this contradicts with the "more than one
interface" concept)

@item
support module collections

Provide "packages" with a package scope for people working together on a
project.  In some sense a module is a view on the underlying package.

@item
ability to request (i.e. import or access) complete packages

@item
support module "generations" (or "versions")

Whenever a new module fails to handle a request (due to an error) it will be
replaced by the old version.

@item
help the user to handle exceptions (note: exceptions
are not errors, see above)

@item
no special configuration language (like @code{,in} etc.)

You can always press Control-D to terminate the module's repl and return to
the config module.

@item
both C and Scheme level interfaces

@end itemize

@node Selection Criteria
@subsection Selection Criteria

@node Rationale Statements
@subsection Rationale Statements

@node Specification
@subsection Specification

Most of the final specification for the module system is reflected in its
interface, @xref{Module System Interface}.  We include miscellany and
internals information here.

@c modules.texi ends here

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