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.
> > Dictionaries have conceptual issues precisely because they are a > > mapping where all other collection styles in the SRFI are just > > collections. > > Agreed. I keep waffling between two different concepts for the > dictionary: is it a collection of mappings, or is it a bag with an > index? A dictionary is a datastructure which stores values that can be accessed using a key. Anything more specific than that assumes a specific implementation type. It may be implemented as a bag with an index, but its important to keep the types distinct, otherwise you risk shoehorning many dictionary types into an awkward interface in order to look like a bag with an index. You can't necessarily assume a collection of mappings either (although to some extent you must to implement the folding enumerator). > > I'm a bit surprised that vector wasn't defined as pure-mutable. Yes, it should be. > > This is more an issue for programmers than the specification of the > > SRFI. > > I can't disagree more strongly. If the specification makes errors likely > and reviews difficult, that's a problem with the spec, not the > programmers. This is such an important issue that language standards > committees include it in their charters! (See C++.) > > I didn't analyze the procedures closely the first time around -- I found > a few issues before I ever got that far -- but when I did I noticed > several inconsistencies and error-prone naming conventions. Examples: > > vector-set! incompatible with R5RS > mutable vs immutable (seem like opposites, but they're not) This is really a problem with haphazardly calling purely mutable functions just mutable at times. This has been fixed. > string= vs string=? (names too similar, different semantics) The problem is that *? in Scheme most often indicates a unary or binary predicate. The equality function of this SRFI (and of SRFI 1) behaves differently enough that I could argue that calling it *=? would actually misrepresent its meaning more. > *-all vs *-any (names similar and counterintuitive) The names are quite intuitive if you read them right: (*-remove-all collection bag) => remove all of bag from collection (*-remove-any collection bag) => remove any occurence of bag from collection > Perhaps not. But I do see a few major issues: > > 1. Quiet incompatibility with R5RS. I agree. > 2. Error-prone naming conventions. Maybe. I'm not convinced that the same argument can't be made from the other side of the fence, i.e. that the names of procedures from other libraries are themselves ill conceived. > 3. Problems with the dictionary interface. I agree on some levels. The dictionary equivalence problem is very real. I don't think however that the general contract of the dictionary API is all that broken. It deliberately seeks to describe dictionaries, not map them onto any other model. Scott
Description: PGP signature