pyret-lang
pyret-lang copied to clipboard
Opportunity for better error message
I feel like we ought to be able to tackle a better error message here:

The parse succeeds, and whether we do it statically (well-formedness) or dynamically, I think we can improve a lot.
It would be a nice differentiator from Python. I have to spend significant time on the corresponding error message in Python in the first few lectures of my Python intro class, because students want to try this. Pyret's error message is only a little better than Python
>>> 6(3 + 2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable
It almost goes without saying that this would also be useful in the first few hours of Bootstrap, and explicit guidance for adding a *
could even make sense.
I'm not sure it goes without saying -- what kind of error message do you want here? Do you somehow want to detect that both the "function" and "operand" could be reparsed as arithmetic expressions and somehow politely remind students that juxtaposition is not how to write multiplication? This seems extremely niche, and brittle to detect...
I would bet that this predicate covers enough cases to make a difference:
is-num-expr(function-part) and is-single-argument(args) and is-binop-expr(args.get(0))
And sure, it's niche: it's precisely the niche of beginner programmers who try doing algebraic expressions!
Right, but this is such a tiny sliver of "algebraic expressions" -- 6a
, (3 + 4)x
, mx + b
etc. wouldn't be covered by your predicate: the first two cause a wf-error (2 expressions on a single line), while the last "works" but is (likely) a semantic error. But oddly, 6(3 + (4 / 5))
and other more complicated expressions will be covered, which makes it harder to predict when this improved suggestion will kick in. I'm not saying it's a bad idea, but I worry whether that lesser predictability will cause its own confusion.
I always applaud better error messages, but with the circles evaluation this specific error rarely comes up in bootstrap classes. Students just assume they're going to have to put an operator in there somewhere.