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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/09bf14a5-1c1c-4718-80d7-c4414bf98d52%40googlegroups.com.
