Here's the comments.
* Overall:
It may be easier to understand (and justify) the rich set of
APIs by regarding ideque not just as a variation of a queue,
but also a variation of a bidirectional immutable list.
Mentioning so in the intro will help the reader to see what
the srfi is aiming at. We can add something like "It can
also be used as a bidirectional list (sequence) and many
APIs reflect list operations." in the first paragraph of
Rationale, for example.
* Nitpicks:
ideque-take, etc. : Maybe add "It is an error if N is
greater than the length of i", for the consistency with
srfi-1.
ideque-map: Maybe explicitly mention that the dynamic order
PROC is applied isn't specified, just as map.
ideque-every: The current draft can read that ideque-every
returns #t if all elements satisfy PRED. Srfi-1's every
returns the last value returned by PRED in that case, and
it's better to be consistent.
ideque-zip, ideque-map, ideque-for-each, ideque-fold,
ideque-fold-right, ideque-append-map: The current draft can
read as if it is allowed to pass zero ideques. We can
define so, but for the consistency we may want to say at
least one ideque is required.
ideque-fold, ideque-fold-right: "passing the result of the
previous invocation as a second argument" is confusing when
more than one ideque are passed. Maybe "passing the
result ... as the last argument"?
ideque-any, ideque-every, ideque-count: Srfi-1's
corresponding procedures can take more than one lists. How
about making them take more than one ideques? (I know the
policy isn't consistently kept across other sequence types,
though.)
* Missing:
(ideque-tabulate n init-proc): Not difficult to define with
ideque-unfold, but for the consistency.
(ideque= elt= ideque1 ideque2 ideque ...): Returns #t iff
all ideques are the same length and every corresponing
elements satisfies elt=.
(ideque-ref ideque n): It's weird to have this if we see
ideque as a queue, but if we see ideque as a bidirectional
sequence, why not?
(ideque-concatenate list-of-ideques): Same reason as we have
concatenate.
(ideque-map-in-order proc ideque1 ideque2 ...): This may be
less important, but we have map-in-order in srfi-1
(ideque-for-each-right proc ideque1 ideque2 ...): If we see
ideque as bidirectional list, it's cleaner to have
operations on both directions whenever it makes sense.
(ideque-filter-map proc ideque1 ideque2 ...): ideque version
of filter-map.
(ideque-any-right proc ideque1 ideque2 ...),
(ideque-every-right proc ideque1 ideque2 ...): Apply PROC in
reverse order. The names are debatable.
(reverse-list->ideque list), (ideque->reverse-list ideque):
Because of bidirectional nature of ideque. Less important,
however, for ideque-reverse is O(1).
* Some more controversial issues:
ideque-find, ideque-find-right: I don't like the signature
inconsistency with 'find'. I can think of two options:
(1) Make failure thunk optional, defaulted to (lambda () #f).
This is under prospect that we'll extend list's 'find'
operation to allow such optional thunk as well.
(2) Use different name, e.g. ideque-search.
ideque-unfold, ideque-unfold-right: srfi-1's unfold and
unfold-right takes optoinal TAIL-GEN and TAIL argument,
which sometimes comes handy. Unfortunately this convension
isn't very consistent--- srfi-13's string-unfold instead
takes optional "base" (raw strings) and "make-tail". Also,
because of bidirectional nature of ideque, we could argue
that ideque-unfold should take HEAD argument and
ideque-unfold-right should take HEAD-GEN argument as well.
We could also argue that, since appending tail to ideque is
cheap, it's less important to have these. I don't strongly feel
about this, but slightly prefer having the same optional arg
as srfi-1, for the consistency.
Variation of ideque-any, ideque-every: If the caller uses
these only as predicates, that is, if she doesn't care the
order PRED is applied, then there's a room for optimization.
Is it too confusing to have such variation?