I have done some further digging. Looks like it is non-trivial to remove the top-level-bind-scope and still preserve the current behaviors of top-level `define-values` and `define-syntaxes`. In particular, through `as-expand-time-top-level-bindings` in "expander/expand/bind-top.rkt", both top-level `define-values` and `define-syntaxes` use `select-defined-syms-and-bind!/ctx` from "expander/expand/def-id.rkt", which selects variable-symbols and binds them at the same time. So after a variable symbol is selected, a binding must be created for it. For top-level `define-values` and `define-syntaxes`, using the top-level-bind-scope for that mandatory binding is necessary to achieve the current top-level behaviors. On the other hand, uses of the top-level-bind-scope that are related to `#%top` (such as in "expander/expand/expr.rkt" and "expander/expand/main.rkt") appear to be non-essential, but may offer minor performance advantages (really not sure).
On Tuesday, March 24, 2020 at 2:15:32 AM UTC-4, Yongming Shen wrote: > > Hi Matthew, > > Thanks for the explanations. But I'm still not convinced that the > top-level-bind-scope is needed. This is my current understanding. The > purpose of the top-level-bind-scope is to support recursion better at the > top level. But for the case of `(define-values (x) ...)`, if `x` is not > defined yet, then implicit #%top in `...` will let `...` refer to `x`. If > `x` is defined, then the old definition will be used by `...`. Either way, > the top-level-bind-scope is not needed. For the case of `(define-syntaxes > (x) ...)`. As you explained, a macro can naturally recursively refer to > itself, simply because of how macro expansion works, so the > top-level-bind-scope is again not needed for recursion. Is my understanding > correct? > > > On Monday, March 23, 2020 at 10:05:12 AM UTC-4, Matthew Flatt wrote: >> >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/09bf14a5-1c1c-4718-80d7-c4414bf98d52%40googlegroups.com.
