2009/4/16 Michael Mossey :

I was thinking that it might be useful to have a Google-like "do you mean this?" feature. If the field name is //customer=, then the parser might recognize a huge list of variants like //ustomer=, //customor=, etc... that is, recognize them well enough to continue parsing and give a decent error message in context.

Any ideas how to go about this?

To measure how similar two strings are, you can use a metric like Levenshtein distance, Damerau-Levenshtein distance, or Jaro-Winkler distance: http://en.wikipedia.org/wiki/Levenshtein_distance http://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_distance http://en.wikipedia.org/wiki/Jaro-Winkler_distance The first two basically count the number of mistakes that a user would have to make to get from the correct string to the one you read from the file. There's an 'edit-distance' package in Hackage that implements the first two: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/edit-distance When you find an unrecognised field name in the file, you could calculate the edit distance to each correct field name, and if there's one within a certain threshold, assume that's what the user meant (if there's more than one close match, maybe it's better to report an error than risk choosing the wrong one). I imagine this brute-force approach would be fast enough, but if not you could look at the techniques used by spell checkers to suggest corrections. Maybe even use a spell checking library, if such a thing exists (either pure Haskell or a binding to a library like aspell, although I couldn't see either from a quick search in Hackage). Andy

On Wed, 15 Apr 2009 23:31:50 -0700 Michael Mossey wrote:

I was thinking that it might be useful to have a Google-like "do you mean this?" feature. If the field name is //customer=, then the parser might recognize a huge list of variants like //ustomer=, //customor=, etc...

You could reduce the probability of such errors by providing a standard template that could be copy-pasted in wherever necessary. -- Robin

2009/4/16 Michael Mossey :

I don't think I would create a parser language that includes every variant, but instead the field names would be tokens that could be passed to another routine.

Right.

The variants could be generated ahead of time. I would limit the number of variants to something manageable, like 10,000 for each field name.

Generating variants ahead of time isn't necessary. Instead, you could just look at the edit distance between the token you get and each possible valid field name using something like http://hackage.haskell.org/cgi-bin/hackage-scripts/package/edit-distance. The token with the least edit distance is the one you should suggest. Cheers, Max