When there is an error in a check-expect expression there are a few behaviours
that were initially confusing me and moreso my students.
Consider the following ISL program:
(define (f x) x)
(check-expect (/ 0) 0)
(check-expect 1 2)
The error from (/ 0) stops subsequent checks.
The error also leaks into the Interactions, which may or may not be considered
a good thing. Unlike when there are errors not from check-expect tests the
function 'f' is undefined in the Interactions and students can't try the
function immediately.
The test failure message is:
Check failures:
check-expect encountered the following error instead of the
expected value, 0.
:: /: division by zero
at line 2, column 0
The mixture of indentations seems arbitrary, and thus a distraction.
It actually seems backwards: subsequent parts of a compound message would
usually be indented under what they are components of.
Regardless of the relative indentation: the large amount of whitespace
requires a lot of scrolling for students with small cheap laptops to see the
the specifics of the failure, especially when the test window is undocked.
Because the "at" line is not indented, it draws the students' attention away
even more.
The "::" is noise.
A space between the function name and ":" could help when the function name
ends with a non-letter.
Consider now the following ISL program:
(define (f x) x)
(check-expect 0 (/ 0))
(check-expect 1 2)
It behaves similarly, except it doesn't report the error as a failed test.
We use check-expect to design functions, so the "value" expression is often more
than a simple value, e.g.
(check-expect (average (list 1 2 3)) (/ (+ 1 2 3) 2)))
(check-expect (average (list 1 2 3)) (/ (apply + (list 1 2 3)) 2)))
I would like to change some of the above behaviours, so this is a post asking:
1. Are they intentional and if so then what rationale am I missing.
2. Would others like these behaviours changed.
3. Are there changes that would receive general agreement.
4. If yes to #3, would requesting those changes likely result in having them in
a snapshot build by January 10th for my students to install then.
5. If yes to #3 but no to #4, is this something that me (or my student) working
on in the next few weeks could result in a snapshot build accepting our pull
requests before January 10th?
Thanks,
Gary
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
