Duncan,

Thanks for coming up with this SRFI and for providing so many examples.
A few comments, from my initial reading, follow.  I make the usual
apologies for pedantry.

* Missing word: “R6RS conditions may not be available, in which
[case] implementations may simply signal an error …”.

I would also allow analogous conditions to be raised in non-R6RS
condition systems, instead of falling all the way back to ‘error’.

* Agreement: “With nlab-comp or elab-comp respectively if they are not
a SRFI 128 comparator.”  Read “if either is not a SRFI 128 comparator,”
or something similar.

* Another agreement issue: “With the incoming and outgoing edges if
they are not a proper list.”  There are a few more of these scattered
throughout the document.

* ‘build-graph’: With regard to all of these irritants, how can you
tell (except by reading the error message) which of the 8 cases caused
the exception to be raised?  Knowing the answer to this question is
either important enough to warrant adding fine-grained condition
subtypes, or not important enough to specify so fine-grainedly.

* Missing words: “An assertion violation is raised with *pair* as
irritant [if it] is not a proper list.” Also, rename ‘pair’ to ‘list’,
since it must be one.

* Typo in ‘graph-contains?’: “Procedure which tests whether graph
contains a node in[d]exed at k.”

“The second case returns #t if and only if there is a node at k and
that it has label label.” Read “The second case returns #t if and only
if there is a node at k which has label *label*”.

* ‘graph=?’: In what sense must the graphs’ comparators be the same?

* Is ‘graph-embed’ required to embed its context arguments in
left-to-right order, or are other orders allowed?  Similar questions
apply to the ‘insert’ & ‘delete’ procedures.

* I think you can save a lot of text about invalid-type assertions if
you add ‘src’, ‘tgt’, ‘label’, etc.  to the “Argument restrictions and
conventions” section.

* ‘graph-context’ is said to be faster than ‘graph-match’.  I think it
would be very useful to implementers and users if this were quantified.
What kind of running time should we be able to expect from the forms of
this SRFI?  (This question is especially relevant to a graph library,
given the traditional performance trade-offs involved in implementing
graphs.)

* The signature of ‘graph-fold’ has a missing close paren.

* To each his own when it comes to identifiers, but I think “nlab-comp”
(“node label comparator”!) and “elab-comp” are cryptic names indeed.
“node-comparator” and “edge-comparator” seem just fine.

Again, thanks.  I’ll keep reading.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>