How would you implement an auto-correct feature for misspelled class attributes?

Question

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?

Answer 1

While you say you don't want an underscore-insensitive language, the straightforward implementation strategy is to build one of those, and disambiguate at the end, like a hash table with chaining:

• Every defined attribute is squashed to its underscore-free name.
• When there are multiple names squashing to the same string, a list/map of the original names to their identities is put in place where attributes are looked up.
• When looking up a name, underscores are removed and the right bucket looked up.
• If there is only one item there, that's the one you're looking for.
• If there's more than one item there, look up the full name string, and produce the corresponding attribute, or an error.

This lookup could during compilation or in an interpreter, with the only difference being what the data being looked up is. These lookups could be memoised if the cost is expected to be too high, but programs where that arises seem perverse.

If it really is the case that what you care about is "the number of underscore characters used inside of the label", the second-layer lookup can just be that count, rather than the full name. In that case, x__ and _x_ are the same, and distinct from x and _x; I find that hard to recommend.

---

As a language design this raises some issues of forwards and backwards compatibility: working code with reference to an attribute via a non-canonical name can be broken by the addition of another identifier in the same scope that is underscore-equivalent, as that will now be an error. Depending on how scopes work, this could be a greater or lesser problem.

For example, the addition of an inherited identifier in a superclass, out of the control of the programmer of a subclass, could break their code making use of the original attribute. Within a single local scope an error will likely be caught quickly and resolved, but with any sort of nested or remote introduction of scope entries it could be much more of a problem. In a public-facing interface, like your dog.len example, the addition of any visible name with an underscore is an unavoidable breaking change.

In a fully-controlled environment, canonicalising the source code to refer to the true name after the compiler first encountered the misspelling would avoid these compatibility issues. In a structured editor this may be acceptable, but in most cases it probably would not be for textual source code. However, there have been language implementations that forcibly applied source formatting upon compilation, so it's not out of the question.

If there is not a very compelling reason to support this sort of naming I wouldn't include it for the above reasons. It is viable, however, and I can imagine there could be cases where it is useful.

---

For a broader class of misspellings, a linear search that computes the Damerau-Levenshtein distance to each other identifier and selecting the unique shortest distance is plausible, but it seems ill-advised to extend this sort of behaviour to wholly-different names like this. For example, x and y have distance 1, but should likely not be treated identically, although the model above would treat x, _x, and x_ (also distance 1) as interchangeable. This is also much more fragile to minor changes, and almost certainly not a good idea.