Suppose that we are working with an object oriented compiled language, such as somthing C-flavored or Java-flavored.

There is a class named string

• string.ascii_letters is not a valid attribute access.

• string.asciiletters IS a valid attribute access.

A feature of a new programming language might be to bind the correct attribute to the invocation despite the presence of a spurious underscore character.

How might you allow an invalid attribute name, such as string.ascii_letters such that if the compiler deletes all underscores from the invalid attribute name, and the compiler searches the class attributes for the revised attribute name w/o underscores, it finds it?

If string.ascii_letters and string.asciiletters both exist, then the compiler can print an error message or raise an exception, or somthing like that.

We do not want an underscore insensitive language in the same way that there exist white-space insensitive languages.

Maybe the underscore matter sometimes.

For example, dog.len and dog._len might both be attributes of the class named dog.

The idea is to maintain allow automatically generated aliases of class method names, and other class attributes, without generating all possible aliases.

The language would be semi-underscore sensitive

If there exist two labels in the current scope which differ only in the number of underscore characters present in the label, then the label is underscore-sensitive.

Suppose that there is a label in the current scope L such that for any label in the current scope L′, we have that if L ≠ L′ then, L ≠ L′ after all underscores are deleted from both label L and L′. Then label L is not underscore-sensitive in the current scope.

I am not talking about a spell-checker in the Integrated Development Environment.

The language itself, and compiler, would allow underscores to be misused provided that no two variables, objects, or class attributes in the current scope differ only by the number of underscore characters used inside of the label.

How would you approach implementing such a feature?

Suppose that we are working with an object oriented compiled language, such as somthing C-flavored or Java-flavored.

There is a class named string

• string.ascii_letters is not a valid attribute access.

• string.asciiletters IS a valid attribute access.

A feature of a new programming language might be to bind the correct attribute to the invocation despite the presence of a spurious underscore character.

How might you allow an invalid attribute name, such as string.ascii_letters, such that if the compiler deletes all underscores from the invalid attribute name, and the compiler searches the class attributes for the revised attribute name w/o underscores, it finds it?

If string.ascii_letters and string.asciiletters both exist, then the compiler can print an error message or raise an exception, or something like that.

We do not want an underscore insensitive language in the same way that there exist white-space insensitive languages.

Maybe the underscore matters sometimes.

For example, dog.len and dog._len might both be attributes of the class named dog.

The idea is to allow automatically generated aliases of class method names, and other class attributes, without generating all possible aliases.

The language would be semi-underscore sensitive

If there exist two labels in the current scope which differ only in the number of underscore characters present in the label, then the label is underscore-sensitive.

Suppose that there is a label in the current scope L such that for any label in the current scope L′, we have that if L ≠ L′ then, L ≠ L′ after all underscores are deleted from both label L and L′. Then label L is not underscore-sensitive in the current scope.

I am not talking about a spell-checker in the Integrated Development Environment.

The language itself, and compiler, would allow underscores to be misused provided that no two variables, objects, or class attributes in the current scope differ only by the number of underscore characters used inside of the label.

How would you approach implementing such a feature?