[R6RS] Condition hierarchy details

[Michael Sperber]

I'd like to draw your attention to some details of the condition
hierarchy that were previously ambiguous or not decided explicitly, as
set forth in the R6RS draft:

- &implementation-restriction is a subtype of &violation, not of
  &error
  (The proposal I sent had it in both places.)

- I had to pick names for the predicates and, in some cases,
  accessors.  While it's clear that &undefined is a condition type,
  it's less clear that a procedure called `undefined?' actually tests
  for a condition type.  In the following cases I've picked predicates
  that don't correspond directly to the condition-type names:

  o serious-condition?  (note this is already in SRFI 35)
  o lexical-defect?
  o undefined-defect?
  o contract-defect?
  o irritants-condition?
  o who-condition?

  The rule I've used is that I picked different names when it wasn't
  obvious the predicate name refers to a condition type.  I realize
  this is shaky---possibly the predicates should all end in
  `-condition?'.  Let me know what you think.

- This is also true of the I/O conditiont types, where the issue of
  accessor names arises as well.  I've generally picked names
  i/o-...-error? for the subtypes of &error, and
  &i/o-operation-not-available-violation?  Also, `i/o-error-filename'
  etc.

If you have suggestions on how to improve on the current choices, be
sure to post.

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