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
- - expected a function call, but found a function name; to call it add
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: