Skip to content

Conversation

@c42f
Copy link
Owner

@c42f c42f commented Oct 21, 2025

When desugaring introduces a K"Identifer" it should always decorate it with an associates scope layer - either adopted from the users code, or an internal layer created on the fly.

This ensures desugaring treats hygiene consistently with macro expansion (thus ensuring that desugaring itself is hygienic).

When desugaring introduces a `K"Identifer"` it should always decorate it
with an associates scope layer - either adopted from the users code, or
an internal layer created on the fly.

This ensures desugaring treats hygiene consistently with macro
expansion (thus ensuring that desugaring itself is hygienic).
@c42f c42f mentioned this pull request Oct 21, 2025
Copy link
Collaborator

@mlechu mlechu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! It makes sense to delete this "layer." I'm not sure if there's any place in desugaring where generating internal layers is preferable to creating internal Bindings, but I'm not going to make early claims about the land of edge cases.

Going to do a quick merge so I can work on top of this in #99.

@mlechu mlechu merged commit 77eb96f into main Oct 21, 2025
1 check passed
@mlechu mlechu deleted the caf/remove-default-lowering-scope-layer branch October 21, 2025 16:54
@c42f
Copy link
Owner Author

c42f commented Oct 22, 2025

any place in desugaring where generating internal layers is preferable to creating internal Bindings

The main difference is that the scope analysis pass processes K"Identifier" according to the usual scope rules but passes bindings through unchanged. I'm not sure this distinction is actually required - we'd have to review all the usages to know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants