In the error test for `maybe-join', there is not much to test because
"it is an error" does not have to be signaled. Your test only tests
your specific implementation, not any portable implementation. In my
opinion, portable test suites are most helpful (because they encourage
alternative implementations), so I would drop that particular test.
As I have already written to John,
an error that has to be signaled but which I cannot test against, is
not only no more helpful than the condition "it is an error" (as you
can see by not being able to write a proper portable test), but even
worse than "it is an error" because it disallows the kinds of
optimizations underlying the idea of SRFI 145.
The phrase "an error is signaled" is used when a programming error has occurred and no recovery is reasonably possible, because Specifically it guarantees that the continuation of the procedure that is signaling will not be called (modulo call/cc tricks). The only time it makes sense to catch such errors is when you are writing something like a server that must continue to run even if there is a bug somewhere in it.
For example, a plausible definition of an `assert` (as opposed to `assume`) macro is "If the argument evaluates to #f, implementation-dependent actions are taken and an error is signaled." There is no need to have a predicate that identifies the objects that can be raised here, because assertions are introduced in order to ensure that a specified expression is true and to prevent further execution of the code if it is not.
It's my view that maybe-if with a non-Maybe first argument is a programming error of exactly this type.
John Cowan http://vrici.lojban.org/~cowan email@example.com
When I'm stuck in something boring where reading would be impossible or
rude, I often set up math problems for myself and solve them as a way
to pass the time. --John Jenkins