SchoolyB/EZ Bug: Type Names As Parameter Names Allowed

Introduction

In the realm of programming languages, consistency is key. A well-designed language should have clear and predictable rules, minimizing ambiguity and potential errors. However, sometimes inconsistencies slip through the cracks, leading to unexpected behavior. This article delves into a peculiar bug found in the SchoolyB/EZ language, where type names are unexpectedly allowed as parameter names in function definitions, despite being blocked for variable names. We'll explore the bug's description, steps to reproduce, expected and actual behaviors, the inconsistency it introduces, and related issues.

Description

The bug at hand involves the use of primitive type names such as int, float, string, bool, char, byte, and their sized variants (u8-u64, i8-i64) as function parameter names in SchoolyB/EZ. While the language correctly prevents these type names from being used as variable names, it surprisingly permits their use as parameter names. This inconsistency can lead to confusion and potential shadowing issues within the function scope.

When you define a function and use a type name as a parameter, the parameter effectively shadows the type name within that function's scope. This means that inside the function, the name refers to the parameter and not the type. While the code might compile and run, this practice is generally discouraged due to the potential for confusion and unexpected behavior. Ideally, the compiler should flag this as an error, ensuring that programmers use more descriptive and distinct names for their parameters.

Steps to Reproduce

To demonstrate this bug, consider the following SchoolyB/EZ code snippet:

import & use @std

do test(int int, float int, string int) {
 println("int=${int}, float=${float}, string=${string}")
}

do main() {
 test(1, 2, 3)
}

This code defines a function named test that takes three parameters: int, float, and string, all of which are named int. When executed, this code compiles and runs without any errors. The output will show the values passed to the function, demonstrating that the parameters are indeed shadowing the type names.

To reproduce the bug, simply copy and paste this code into a SchoolyB/EZ environment and compile it. Observe that the code compiles successfully without any warnings or errors, despite the unconventional parameter names. Run the compiled program, and you'll see the output confirming that the parameters are being used as intended, shadowing the type names.

Expected Behavior

Ideally, the SchoolyB/EZ compiler should prevent the use of type names as parameter names. The expected behavior would be an error message similar to the following:

E2020: "'int' is a reserved keyword and cannot be used as a parameter name"

This error message would clearly indicate that the programmer is attempting to use a reserved keyword (in this case, a type name) in an invalid context. By preventing this, the compiler would enforce consistency and prevent potential confusion caused by shadowing.

The error message should be clear and informative, guiding the programmer to correct the issue by choosing a different, non-reserved name for the parameter. This would align the behavior with the restriction already in place for variable names, ensuring a consistent and predictable programming experience.

Actual Behavior

As demonstrated in the reproduction steps, the actual behavior is quite different from the expected behavior. Instead of producing an error, the SchoolyB/EZ compiler allows the code to compile and run without any complaints. The parameter names effectively shadow the type names within the function scope, leading to potential confusion and unexpected behavior.

This behavior can be particularly problematic in larger codebases where the programmer might not be immediately aware that a parameter name is shadowing a type name. This can lead to subtle bugs that are difficult to track down, as the code might appear to be working correctly but is actually behaving in an unexpected way due to the shadowing.

The fact that the compiler doesn't flag this as an error is a significant departure from the expected behavior and introduces an inconsistency in the language's rules.

Inconsistency

The core of the issue lies in the inconsistency between how SchoolyB/EZ handles type names in different contexts. Using type names as variable names is correctly blocked, as demonstrated by the following code snippet:

temp int = 1 // E2020 error - correct!

This code will produce an error message, indicating that int is a reserved keyword and cannot be used as a variable name. This is the expected and consistent behavior.

However, using type names as parameter names is allowed, which is inconsistent with the restriction on variable names. This inconsistency can lead to confusion and unexpected behavior, as programmers might assume that the same rules apply to both variable names and parameter names.

The inconsistency highlights a flaw in the language's design, where the rules for identifier naming are not uniformly enforced across different contexts. This can make the language more difficult to learn and use, as programmers need to be aware of these subtle differences in behavior.

Related Issues

This bug is related to other issues concerning the use of reserved keywords as parameter names. Specifically, the following issues have been identified:

• #315 - Struct names as param names: This issue explores whether struct names should be allowed as parameter names.
• #316 - Function names as param names: This issue investigates whether function names should be allowed as parameter names.

These related issues further highlight the need for a consistent and well-defined set of rules for identifier naming in SchoolyB/EZ. By addressing these issues, the language can become more predictable and easier to use, reducing the potential for errors and confusion.

Conclusion

The bug allowing type names as parameter names in SchoolyB/EZ, while blocking them as variable names, introduces an inconsistency that can lead to confusion and potential errors. Addressing this inconsistency and related issues will contribute to a more robust and user-friendly language. By enforcing consistent naming rules across different contexts, SchoolyB/EZ can improve its overall design and reduce the likelihood of unexpected behavior.

For more information on language design principles and best practices, consider exploring resources like Crafting Interpreters.