Disallow shadowing? #86
Labels
No Label
accepted
bug
clj
documentation
enhancement
errors
infrastructure
later
next
now
optimization
proposal
question
research
semantics
syntax
ux
vm
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: twc/ludus#86
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is the correct?
Technically, what happens when a function body is a block?
Well, a block is a new scope. So when the function body is a new block, it's a child scope, with the parent scope being the scope for the function body. That means that we would have to special-case the "function body is a block" situation.
I'm disinclined to special-case things.
@matt What do you think? Should the following be allowed?
You wouldn't be able to do
But actually, this wouldn't even parse, because function bodies actually must be non-binding expressions.
So the question is, is a block that's a function body different from other kinds of blocks, so people can't re-bind function parameter names?
Validator should not allow re-binding of function parametersto Disallow shadowing?Actually, the conversation leads us to think we should disallow shadowing.
One question is whether we allow shadowing of names bound in Prelude. The first thought is that yes, you can shadow Prelude, but scripts may not shadow bindings they introduce.
Validator now disallows shadowing of any name in any context. Next up: develop logic in validator to only check names that are explicitly bound in a script, and not names that are in Prelude.
Done in
98421a9215