At Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen wrote:
> I tried the example you gave for my first question and it resulted in an 
> error.

Oops --- you're right. I lost track of what we try to make work at the
top level.

> I think this is because `(define-values (x) ...)` expands `...` without the 
> top-level-bind-scope, even when expand-context-to-parsed? is #t (according 
> to expander/expand/top.rkt). Is this a bug?

Since the behavior goes far back, I think this is the behavior that we
decided to settle for.

> Related to your answer to my second question, `define-syntaxes` similarly 
> does not add the top-level-bind-scope when expanding `...`. Does this mean 
> that even for `define-syntaxes`, `...` won't use the top-level-bind-scope 
> binding(s) after all?

The way that evaluation, binding, and expansion are interleaved means
that a `define-syntaxes` macro can refer to itself in expansions. The
binding of an identifier in a macro template is resolved after the
macro is applied.

The difference with `define` is that the right-hand side is
expanded/compiled before `define` binds.

> A little bit off-topic, in the definition of define-values (in 
> expander/expand/top.rkt), there is `(define-match m s ...)`, but for 
> define-syntaxes it is `(define-match m disarmed-s ...)`. Is this difference 
> significant? Or does define-match not care whether `s` or `disarmed-s` is 
> used?

Using `disarmed-s` in the definition of `define-values` is probably
a better idea, and I'll look into that more.

It think it turns out not to matter, normally, because `define-values`
is transparent to syntax arming via `syntax-arm` with a #t second
argument (which is what the expander does). But it would be better to
not rely on that.

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit

Reply via email to