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 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