[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SRFI-13 -- bits & pieces
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.
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.
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.