[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SRFI-13 -- bits & pieces

This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.

    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

    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.