On Thu, Jan 28, 2016 at 3:45 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

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

I do use *-tabulate time to time; it saves space for stop-predicate

and next-procedure of *-unfold. In languages with concise partial

application such as Haskell we won't probably need it, but with Scheme,

saving a few lambdas sometimes makes the expression fit in one line nicely.

But I can live without it. Like to see others' opinion.

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

Reasonable. I do define *-concatenate with (apply *-append arg) anyway.

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

Agreed. I think I never used map-in-order anyway. Just that users should

be more careful not to assume the dynamic order of ideque-map---for example,

with two-list implementation of ideque, it's efficient to apply PROC in the reverse

order of the tail part.

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

I'm thinking of rerturning ideque. It's (ideque-filter values (ideque-map proc ideque ...))

but saves creating intermediate ideque.

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

I'm fine with your decision.

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

I'm fine with it, too.

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

Reasonable.