+1 for allowing push and pop on both ends.
I wonder if we should specify the concrete implementation of bidirectional lists as John's pre-pre-SRFI;
for example, an implementation might have an efficient bidirectional list and want to build SortedDictionary
on top of it. Specifying internal structure can prevent such strategy. Exposing internal structure (alists) also
increase the risk that the user might use it in inconsistent way as SortedDictionary operates.
OTOJ, I see the advantage of exposing alists, that allows users to scan through the lists from the key with
usual list-operating tools rather than having a whole new set of utilities in SortedDictionary alone. So the question
is: Will we want a rich set of list operations that work on internal bidirectional lists? If so, I'm for John's idea
rather than duplicate the list operations work on SortedDictionary. However, if "deque with O(1) dictionary" is
suffice, I like it to be opaque.