search

brownplt / pyret-lang

The Pyret language.
Other
1.07k stars 111 forks source link

Upper-case `Include` gives weird error #1117

Open shriram opened 7 years ago

shriram commented 7 years ago 
Include image
3
5

gives a WF error about two expressions on the same line, when the real problem is that include is spelled as Include.

PS: I understand why this parses the way it does, so it's not weird to me. I'm suggesting it would be weird to a beginner. Also, I actually saw someone type Include in their file this morning.

blerner commented 7 years ago

Agreed. This and #1116 are ungrammar (and un-lexer!) errors, though -- they're gonna be tricky to fix in general.

shriram commented 7 years ago

Can we at least build a Levenshtein for keywords? Simple typos can really throw people when combined with Pyret's error reporting.

blerner commented 7 years ago

Possibly...but: (1) When I worked on Seminal, Levenshtein edit distance on tokens wound up being a lousy metric (among many other lousier ones), (2) Keep in mind that this successfully parses, so it'd be a very ad-hoc heuristic to detect "expressions that are really just single identifiers that happen to be Levenshtein-near a keyword and that if we managed to reparse everything might improve the parse." I'm not confident in that working reliably...

jswrenn commented 7 years ago

Unlike #1116, this program is parsable so it is not that tricky to provide a better error report in this scenario. We could catch this in the well-formedness check that raises same-line, and append an additional suggestion to use "include" instead of "Include".

The degree to which we provide suggestions needs to be decided. Instead of an edit-distance metric, we could limit ourselves to generating suggestions based on capitalization. When I ran Kathi's lab section last week, I saw a lot of capitalization mistakes.