@mflatt Is it still true that the result of local-expand can include letrec-syntaxes+values when stop-ids is an empty list? If so, when could that be possible?

No, I don’t think that’s true.

Okay. I’m trying to improve the local-expand docs some more; I’ll update PR #2030 when I’m done.

@mflatt Okay, I’ve pushed some changes. If you could take a look at https://github.com/racket/racket/pull/2030 when you get a chance, I’d appreciate it.

It sounds like the expand-to-AST use case is okay for the moment, unless we start trying build in support for users to extend the compiler itself to support their custom core forms. :)

As for the interface, that’s a hard question. On the one hand, I really wouldn’t mind a new local-expand function with an updated interface. The way local-expand handles the stop list is already unpleasant; perhaps we can solve two problems at once by coming up with a new function (syntax-local-expand?) that gives greater control over the stop list and allows configuring which core forms may appear in the output? On the other hand, if local-expand raises an exception when it produces syntax containing custom core forms, then all forms would need to be updated to support subexpressions with custom core forms, including syntax-parameterize. I guess syntax-local-expand-expression could probably uncontroversially support custom core forms, since it produces an opaque result anyway, but I don’t know how much would break if local-expand produced something someone didn’t expect.

In the meantime, though, I’m not actually sure what workaround I should use for Hackett. Calling syntax-local-get-shadower myself seems almost certainly like the wrong thing to do, given how much everyone seems to want to get rid of it, so maybe I’ll just unhygienically introduce #%app for now instead of using a syntax parameter to adjust it.

I saw a behavior with nested modules I don’t understand why it’s occurring. I have a simple example:

in (module* A racket ...) the a identifier is available because it’s been provided in the enclosing module and required via (submod "..")

oh that is neat

but in the (module C racket ...) nested within (module+ B ..) the b identifier is available even though it’s not been provided by the top-most module?

Does that behavior occur with the Racket7 expander?

if I take out the (submod ".." ".."), then I get a weird namespace mismatch error

umm am running Racket 6.12

@abmclin That appears to be a bug with the old expander; racket7 reports the right error

ok so the (module+B (module C racket...)) is actually illegal?

The use of b is illegal, unless you add it to provide

shoot, I was taking advantage of that behavior to make possible some nice test cases

then once I started thinking on why it worked, I realized it made no sense, so I’ll make sure not to depend on that behavior

@mflatt for my clarification, the old expander being used by Racket 6.12 is still a set-of-scopes expander? The “old” is meant to imply it’s a C implementation?

Yes. (I keep forgetting that the “old” expander was the “new” expander fairly recently.)

@mflatt Is there a way to make the expander print the information given to log-expand to stderr, or is the only way to obtain that information to use the mysterious expand observer API?

what’s log-expand?

The internal log-expand form sends information only to the expand observer.

We should rename that to something that doesn’t say “log”

Alright, thanks. Is it documented anywhere how that works, or should I just read the macro-debugger source?

It’s not documented. You could set the parameter to a function that takes any number of arguments, and that would probably tell you as much as trying to read the macro-debugger source

Okay, that makes sense, thank you.

I have a program that is making the expander diverge, and I don’t understand why, so I’m trying to gain some insight into what’s happening.

Is it possible in Racket to get rest keyword arguments somehow? It seems not at first try.

not sure if I understood you correctly, don’t think there’s a such thing as a rest keyword.

@pocmatos the low level interface is make-keyword-procedure

I have a package called arguments that makes it easier: http://docs.racket-lang.org/arguments/index.html?q=arguments

Perfect, thanks.

example: > (define/arguments (keywords-product args) (for/product ([(k v) (in-hash (arguments-keyword args))]) v)) > (keywords-product #:foo 2 #:bar 3) 6 > (keywords-product 'ignored #:baz 6 #:blah 4) 24

@mflatt I have a very strange program that diverges on the Racket 7 expander but not Racket 6.12, but I’m having a lot of trouble coming up with a minimal reproduction (the real use case is a fairly complex program). I’ll keep trying, but looking at the information from the expand observer, it gets stuck in an infinite resolve, tag loop in which it introduces #%app over and over again, generating expressions that look like (#%app #%app3 #%app #%app3 #%app #%app3 #%app #%app3 ....). Do you have any idea why that might happen?