[plt-scheme] Structures added to MzLib

Isn't "structure" a confusing name given that we have define-struct
already?  I know the name comes from ML, but it's still confusing.

Are structures to support dromedary?  Are you (or others) planning to
replace modules or units with structures eventually?

Thanks,

Paul

At Wed, 19 Mar 2003 16:03:08 -0700, Scott Owens wrote:
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> 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:
> 
> _structure_
> 
> 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))
> and
> (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
> identifier.
> 
> 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.