[plt-scheme] Structures added to MzLib

On Wednesday, March 19, 2003, at 07:43  PM, Paul Graunke wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> 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.
I haven't been able to come up with a less confusing name, so I stuck 
with the ML name.  Any suggestions?

> Are structures to support dromedary?  Are you (or others) planning to
> replace modules or units with structures eventually?
I implemented structures to support an SML compiler I am working on.  
Whereas Dromedary is only a teaching language, I aim to support most of 
the full SML language.
I don't think structures should replace modules or units and I am not 
aware of anyone who does.

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