The way to remove scopes is via make-syntax-delta-introducer, but it does sound like quasisyntax was the wrong tool to start with in this case. I’m not clear on what scopes you mean to add (on which subforms) and which ones are unwanted.

Personally, on MacOS, I merge consecutive wheel events into one (by adjusting wheel-step) in every 200ms, though the overall performance of DrRacket is still much slower than on Linux, it do avoid the unresponsive problems while scrolling large files.

@samth the reduced version from 2569, was this generated using demodularize + full expand?

That’s generated from the extraction tool used for bootstrapping the expander (see racket/src/expander/README)

Will take a look, thanks.

@mflatt Is this behavior a bug? This program: #lang racket (parameterize ([current-namespace (make-base-namespace)]) (eval '(module m racket (define phase-0-mod-path (resolved-module-path-name (variable-reference->resolved-module-path (#%variable-reference)))) (define-syntax (quote-phase-1-mod-path stx) #`'#,(resolved-module-path-name (variable-reference->resolved-module-path (#%variable-reference)))) (define phase-1-mod-path (quote-phase-1-mod-path)) (printf " mod-path @ 0 = ~v\n" phase-0-mod-path) (printf " mod-path @ 1 = ~v\n\n" phase-1-mod-path) (printf " mod-paths equal? = ~v\n\n" (equal? phase-0-mod-path phase-1-mod-path)) (printf "mod-path interned? @ 0 = ~v\n" (symbol-interned? phase-0-mod-path)) (printf "mod-path interned? @ 1 = ~v\n" (symbol-interned? phase-1-mod-path)))) (eval '(require 'm))) prints: mod-path @ 0 = 'm mod-path @ 1 = 'm mod-paths equal? = #f mod-path interned? @ 0 = #t mod-path interned? @ 1 = #f I don’t have any idea if this is a bug, intentional, or unspecified behavior, but it is a little confusing.

It also seems like it’s different from Racket 6.12, since on Racket 6.12 the paths are equal? (both are interned).

@lexi.lambda It’s intentionally inconvenient. A compile-time module path does not necessarily have anything to do with the run-time module path. The new expander uses an uninterned symbol that prints in a useful-for-debugging way but is meant to be consistently different from the run-time name.

Got it, that makes sense. It came up when I was writing tests for https://github.com/racket/racket/pull/2554, and I wanted to make sure the right module was blamed, so I am looking at the value inside the blame-positive field of a blame object. I ended up doing this: https://github.com/racket/racket/blob/660107e0a9204e146994080189aeca1bca8aa6bd/pkgs/racket-test/tests/syntax/contract/phase.rkt#L23-L25 Is there a better way/is there something I should do instead?

I can think of anything better.

I guess maybe the right thing to do in that case is to extract the actual module path from the module at the appropriate phase, but it’d be a little more effort. Maybe I’ll make that change.

@343519265 Is this the code you use for DrRacket to merge consecutive wheel events?

https://github.com/yjqww6/useless/blob/master/gadgets/tool-wheel.rkt

@mflatt Thinking about it some more, is there any particular reason module names at compile-time ignore current-module-declare-name? I realize that parameter is designed to affect, well, when a module is declared, but it does seem unnecessarily confusing that the expansion-time module name is sometimes very different… so maybe there could be something like that parameter that affects expansion-time? I guess the current approach makes things like phase 1 uses of quote-module-name conveniently work out, in that they will produce symbols instead of paths, which means bytecode that contains quoted versions of those paths will be machine-independent, but that seems more accidental than intentional.

What are module names anyway? I don’t really understand the subtler points of how they relate to phases, file paths, the top level, and bytecode.

Oh cool. That actually seemed to work. (replacing quasisyntax with datum->syntax and using delta introducers. Thanks.

When I have the following macros: https://gist.github.com/LeifAndersen/8f06b4a15d9eb62e8fe8d5078d1253b4

The syntax object inside of bar has one less scope than the one inside of foo.

#hasheq((context
         .
         (#(71034 module)
          #(71042 module anonymous-module)
          #(71606 macro)
          #(71607 use-site))))
#hasheq((context
         .
         (#(71034 module)
          #(71042 module anonymous-module)
          #(71607 use-site)
          #(71608 macro)
          #(71609 use-site))))

Is there any way to remove the second use site scope?

You need to call syntax-local-introduce before calling syntax-debug-info to see the “outside” view instead of the “inside” view.

@lexi.lambda Ya, but iirc that only removes the macro scope.

Oh, sure. You can’t arbitrarily get rid of use-site scopes.

But isn’t that a problem when you have a macro that expands to another macro (use) that wants to bind a new variable?

No, because use-site scopes are pruned by the expander when it binds a variable in a definition context.

err….other way

err…never mind, the original way.

You can prune some use-site scopes off of identifiers using syntax-local-identifier-as-binding. But that only works on identifiers, since you’re only supposed to use it if you’re implementing your own definition context-like expansion loop.

See this section of the sets-of-scopes paper: http://www.cs.utah.edu/plt/scope-sets/pattern-macros.html#%28part._use-site%29

Specifically, see that section and the next one.

OH. So this is a limitation of @stchang’s and Sam C.’s trick to extend environments in turnstyle.

Section 2.4 explains the pruning of use-site scopes.

I don’t know what you mean, but I don’t think turnstile should be negatively impacted by this, though it may need to call syntax-local-identifier-as-binding in certain places.

It’s possible it currently doesn’t do that, but should.

(because we’ve been local-expanding it in an ‘expression’ context, which obviously isn’t a binding one.

Nah, that’s almost certainly how to get around it.

If you’re expanding an expression, you should expand it in an expression context, yes… but then use-site scopes shouldn’t affect you, since you’re in an expression context.

I think that you answered my question (without realizing it) so thanks. :smile:

Use-site scopes only come into play when you’re expanding in a definition context.

THe overall macro is in a definition context.

Then yes, you’d get a use-site scope. But the use-site scope should go everywhere, so it shouldn’t matter if the thing you’re expanding is an expression.

Has anyone made a redex model of wasm yet?

or a #lang for that matter

The text format of wasm uses s-expressions so it should be really easy

Yes, it is

another attempt is https://github.com/yjqww6/useless/blob/master/gadgets/tool-wheel2.rkt, didn’t feel a significant difference.