-
Notifications
You must be signed in to change notification settings - Fork 9
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
Check for type collisions when registering a free parameter against existing inputs #14
Comments
I'm not sure this is possible right now. I think it would be after the program refactor. Right now, when we process statement arguments, such as
then @speller26 ^ Another example of a use case for the program refactor, although it might be confusing without more context. Basically, we don't have a great way to actually track symbols. When I hit that symbol a new time, I can't tell if it's the same symbol or if it's shadowing the prev symbol. |
Prototype branch started here to explore fixing this, which always allow input parameters to be declared at the time of registering them: main...rmshaffer/input-param-name-conflict But as discussed above, this results in a failure in
|
No description provided.
The text was updated successfully, but these errors were encountered: