This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
By the way, am I reading the reference implementation correctly to conclude that: (define x (list 1 2 3) (collection->list x) => (1 2 3) but (define x (list =? '(a . b) '(c . d))) (collection->list x) => ((a . b) (c . d)) So, for lists, the behavior of COLLECTION->LIST changes depending on the types of values stored in the list? Here's a detailed review of the first two sections: > Abstract > A Collections API which defines a common naming scheme and set of > operations for creating, accessing, and manipulating common > datastructures in Scheme. The API defines accessors, a common > protocol for value access via a generic enumerator, and functions for > inter-datastructure cooperation. > Finally, a concrete specification of a compliant set of operators > for the standard Scheme heterogenous datastructures (lists and > vectors) and for the homogeneous Scheme string is provided. * confusing wording Mutation isn't mentioned there and "inter-datastructure cooperation" doesn't mean much. Saying that "the API defines [...] a common protocol for value access via a generic enumerator" is misleading: the proposal in fact defines procedures (not protocols) which perform enumeration of the values in any collection. I'm not sure how you use the word "protocol" but in this context, I would take it to mean that the proposal defines a way to extend the enumeration generics for new collection types -- something that the srfi does _not_ define. Although I see later that some operations in the interface accept multiple collection arguments of possibly different collection types, when reading the abstract I have no idea what is meant by "inter-datastructure cooperation". * unclear "need for" this SRFI and incomplete results Most importantly, the abstract doesn't mention the need for the proposal: it doesn't say what problem it aims to solve. This concerns me because while there are some common needs that I would hope a collections srfi will address, the abstract doesn't suggest that this srfi will. ** is it an extensible, abstract API for collections? I _think_ that the intent of the SRFI is roughly this (but see below for an alternative): We recognize that there are several abstract data types, all of which are kinds of collections (unordered sets of value, sets of values, dictionaries, and so forth). Each of these varieties of collection permits many possible implementations, often differentiated by distinct performance trade-offs. It is desirable to be able to write programs which manipulate collections using only abstract interfaces: so that the programs can operate on many different specific implementations of the collections (even during a single run). Given such an abstract interface, it is then necessary to provide a standard mechanism by which programs may provide new implementations [*] of the abstract interfaces to collections. This SRFI defines abstract interfaces to a small variety of common collection types and an interface for making new implementations of that inteface available. Additionally, for each abstract collection type it defines, this SRFI defines constructors for specific implementations which all [**] implementations are required to provide. 44 concerns me with respect to the paragraph marked [*]. It appears to me that 44 does not attempt to solve that problem. 44 concerns me with respect to the paragraph maked [**]. It appears to me that 44 does that job "half way". Because of those two problems it would be a practical impossibility for someone to write a future srfi, defining a new collection type implementation which extends the abstract interfaces of 44, and provide a reference implementation which is portable to all systems that support 44. That seems to me like quite a surprising property for a fundamental data structures srfi to have. Similarly, and also because of those two problems, it would be a practical impossibility for someone to write a program, portable to all systems that provide 44, which adds new collection types. In effect, then, 44 gives us only: 1) a large abstract interface to collections parts of which are neither required by the srfi to be useful or to be portably implementable on systems providing 44 2) a not-portably-extensible interface to a small set of "Scheme collections" ** or is it a non-extensible API for certain implementations of collections? Or, perhaps the intent of the SRFI is roughly this (loosely following wording from the chapter "Sequences" in "Common Lisp" by Guy L. Steele): The standard Scheme types list, vector, and string have very different natures and uses, but they also have some aspects in common. For example, each contains an ordered list of elements. Because of those common aspects, it is useful to provide a set of operations which operate on data of any of those types generically. This SRFI defines procedures which do so. I think it's unlikely that that's the actual intent: the srfi talks about "dictionaries" for example. If the intent were revised so that the above was the goal, it could then be made far smaller and simpler, and more obviously implementable. > Issues > Several functions in this SRFI are required to take arbitrary > collections or major collection subtypes as input. This > requires that the function in question be able to determine > the specific type of the collection and dispatch to an > appropriate implementation. > As standard Scheme lacks the ability to automatically dispatch > on different function behaviors based on the types of > arguments, it is difficult to devise a portable implementation > of this SRFI which allows arbitrary future collections. I don't think that that's a good description of the issue. Standard Scheme provides no means by which to create new types of objects which are disjoint from those listed in section 3.2 of R5RS. Among the disjoint types it does provide, it provides no reliably efficient means to dispatch on the type of one of those objects. Furthermore, some "derived types" recognized by Scheme procedures and of interest to a generic collections interface are not disjoint, either from one and other or from the types of section 3.2 (example: pairs, lists, and association lists). Together, those problems imply that it is _permanently_impossible_ to write a standard Scheme procedure which discriminates its input based on the type of that input if the notion of type being used for discrimination would separate, for exaple, pairs, lists, and association lists. No upwards compatable extension to Scheme can change that fact. Consequently, I think it is a profound mistake of this srfi to attempt the impossible. As a particular example, the reference implementation defines a procedure CLASS-OF whose definition begins: (set! class-of (lambda (obj) (cond ((%instance? obj) (%instance-class obj)) ;; Get the right classes here -- previously, there was no <LIST> ;; or <ALIST>. ((null? obj) <null>) ((alist? obj) <alist>) ((list? obj) <list>) ((pair? obj) <pair>) ....))) The implication of this, given how ALIST? is defined, is that if I create a sequence using the srfis LIST procedure, then update it by storing certain elements in it at certain positions (a procedure as the 0th element, pairs as the other elements), then my list will change types and become and ALIST? and a DICTIONARY? What difference does that make? Here's an example: COLLECTION-FOLD-LEFT, on a LIST?, should enumerate every element of the list. COLLECTION-FOLD-LEFT, on an ALIST?, should enumerate every key-value pair. In the reference implementation, given a list which contains the elements: =? (a . b) (c . d) the enumeration will produce: (a . b) (c . d) !!!! In short, the kind of genericity that this SRFI proposes to provide is an incoherent notion. It simply can not work. -t