SRFI-13 -- bits & pieces shivers@xxxxxx (25 Jan 2000 01:02 UTC)
|
Re: SRFI-13 -- bits & pieces
d96-mst-ingen-reklam@xxxxxx
(28 Jan 2000 12:41 UTC)
|
SRFI-13 -- bits & pieces shivers@xxxxxx 25 Jan 2000 01:00 UTC
From: "Sergei Egorov" <xxxxxx@informaxinc.com> 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: d96xxxxxx@d.kth.se (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 <xxxxxx@netscape.com> 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: xxxxxx@informatik.uni-tuebingen.de 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