It seems fairly simple: structures that are inductively-defined have
"true", corecursive unfolds. Those that are not have iterative
("vector-style") unfolds, which take a length rather than a stop?
predicate.
Exactly so; thanks for the concise expression. I think that Marc's complaint is mostly terminological: we shouldn't call it an unfold when it isn't. Then again, we shouldn't be using "lambda" for something evaluated in applicative order, either.
It's especially unfortunate that all the string SRFIs follow SRFI 13
in this, since I doubt it's what anyone wants. Scheme strings/texts
are no longer lists in disguise, and should have an iterative unfold.
However, fixed-length but mutable strings are not really what anyone wants either, as has been hashed out at great length. We have more candidate string SRFIs than anything else, though I am hoping to get the number down to two (cursor-based and index-based), while still steering the strait between guaranteed backward compat and lack of portability.
As a result of this structural mismatch, I suspect that all existing
string unfolds are unfolding a list and calling list->string, which is
about as good as having no string unfold at all.
Actually not. Here are Olin's comments in SRFI 13, which have been carried over:
;;; The strategy is to allocate a series of chunks into which we stash the
;;; chars as we generate them. Chunk size goes up in powers of two starting
;;; with 40 and levelling out at 4k, i.e.
;;; 40 40 80 160 320 640 1280 2560 4096 4096 4096 4096 4096...
;;; This should work pretty well for short strings, 1-line (80 char) strings,
;;; and longer ones. When done, we allocate an answer string and copy the
;;; chars over from the chunk buffers.
The chunks are of course kept in a list. This is a variant of the strategy used for extending vectors: double it until the geometric progression threatens to eat you alive, and then grow arithmetically after that. On average every element is only copied once until arithmetic growth is reached. (Perhaps the 4K limit should be increased now.) SRFI 135 uses purely arithmetic growth, where the chunk size is 128 bytes.
This is getting rather far afield, but I think a tiny SRFI to offer an
iterative unfold for strings and texts might be a Good Thing.
SRFI 152 + 185 is the most recent index-oriented candidate for a string library, and SRFI 152 is basically from pruning SRFI 113 (via 130 and 135), but it desperately needs a full review with an eye not only to adding but to further pruning. I'd be happy to withdraw it and resubmit it on the basis of such a review. (I already got rid of string-reverse in 130 and 152 on the grounds that it is, to say the least, highly specialized)
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgIs a chair finely made tragic or comic? Is the portrait of Mona Lisa
good if I desire to see it? Is the bust of Sir Philip Crampton lyrical,
epical or dramatic? If a man hacking in fury at a block of wood make
there an image of a cow, is that image a work of art? If not, why not?
--Stephen Dedalus