[r6rs-discuss] [Formal] Trivial Enhancement of macros in v5.91: capture-syntax

From: William D Clinger <will>
Date: Wed Nov 29 20:03:34 2006

I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors, and
this message should not be confused with the editors'
eventual formal response.

AndrevanTonder wrote:

> By the way, this is for me a feature, given the kinds of things I am
> interested in doing with libraries. The inadvisability of mixing code
> in the ground language and code in the meta-language at the same
> apparent syntactic level in an unsplit library becomes obvious once I
> call my ground language Java and my meta-language Scheme, or call my
> ground language Lazy Scheme and my meta-language Scheme. I like having
> a library system that can help me keep these distinctions straight,
> with static guarantees, by forcing me to be explicit about them.

If you program in Java, but write your procedural macros
in Scheme, then you have a fairly good static guarantee
that no procedural macro will take some of your Java code
and try to execute it at macro time without some kind of
marshalling when values are communicated between the two
languages.

The draft R6RS provides no such guarantee. There does not
appear to be any way to write a library in draft R6RS Scheme
that can protect itself against being executed at macro time.

That means I cannot write a reference implementation for R6RS
arithmetic that guards against a procedural macro that creates
a macro-time bignum and tries to insert it as a quoted constant
into the macro-expanded code. That is an example of the mixing
both of us deplore.

Requiring a separated binding semantics almost guarantees that
this undesirable mixing will occur. Requiring a shared binding,
invoke-once-per-session semantics isn't all that great either,
but it would at least guarantee that the bignum created at macro
time would make sense as a quoted constant in the macro-expanded
code.

Will
Received on Wed Nov 29 2006 - 19:02:32 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:00 UTC