Shiro Kawai scripsit:

> I've been pondering this, too - whether this srfi should specify
> underlying implementation or not.  Gauche also has a queue library,
> which now use lists internally but I was about to introduce
> alternative implementation using a ring buffer.

I would like to see a ring-buffer SRFI.

> OTOH, the intention of this srfi is understandable - that,
> by exposing internal list structure, we can use rich list
> utitities instead of duplicating them for queue, e.g. queue-find,
> queue-any, queue-every etc.

Exactly so.

> Arguably, this makes the proposed API low-level - for example,
> if an implementation wants to provide a variation of a queue
> which is MT-safe, API to expose its internal list won't make
> much sense.  One need to build a distinct structure which
> internally use this srfi.

Yes.

> Maybe what bothers me most is that this specific implementation
> strategy takes a generic name "queue".   It'd be nice that
> a generic queue-add-front! etc work with various queue
> implementations.
>
> Will it be too confusing to name this as simple-queue or list-queue
> or something?

Scheme doesn't normally mind long names, but make-list-queue-from-list
might be overkill.  Perhaps I will get rid of make-queue as it exists
(I'm inclined to agree that it isn't very useful) and merge
make-queue-from-list and make-queue-from-first-last into a new
make-list-queue.

I don't suppose "tconc" will fly for Scheme, though it does have Lisp
tradition behind it.  :-)

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
First known example of political correctness: After Nurhachi had united
all the other Jurchen tribes under the leadership of the Manchus, his
successor Abahai (1592-1643) issued an order that the name Jurchen should
be banned, and from then on, they were all to be called Manchus.
                --S. Robert Ramsey, The Languages of China