@vishesh or @soegaard2: Do you understand what this person has in mind? If so, could you maybe please chime in, there or here? (If not, no worries.) Thank you. https://github.com/greghendershott/frog/issues/215

@mflatt Another data point: this program produces #<syntax x> on Racket 7 (which would turn into an unbound identifier error if left to expand further) but #<syntax values> on Racket 6. #lang racket (begin-for-syntax (define x-id #'x) (define y-id #'y) (define intdef-ctx-a (syntax-local-make-definition-context)) (syntax-local-bind-syntaxes (list x-id) #'(make-rename-transformer #'values) intdef-ctx-a) (define intdef-ctx-b (syntax-local-make-definition-context intdef-ctx-a)) (define x_a-id (internal-definition-context-introduce intdef-ctx-a x-id)) (syntax-local-bind-syntaxes (list y-id) #`(make-rename-transformer #'#,x_a-id) intdef-ctx-b) (println (local-expand y-id 'expression '() intdef-ctx-b)))

@lexi.lambda Which behavior do you think is better in the long run?

After some consideration, I think the Racket 6 behavior is better. It better reflects how the expander reasons about nested definition contexts, since the bindings from surrounding definition contexts should always be in the local binding context when expanding nested definitions, and that behavior should be decoupled from the implicit introduction of internal-definition contexts’ scopes. As far as I can tell, the implicit introduction of the bindings essentially has no downsides—that is, the user would never want or need to opt out of it—precisely because it does not add any scopes and thus only turns out-of-context uses into in-context uses. The only potential downside (and this is a stretch) is that parent definition contexts might not be able to be GC’d as early, but that seems irrelevant given most uses of definition contexts in this way would need to retain the parent contexts, anyway.

In any case, implementing the Racket 6 behavior is not hard. I have done it on a branch, and I’m just working on tests and documentation. I’ll open a PR soon.

Ok, good!

Alright, opened a PR here: https://github.com/racket/racket/pull/2053

@mflatt Could I ask you for your input on this? https://github.com/racket/racket/issues/2052 I think being able to do something like this would be able to solve two problems I currently have (one in Hackett, one elsewhere), but I understand why syntax-local-lift-require as it currently works doesn’t make sense in a 'module-begin context (since there’s nowhere to lift the #%require to). In theory, though, it seems like it would be possible to add the scope/bindings and then arrange for the #%require to be inserted after #%plain-module-begin is exposed, which seems like it would solve the problem. I don’t know for sure, though.