[r6rs-discuss] [Formal] Compound conditions considered bogus

[John Cowan]

Michael Sperber scripsit:

> There's all kinds of "must" language in here, but I don't even
> understand what you're trying to do.  

I didn't mean "must" in the sense of RFC 2119, but rather in the sense of
"in order to achieve one's goals it is necessary to act as follows."

> (Note that both simple and compound conditions are are conditions.
> None of the procedures operating on conditions is restricted to one
> or the other.)

You're right: I had overlooked the fact that a simple condition
functions like a singleton compound condition.  That eliminates most
of the difficulties I was seeing: you can "wrap" a condition with a new
simple-condition simply by using make-compound-condition passing the new
condition and the original condition (simple or compound) in that order.

However, what still remains anomalous is the fact that a compound
condition can have components r, s, such that type(r) is a subtype of
type(s).  Call such components "overlapping".  Overlapping components make
it hard to reason about the model: there are first-class components that
are visible and second-class ones that are not.  Second-class components
shouldn't exist.

Three strategies for dealing with overlapping components come to mind:

1) make-compound-condition signals an error, and the compound condition
is not created.

2) make-compound-condition quietly ignores all but the first condition.
(This is close to the current position, as condition-ref cannot read
the fields of non-first conditions; however, they can be read by using
condition->list first.)

3) make-compound-condition intelligently merges the field lists of the
overlapping conditions, such that the first appearance of each *field* is
preserved in the resulting condition.  Thus given overlapping components
r, s of types R, S such that R is a subtype of S, the result has a
single component, namely:

	a) if r precedes s, component r;

	b) if r follows s, a component of type R such that all fields
	in both r and s are taken from s, and all other fields are taken
	from r.

The condition macro should forbid overlapping conditions if choices 1 or
2 are adopted, and identical fields of overlapping conditions if choice
3 is adopted.

Choice 3 is closest to The Right Thing, but is the most complicated.
Choice 1 is simple and safe.  Choice 2 is even simpler but may discard
information unexpectedly.

-- 
John Cowan       http://www.ccil.org/~cowan        <cowan at ccil.org>
        You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
        You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
                Clear all so!  `Tis a Jute.... (Finnegans Wake 16.5)