[plt-scheme] Structures added to MzLib

From: Scott Owens (sowens at cs.utah.edu)
Date: Wed Mar 19 18:03:08 EST 2003

I have added a structure form into MzLib in the CVS repository.  The 
documentation will be merged into the MzLib documentation soon, but 
until then, here is a preliminary version of the documentation:


Structures are convenient scoping constructs that allow fine-grained
control over binding visiblilty.  Structures have no run-time component,
they are entirely expansion-time entities.  These structures correspond
to the untyped part of structures in the ML language and the module
construct of Chez Scheme (which is itself based on ML structures).

The _structure.ss_ module provides the following syntactic forms:

 > (structure name (export ...) body ...) > (structure name provide-all
body ...) > (open path) > (open-in-context identifier path) > (open-as
identifier path field) > (dot path field)

Where name, export and field are identifiers.  Path is a non-empty list
of identifiers. Body may be any scheme expression, or of the form: >
(define-values-ml (identifier ...) expression) > (define-syntaxes-ml
(identifier ...) expression)

A (structure ...) form may appear anywhere a (define ...) form can
appear, including inside of other structures.  The structure form binds
its name as syntax in the scope where the structure expression appears.
This is similar to the (define-struct a ()) form that defines a as
syntax.  The sequence of expressions inside of a structure may include
regular Scheme definitions which behave as usual, or (define-values-ml
...) expressions which behave as the usual define-values expressions,
except that the identifiers to be defined are not in scope in the
right-hand-side of the definition, thus define-values-ml is a
non-recursive definition form.

A path identifies a particular structure.  The first identifier in a
path must be the name of a structure visible in the scope of the path.
Each subsequent identifier in the path must be the name of an exported
structure that is nested inside the structure specified by the previous
elements in the path.

The (open path) form may appear anywhere a (define ...) form can appear.
The open form places all of the identifiers exported from the structure
indicated by the path into the context of the open expression (the
binding context of the first identifier in the path is used).  A
structure cannot be opened in the same scope that it was defined in,
unless that scope is a top-level scope. For example,
(let ()
   (structure a provide-all ...)
   (open a))
(structure a provide-all
   (structure b provide-all ...)
   (open b))
are both illegal.

The (open-in-context identifier path) is just like an open expression,
but the exported identifiers are placed in the context of the given
identifier, which is not otherwise used. This form can be necessary in
the implementation of a macro that expands to an open.

The (open-as identifier path field) expression may appear anywhere a
(define ...) expression can appear. The field of the structure indicated
by the path is placed in the identifier's scope with the name of the

The (dot path field) form may appear anywhere a Scheme expression can
appear. It returns the value of the specified field from the structure
indicated by path.

Known Bugs:
The check syntax tool in DrScheme does not do anything useful with
structure bindings.

Posted on the users mailing list.