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

 Racket Developers list:

Reply via email to