-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spec is unclear on label shadowing #1572
Comments
Yes, the places in the spec that you cite the side condition you cite should actually be rather unambiguous about this. In particular, the condition in (1) rejects a symbolic label if it already exists in the context, so that any program attempting shadowing won't parse. Do you have any specific clarification in mind? |
I certainly feel that the incorrect side condition should be removed, and perhaps the prose updated to say explicitly that label shadowing is syntactically permitted. A question about clarity in principle (if not in practice) is whether the definition of well-formedness should exempt the |
I think there is a misunderstanding: side condition and well-formedness are correct. Rejecting shadowing is intended. |
Oh, apologies, I certainly have misunderstood then. The discussion in #210, for example, suggests that shadowing is permitted (“Labels […] scope over the labelled expression, and can be shadowed within their scope”); #303 reiterates that suggestion (“labels simply use ordinary lexical scoping”); and an assertion in Am I just not thinking about this correctly? Is there a reason why reuse of labels is not prevented by the side condition and well-formedness constraint? (Here’s a video of me being confused, if that helps to clarify my confusion.) |
I'm sorry, you are right: the spec does not match test suite or prior discussion. So while it probably defines what it does intentionally (to be honest, I don't remember), that intent does not match prior intent. I'll prepare a fix. Thanks for bearing with me. :) |
Not at all, I’m just relieved I wasn’t missing something obvious! Thanks very much for explaining. |
Please see #1579. |
Fantastic. This exactly matches what I was initially expecting to see. 🙏🏻 |
(It’s particularly nice that this, by removing the old label from the context, doesn’t compromise well-formedness.) |
As discussed in #210 and #303, it’s not clear from the spec whether a nested block may redefine (“shadow”) a label from one of its ancestors, although the test introduced by #216 makes it unambiguous that this is allowed in practice.
Subjectively, I got the impression from reading the spec that label shadowing is explicitly not allowed, because:
I can explain away point 2 by noting that — itself somewhat counterintuitively — well-formedness appears to be asserted only selectively, i.e. in special circumstances where we expect the labels index space to be empty anyway, but I have no explanation for point 1.
It’s entirely possible I’ve misunderstood the spec, but either way, might it be clarified to make the situation more explicit?
The text was updated successfully, but these errors were encountered: