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

From: Abdulaziz Ghuloum <aghuloum>
Date: Thu Nov 30 12:26:44 2006

On Nov 29, 2006, at 1:03 PM, Andre van Tonder wrote:

> On Tue, 28 Nov 2006, AndrevanTonder wrote:
>
>> On Tue, 28 Nov 2006, Abdulaziz Ghuloum wrote:
>>
>>> On Nov 28, 2006, at 9:28 AM, AndrevanTonder wrote:
>>>> This seems to be an example where negative phases are
>>>> unavoidable in phased models.
>>> Splitting the library into two components was also unavoidable,
>>> wasn't it?
>>
>> I believe so...
>
> 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.

If you reread the code I posted (the second post), it should be
obvious that the tracer library is used *only* at compile time. None
of its bindings escape to the runtime code. The tracer-helpers
library is, similarly, a run-time only library. There was no mixing
of the two levels; nor was there any need for negative levels. But
anyways ...

In the paragraph above, you distinguish between "ground language" and
"meta language" as two separate languages with potentially different
and incompatible semantics. When I look at Scheme code that looks like:

(define f0
   (lambda (x0)
     (define-syntax f1
        (lambda (x1)
           (define f2
              (lambda (x2)
                 (define-syntax f3
                    (lambda (x3)
                       ...))
                 ...))
           ...))
     ...))

then it is obvious to me that I'm programming in Scheme all the way
up with lambdas at run, expand, meta 2, meta 3, etc. These Scheme
forms can nest arbitrarily deep. They can also be automatically
generated with using macros (procedural or not). Forcing me to
*guesstimate* how many levels I *may* need is a burden to me. This
is no better than asking me to specify how many recursive calls my
program may make. Scheme is the language of no arbitrary
restrictions (not on procedure calls, not on number of arguments that
procedures may take, not on how many levels deep you can curry a
function, and not on how many levels deep you can nest expressions).
The forms of the language are inductively defined. Why would macros,
all of a sudden, require me to specify how many levels deep they will
be allowed to nest, and thus break a fundamental property of the
language?


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

And I like having a static type system that can help me keep my types
straight, with static guarantees, by forcing me to be explicit about
them. Well, sometimes. When I need to add restrictions on myself, I
know how to do that. And if I wanted languages with restrictions, I
know where to find them. But I program in Scheme because it is one
of the few languages that do *not* force me to do anything their way;
but I can always have it my way.


> I know you guys have different applications in mind, for which you
> have argued these constraints not to be relevant, and I am not
> disputing that.

I did not argue the relevance of the issue. On the contrary. This
argument is the heart of the matter. You may like to see these
restrictions added the language. I would like to see Scheme remain
restriction-free. All we can do is argue our cases and leave it to
the judges to decide. :-)

Aziz,,,
Received on Wed Nov 29 2006 - 21:40:44 UTC