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.
Andre
Received on Tue Oct 30 2007 - 11:09:06 UTC