SRFI-13 -- bits & pieces

[shivers@xxxxxxxxxx]

    From: "Sergei Egorov" <esl@xxxxxxxxxxxxxxx>
    I also oppose "dropping" of standard Scheme
    procedures. Does this mean that to claim 
    support for SRFI-13 (or SRFI-1) my implementation 
    should make them unavailable? If not, then why
    mention it at all? I believe the whole idea belongs 
    to a separate "Scheme Request For Non-implementation"
    process (SRFN-0: drop TRANSCRIPT-ON and TRANSCRIPT-OFF).

No. I'm really saying something much simpler. SRFI-13 is a collection
of names & values. CAR is not part of that collection. Neither is IF.
Neither is GEORGE. Neither is SUBSTRING. Now, if your Scheme provides
the R5RS procedures -- perhaps in some R5RS module, perhaps simply as part of
the pervasive top-level environment -- then you will, of course, have
a SUBSTRING binding around. Which is fine -- SRFI-13 has no conflicts with
R5RS. But the name SUBSTRING isn't part of SRFI-13, just like CAR and IF
and GEORGE.


    From: d96-mst@xxxxxxxx (Mikael Ståldal)
    I wonder if [STRING-CONCATENATE is] really nessesary at all. Is there
    really a need to concatenate so many strings that (apply string-append
    list-of-strings) doesn't work? What is the lowest known limit on number of
    arguments to procedures in a sensible Scheme implementation?

64. Not acceptable. Say what you mean; mean what you say.

    From: David Rush <drush@xxxxxxxxxxxx>
    string-tabluate - ??? I grok it, just can't see the utility

Useful for constructing new strings. Instead of doing an allocate&side-effect 
construction, you can *functionally* specify how to construct the string.

    From: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx
    The [lower-level] procedures contain veiled references to a condition
    system, and even try to pass information to it, which it may or not be able
    to use.  In their present form, they should go.

So what? SRFI-13 doesn't specify what to do with the information, since
there's no good condition system for doing so. But it makes the information
available for implementation-specific error reporting/condition raising.
This is a good thing, and leaves the door open for making things more
precise later, should a standard condition system ever see the light of day.

I'm punting STRING-DO-EACH. Nobody likes it.

    I think that the KMP searching procedures should be generalized to
    allow for other algorithms than KMP. But only to algorithms that have
    the same properties as KMP, i.e. scanning a stream without
    backtracking. This excludes Boyer-Moore, but allows for some recent
    algorithms that are said to be faster than KMP[1].

The other algorithms I've seen (Sunday's, Boyer-Moore's) require building a
data structure whose size is proportional to the number of codes in the
character encoding: only 128 for ASCII... but, ah, somewhat larger for full
32-bit Unicode. I don't want to export an interface that couldn't be supported
in a Unicode Scheme.  So we can export either an algorithm-neutral interface,
or KMP, but really not anything else.
    -Olin