I was wondering about the correct behavior for code like:
print clock();
fun clock() {
return 0;
}
print clock();
I think that we need to allow clock to be shadowed by the new definition. This means that the root program environment needs to be populated with our builtins, rather than using a separate lookup table (which would prevent shadowing). I had made this mistake previously, however there doesn’t seem to be a test for it.
There might also be a test to see whether the “evaluate” function from before can also handle builtins, not just “run”.
Another weird test that’s especially relevant to the Rust path:
fun foo() {}
print foo == foo;
Thus the AST nodes representing foo must hold an Rc to the same data, and cloning that data during node creation would be an error (returns false for the above test instead of true).
Hey @yinchi, since you’ve finished the Resolving and Binding extension, does Stage #PZ7 (Variable Redeclaration) cover the problematic case you’ve encountered?
I think the issue here is realizing that builtin functions need to be treated like any other type of variable, thus allowing them to be redefined. I made a mistake of treating clock like a keyword and bypassing normal variable lookup. I learned I definitely need to pay more attention to what the book says.
#PZ7 comes before the functions portion of the challenge so the tests won’t cover this case. The second example I gave, checking that a function is equal to itself, is also not tested for as far as I know.