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

[Abdulaziz Ghuloum]

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