[r6rs-discuss] [ANN] R6RS Libraries and syntax-case (van Tonder) implementation

AndrevanTonder andre at het.brown.edu
Tue Oct 30 11:09:06 EDT 2007

On Tue, 30 Oct 2007, Marijn Schouten (hkBst) wrote:

> AndrevanTonder wrote:
>>      R6RS Libraries and Syntax-case
>> implementation is available at:
>>     http://www.het.brown.edu/people/andre/macros
> This is a different library than what Abdulaziz Ghuloum announced recently,
> <http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/>?
> What are the differences?

As you noticed, there are currently two portable reference implementations
of R6RS libraries and syntax-case.  Even though they are both R6RS compliant,
there are indeed differences between them.  Aziz may have further comments,
but the differences that are known to me are the following:

  * The largest difference is in how identifier import levels are treated.
    The Van-Tonder implementation enforces declared import levels while the
    Ghuloum-Dybvig implementation does not.  In other words, the Van-Tonder
    implementation treats a reference to an identifier outside its declared
    import levels as a syntax violation, while the Ghuloum-Dybvig
    implementation ignores import level declarations, allowing references to
    identifiers outside their declared import levels.  Both models are allowed
    by R6RS.

    As a result, a working Van-Tonder library will be portable to the
    Ghuloum-Dybvig system, but a working Ghuloum-Dybvig library will
    not necessarily be portable to the Van-Tonder system.

    An advantage of the Ghuloum-Dybvig model is that some may find it easier
    to use.  Some may argue it to be conceptually simpler.  It may indeed be
    friendlier to newcomers, until they try to port their libraries to
    another Scheme implementation.

    An advantage of the Van-Tonder implementation is that it may make it
    easier to develop libraries that are portable.  The syntactic
    check on the import levels guarantee that a working Van-Tonder library
    will not fail on implementations that require identifiers to be used at
    their declared levels.  These implementations include MzScheme (PLT),
    probably Scheme48, and probably Larceny.  For example, if your library
    works in the Van-Tonder implementation, it is very likely to work
    in the MzScheme (expected R6RS) implementation, the expected
    Scheme48 implementation, and the expected Larceny implementation, all of
    which will enforce import levels, as well as the expected Chez
    implementation, which will not enforce them.

    Another advantage of the Van-Tonder implementation is that the
    programmer has more control over the availability of bindings
    in different phases.  For example, we can guarantee that syntax-rules
    will only be used at expand-time, and we can make sure in (rnrs base) that
    lambda, cons and car cannot be used on the right hand side of define-syntax.
    Such guarantees cannot be enforced in the Ghuloum-Dybvig implementation,
    which may be a problem in some situations (e.g., teaching).

    The Van-Tonder implementation is in fact very close to the model
    developed long ago by Matthew Flatt of PLT, with which there
    is a large amount of historical experience among the PLT
    user base.  For more details on the model and the design reasons
    behind it, see for example the article:

    Further http://citeseer.ist.psu.edu/flatt02composable.html

  * The Van-Tonder implementation has hooks for using R6RS libraries
    in a traditional interactive top-level (REPL).  Libraries can be
    defined at and imported into the interactive environment.
    Libraries can also be dynamically loaded using the LOAD procedure.

    I am not sure if the Ghuloum-Dybvig model provides REPL integration.
    Aziz may have more information on this.

  * The Van-Tonder implementation is compatible with incremental compilation.
    In other words, a dependent library can be compiled separately from the
    libraries on which it depends without needing the source of those
    already-compiled libraries to be present.

    Again, I am not sure if the Ghuloum-Dybvig model provides this.
    Aziz may have more information.

  * The Van-Tonder implementation does not use the mark-antimark
    expansion algorithm described in the R6RS, but instead it internally
    uses an algorithm based on explicit renaming that does not require
    syntax objects to be wrapped.  Indeed syntax objects in the Van-Tonder
    implementation are always s-expressions that can be deconstructed using car,
    cdr, etc.  The Ghuloum-Dybvig algorithm uses the mark-antimark algorithm
    that requires the input to a macro to be wrapped.  As a result, syntax
    objects have to be deconstructed using syntax-case.

    While the technical difference should not matter on R6RS syntax-case macros,
    the Van-Tonder implementation can provide some other macro APIs, such
    as "explicit renaming", more efficiently than the Ghuloum-Dybvig
    implementation can.  An "explicit renaming" library is indeed provided
    by the Van-Tonder implementation as a non-standard extension.

As you can tell, this is a somewhat biased account.  I will leave it to Aziz
to expand on the properties of his implementation.


More information about the r6rs-discuss mailing list