> I've been chided for singing the Beatles song "All You Need Is Lambda" > one too many times, so I'll just point out that everything around lists > is inessential, and that car and cdr and their setters, plus pair? and > cons, are all you actually need in that department. Standardization is > not intended as an exercise in minimization: we also want length to > have a standard meaning, not so much so that Scheme programmers don't > have to rewrite it every time, but so that people reading Scheme code > can already know what it means.
I'm not talking about minimization; I'm talking about power. Rather than introducing (for example) these ten primitives: make-string string? string-length string-ref string-set! make-u8-vector u8-vector? u8-vector-length u8-vector-ref ub-vector-set! we'd be talking about introducing one: (define-vector-type <name> <type>) Now the above 8 primitives become derived. But--much more importantly--so do boolean vectors and floating point vectors and vectors of shape objects. A naive compiler would perhaps just implement all of this in terms of vectors (with a type tag). And a naive compiler would still be free to implement strings and u8 vectors differently as long as they honored the contract. A smart compiler, on the other hand, could work some time and space magic. That's why this is not about "reducing everything to lambda." Quite the opposite, in fact; this provides an implementation with a higher level of abstraction, not a lower one. I'm afraid I don't follow your point about "length" having different meanings. First, every type created by define-vector-type would have the same meaning; second, you can still make strings and u8 vectors part of the standard, just as "let" is part of the standard and derived from "lambda". define-vector-type would actually make it easier to gracefully expand the set of pre-defined vector types in Thing Two. The point of doing so would be to a) agree on names and b) allow naive compilers to continue to cheat on those pre-defined types with those pre-defined names. > I'm proposing a different implementation tower: general vectors can > be used to implement blobs, which can be used to implement homogeneous > vectors. High-quality small Scheme implementations should do a better > implementation of blobs than that, but a Scheme without native blobs can > load a portable general-vector-based implementation. Layering SRFI-4 > vectors on blobs is trivial. Consequently, my proposals provide only > general vectors, which are already in. Yes, but that's like saying we don't need fixnums because we already have bignums. If you define things in terms of general vectors you give up space and time efficiency--and you close the door to getting it back. Unless, of course, I misunderstood what you mean by "tower"; to me that implies an is-a? hierarchy which isn't present with the disjoint types I'm suggesting. >> On the second point, growable vectors are hidden inside >> open-output-string and open-output-blob (or whatever it might be >> called). But the concept of "growable vector" ends up getting attached >> to ports when it needn't be--and shouldn't be. > > Indeed, no need for that. A perfectly suitable growable vector is just a > non-growable vector inside a box. If that's too much copying for you (you > generally want to double the size of the vector at each copy), you can > use a tree of non-growable vectors instead, what a rope is to a string. Again, making growable vectors part of the standard raises the level of abstraction available to an implementation. And that in turn enables new families of algorithms. In its place you're proposing one-off implementations (for, say, strings and blobs) with the possibility of more to follow in Thing Two. To me that's just the kind of thing that the opening sentence of the RnRS standard is talking about: enable new capabilities, don't just pile on features. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
