Shiro Kawai scripsit:

> 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.

Excellent idea.

> ideque-take, etc. : Maybe add "It is an error if N is greater than the
> length of i", for the consistency with srfi-1.

I will add it.

> ideque-map: Maybe explicitly mention that the dynamic order PROC is
> applied isn't specified, just as map.

Agreed.

> 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.

I will fix this one: it's a slight deficiency in the wording.

> 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.

I agree.

> 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"?

Yes.

> 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.)

Agreed.

> (ideque-tabulate n init-proc): Not difficult to define with
> ideque-unfold, but for the consistency.

I'm never been quite sure what the point of tabulate really is: it's a
trivial variant of unfold.  I can add it back, I suppose, if there is
demand for it.

> (ideque= elt= ideque1 ideque2 ideque ...): Returns #t iff all ideques
> are the same length and every corresponing elements satisfies elt=.

I suppose this is the Right Thing given the bidirectional-list mental
model, so I'll add it.

> (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?

Agreed.

> (ideque-concatenate list-of-ideques): Same reason as we have
> concatenate.

I think that's now obsolete: if you look at the wiki page
ApplyArgsLimit, you can see that all Schemes support at least 1000
arguments, and if you have more than that to concatenate, you should
probably use another data structure instead.

> (ideque-map-in-order proc ideque1 ideque2 ...): This may be less
> important, but we have map-in-order in srfi-1

Which has always been defined to be map.  I think that's excessive.

> (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.

Agreed.

> (ideque-filter-map proc ideque1 ideque2 ...): ideque version of
> filter-map.

But should the map function return lists or ideques?  It seems heavyweight
to return ideques that are then just copied and discarded, whereas
returning lists seems inconsistent.  That's why I left this out.

> (ideque-any-right proc ideque1 ideque2 ...), (ideque-every-right proc
> ideque1 ideque2 ...): Apply PROC in reverse order.  The names are
> debatable.

Since ideque-reverse is O(1) these are not necessary.

> (reverse-list->ideque list), (ideque->reverse-list ideque):  Because
> of bidirectional nature of ideque.  Less important, however, for
> ideque-reverse is O(1).

Likewise I don't think these are necessary.

> 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.

I think this option is best even if we do not replace SRFI 1's find.

> ideque-unfold, ideque-unfold-right: srfi-1's unfold and unfold-right
> takes optoinal TAIL-GEN and TAIL argument, [...]  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.

I think these are not necessary, and are only provided in SRFI 1 because
of the unidirectional nature of lists.

> 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?

I think so, yes.  The compiler should be able to replace (if (ideque-any
...) ...) with (if (ideque-any? ...) ...) where any? is the version that
returns a pure boolean and can optimize.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Awk!" sed Grep. "A fscking python is perloining my Ruby; let me bash
    him with a Cshell!  Vi didn't I mount it on a troff?" --Francis Turner