[racket-dev] very unhelpful beginner language error message, possible fix proposed

On 2/13/12 8:11 AM, Stephen Bloch wrote:
>
> On Feb 13, 2012, at 5:05 AM, Marijn wrote:
>
>>> ... it highlighted the id "list-sum-odd" in what should have
>>> been the 'else' case, and wrote:
>>>
>>> "list-sum-odd: expected a function call, but there is no open
>>> parenthesis before this function"
>>>
>>> ... which is really terrible, because there *IS* a parenthesis
>>> right before the function name.
>>
>> How about changing the message such that it complains about a shortage
>> of parentheses without stating that there are none?
>>
>> - - expected a function call, but there is an open parenthesis missing
>> before this function name
>
> Doesn't help much: as any student can see, there IS an open parenthesis before this function name.
>
>> Or maybe formulate it in a positive way to encourage the user to
>> insert parentheses?
>>
>> - - expected a function call, but found a function name; to call it add
>> surrounding parentheses
>
> It's GOT surrounding parentheses.
>
>
>
> The mistake the student made was at the "cond" level, not at the level of this function call, so the "right" error message has to say something about "cond", like
>
> -- cond: each clause must be a question/answer pair enclosed in brackets.  You have two expressions that look like the "question" and the "answer", but you need another pair of brackets around the two of them.
>
> It should be possible for the "cond" macro to detect this situation, at least in BSL, because the first element of what should be a cond-clause is a function name, and that's not a complete expression.  In ISLL, a function name can appear as an expression in its own right, but it still doesn't make sense as the first element of a cond-clause because a function name isn't a boolean: if it's defined, then it's non-null and therefore true, and if it's not, the student shouldn't be mentioning it at all.  Not until ASL does it become possible (albeit unlikely) that a function name could make sense as a condition.

In BSL, you can detect when the first element of a clause is a variable 
bound to a function, but I don't follow the reasoning about ISL.  You 
can't distinguish good from bad uses without running the code because 
you can't tell if a name refers to a function or a non-function.

ISL actually gives the best error message in my opinion:

cond: question result is not true or false: (lambda (a1) ...)

But it only does this at run time (as it must).  The syntax error for 
BSL could be similar though:

cond: question is not an expression but a function name: list-sum-odd

David