[R6RS] "Reduce over-specification as well as under-specification"

[Michael Sperber]

Here's my attempt at trying to understand Will's Ticket #87, more
specifically the last two sections on "list utilities" and "plausible
lists."  I'll try to apply Will's suggestion to an example, to get an
idea of what the consequences would be.  Note this is only based on my
imagination.  I'm hoping Will will correct me where I'm wrong about
what he's suggesting.

---snip---
(for-all proc l1 l2 ... ln) (procedure)
(exists  proc l1 l2 ... ln) (procedure)

The lis must all be lists of equal size, and proc must be a procedure
that takes n arguments.  Proc must not mutate the li arguments.

For natural numbers i = 0, 1, ... the `for-all' procedure successively
applies proc to arguments xi^1 ... xi^n, where xi^j is the ith element
of lj, until #f is returned.  If proc returns true values for all but
the last element of the li, `for-all' performs a tail call of proc on
the kth elements, where k is the length of the li.  If proc returns #f
on any set of elements, `for-all' returns #f after the first such
application of proc without further traversing the ls.  If the ls are
all empty, for-all returns #t.

Implementation obligations: The implementation must* check that proc
is a procedure.  It should* check that the lis are chains of pairs to
the extent necessary to determine the return value.
---snip---

Note how the complicated description (at the front, but also inline)
of what the arguments might be gets simplified.  "Implementation
obligations" take up some space, but they're at the end and clearly
separated.

I've marked "must*" and "should*" because either of these might be the
other.  If we care about some efficiency statement, we might also add
something like "It should not check that the lis are chains of pairs
beyond the extent necessary to determine the return value."

Anyhow, somewhere near the beginning of the report we'd generally say
that, if an implementation detects a situation where the program
violated a "must" obligation, it must either abort the program or
raise an exception with condition type &violation.

Also, we'd get rid of all the "plausible list" stuff.

This makes anal-ness (anality? analogy? anal fixation?) a
quality-of-implementation issue, and we'd encourage (rather than
require) implementations to check things at just about the same point
we require them to check now.

We would lose the ability to reliably detect and handle
violations---but there are a number of cases where we don't guarantee
that anyway.  (And, after thinking about it, I disagree that the
multiple-value unspecifiedness is unrelated---if I read the draft
right, an implementation is already allowed to abort the program for
((lambda (x) x) (values 1 2)).)  An implementation might add a library
providing some special `catch-all-violations' facility, whose absence
disables some optimizations and implementation shortcuts.

Also, we would retain the guarantee that, if you see an exception with
condition type &violation, a violation indeed is what happened.

On a minor tangent, the current use of the word "must" in argument
specs is really both incompatible with RFC 2119 and also confusing.
When we say "l must be a t," we're really saying "l may be anything.
If it's not a t, an exception with condition type &assertion is
raised.  If it's a t, the following description applies."

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla