You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And, I got the following error message: Error E: Name "E" is already in use at [5:5].
Should this be the behavior? struct/enum declarations in a scope must become inaccessible when out of scope. (In this case, they are inaccessible, however, it won't let us declare another enum/struct with the same name)
The check for previously declared enum/struct is being done in Parser::check_if_declared. We should probably move it to the interpreter where the name resolution by scope is handled.
@tuqqu what do you think about this? What should be the behavior?
The text was updated successfully, but these errors were encountered:
Good catch actually.
The parser should not be handling enum/struct collisions. And it can't do it properly anyways.
Other name collisions are resolved on declaration in interpreter::env as they ought to be (constants, functions).
And it works as expected and this is allowed:
fnf(){const x = 10;fny(){}}const x = 10;fny(){}
If I am not missing anything we need to add a similar check to define_struct and define_enum and remove the check_if_declared from the parser altogether.
While we are at it we can also fix the current confusing error messages of define_function and define_constant
const x = 10;fnx(){}//Error x: Trying to redefine function "x" at [2:3].
It really should be just Name "x" is already in use at [..].
I tried to perform the following:
And, I got the following error message:
Error E: Name "E" is already in use at [5:5].
Should this be the behavior?
struct
/enum
declarations in a scope must become inaccessible when out of scope. (In this case, they are inaccessible, however, it won't let us declare anotherenum
/struct
with the same name)The check for previously declared
enum
/struct
is being done in Parser::check_if_declared. We should probably move it to the interpreter where the name resolution by scope is handled.@tuqqu what do you think about this? What should be the behavior?
The text was updated successfully, but these errors were encountered: