[plt-scheme] Some syntax issues

> I'm trying to define a macro that expands to the definition of a macro
> that expands to use a "private" variable that is visible nowhere else.
> Here's a simple example:
> 
>   (define-syntax (define-thingy stx)
>     (syntax-case stx ()
>       ((_ macro-name)
>        (with-syntax ((var-name (syntax-local-introduce 
>                                 (car (generate-temporaries #'(macro-name))))))
>        #'(begin
>            (define var-name 11)
>            (define-syntax (macro-name stx2)
>              (syntax-case stx2 ()
>                ((_ a) #'(set! var-name a))
>                (i (identifier? #'i) #'var-name))))))))
> 
> In drscheme this seems to work fine, but in mzscheme this causes a
> segfault.

Obviously a bug. Fixed now in the exp-tagged sources.

> Still, this seems a bit awkward. Is there a reason why
> generate-temporaries gives doesn't give the generated identifiers the
> same syntactic context as its arguments? Now pure generate-temporaries
> -generated identifiers are fairly useless, since their context doesn't
> have #%top bound...

They're useful for `lambda' and `let' bindings, which was the original
intent, I believe.

Generating top-level variables is a tricky business. It still doesn't
work quite right even in the `module' world, though I think I know how
to improve things in the next iteration.

> Also, I don't much like the fact that I have to use manually generated
> unique identifiers. Hygienic macros are supposed to liberate us from the
> endless gensyms of defmacro. 

Agreed...

> Is there any cleaner way of defining a
> variable that is to be used only from a macro?

I don't know. I hope so, but I haven't quite found it myself.

Top-level variables are different from local variables in a fundamental
way: you can't see all of the uses from the definition site. (This
difference is true of `module'-bound variables, too, and it's why they
tend to be treated more like top-level variables than like `let'-bound
variables.)

> So here's what I propose: add syntax object support to the "regular"
> pattern matcher.

I'll look into it, though probably not soon.

However, I'm not sure that `syntax' is dead. Originally, I though of
making #`, etc. expand to `quasiquote-syntax', in parallel to
`quote-syntax'. After trying it out, I went with `quasisyntax', etc.

> The only real feature that syntax-case has and match doesn't is
> ellipsis. But I for one use ellipsis very rarely with syntax-case.

That's interesting. I think I almost always use ellipses in a
`syntax-case' expression.

> Oh, one final question: what's the easiest way to reload a module from a
> REPL after modifying the file where it's defined?

Good question, and I don't have a good answer (i.e., I don't have an
easy way). The "cm.ss" infrastructure will likely move in a direction
that makes it easier.

Matthew