CoCoA » CoCoA-5

The problem is caused by the fact the suggestions offered depend on the arity in the context in which the name appears.

Since Bin has fixed arity (=2), but the arity was 0 in the input, the interpreter does not propose it. Min and min have variable arity, so they are offered.

If bin is input as a variable then all suggestions appear because any name can be used in that context.

What to do? Arity filtering seems like a good idea, but in this case it produces quite a misleading result.

1. we could disable arity filtering (might produce lots of useless suggestions?)
2. we could tell the interpreter to offer two sets of suggestions: those with suitable arity; and any others that match.

Now we get slightly different output:

>>> bin();
--> ERROR: Cannot find a variable named "bin" in scope.
Similarly named variables (that you might need to import) are: "Gin", "Min", "min" 
--> bin();
--> ^^^

>>> bin;
--> ERROR: Cannot find a variable named "bin" in scope.
Similarly named variables (that you might need to import) are: "Bin", "Gin", "Min", "gin", "min" 
--> bin;
--> ^^^

Notice that Gin appears in both lists of suggestions, while gin appears in only the second list. This is because of how Gin is defined in BackwardCompatible.cpkg5.

• the suggested names should be in order of increasing levenshtein distance
• if the name appears as a fn name in a call then name with "inappropriate" arity should appear but only after those with appropriate arity

This means that the set of suggested names does not vary with context, but the order in which they appear may vary (hopefully the "better matches" being earlier in the list).

What do you think? It should not be too hard to implement :-)
NOTE (20140903) damn, it won't be as easy as I'd hoped because Giovanni used std::set rather than list/vector.

• changed the use of std::set into set::vector
• implemented the idea of printing the names in increasing order of "remoteness"

I note that there are two distinct fns called collectSimilarlyNamedIdentifiers; I have changed only one of them. The other one appears to be recursive... not sure when it is called.

I'll talk with Anna; if she approves, I'll check in.

After some testing Anna and John approve the idea in comment 8 (already implemented).

We have also increased the max distance allowed when comparing names to (len+3)/4 where len is the length of the name typed by the user.