Add syntax-local-binding, a generalized version of syntax-local-value#2300
Add syntax-local-binding, a generalized version of syntax-local-value#2300lexi-lambda wants to merge 1 commit intoracket:masterfrom
Conversation
First-class definition contexts provide general-purpose control of the local binding context, but syntax-local-value only provides a limited way to inspect it: it cannot distinguish between out-of-context identifiers and in-context variables. This commit adds syntax-local-binding, which provides precisely the missing functionality. This commit also adds an #:immediate? keyword argument to syntax-local-value to make it more consistent with syntax-local-binding and eliminating the need for a separate syntax-local-value/immediate function.
6bf3d1e to
5ad4988
Compare
|
I certainly approve of extending the API to be able to distinguish these situations! I have an alternate design proposal I'll throw into the ring, though. I think that these APIs can be designed in two different ways:
I find that APIs in the second style make things like Turnstile and Hackett easier to write. Ultimately it might be nice to separate the Racket-specific APIs in a totally different part of the expander API and documentation from the generic bits! Specially segregating bindings for Racket runtime identifiers versus other syntax bindings, as in If we're introducing a new API, I would propose a design that doesn't privilege normal Racket variable bindings as anything special versus other transformer environment entries. We might expose the special internal |
I like this idea. The biggest question to me is what such a value should be named. It obviously can’t just be exported as |
First-class definition contexts provide general-purpose control of the local binding context, but
syntax-local-valueonly provides a limited way to inspect it: it cannot distinguish between out-of-context bindings and in-context variables. This commit adds a new function,syntax-local-binding, which provides precisely the missing functionality.This commit also adds an
#:immediate?keyword argument tosyntax-local-valueto make it more consistent withsyntax-local-binding, eliminating the need for a separatesyntax-local-value/immediatefunction (though of course it must be retained for backwards compatibility).