Michael Lenaghan scripsit: > That's a beautifully expressed idea. When considering Thing One > features I think it would be worth asking: what's the underlying > essential piece here that would make more things possible? I think > those are exactly the things that should be in Thing One.
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. > In what's been discussed so far I think there are at least two such > building blocks. One is homogeneous vectors; the other is growable > vectors. 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. > 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. -- No, John. I want formats that are actually John Cowan useful, rather than over-featured megaliths that http://www.ccil.org/~cowan address all questions by piling on ridiculous [email protected] internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
