On Wed, May 6, 2009 at 11:26 PM, Kon Lovett <klov...@pacbell.net> wrote:
> Hello Involved, > I really hate to respond to this thread but since I ported from the SRFI 41 > reference implementation maybe I should. > I'm curious. What did you have to do to port SRFI-41? It should have worked directly as written just about everywhere. > > On May 6, 2009, at 5:46 PM, Phil Bewig wrote: > > On Wed, May 6, 2009 at 4:56 PM, Alex Shinn <alexsh...@gmail.com> wrote: > >> Hi, >> >> Phil Bewig <pbe...@gmail.com> writes: >> > <snip> > > >> >> > Writing a library that duplicates SRFI-1 for streams seems >> > to me to be folly. >> >> Well, if you have streams at all, even if they are only >> suited to a special class of algorithms, it makes sense to >> provide a complete library of basic operations. Otherwise >> people will continuously reinvent the same utilities, and >> sometimes get them wrong. >> >> In fact, it is specifically desirable to provide an exact >> match of the SRFI-1 API for easy conversions and >> comparisons. In any module system with import prefixing >> (including Chicken 4), you can write everything with a >> stream- prefix and swap the backend from streams to lists >> with: >> >> (import srfi-41) >> (import (prefix stream-) srfi-1) >> >> Going the other direction (writing for SRFI-1 but then >> switching to streams) is only a little more verbose, >> requiring renaming of the individual identifiers you use. >> > > I disagree. Streams and lists are not substitutable. Haskell conflates > the two because everything in Haskell is lazy, so there is no difference. > But that isn't true in Scheme. > > > There is a reason for 'delay' & 'force'. Scheme is "eager" but > "multi-paradigm" and API designers shouldn't go out of the way to hide the > fact. At least for the "basics" :-) > Exactly. Haskell is pure and lazy all the way. Scheme is broader. > > > <snip> > > > When would it make sense to convert the name of a symbol to a stream of > characters? > > > If your interface only accepts streams. > But Scheme doesn't only accept streams. It also accepts lists. My other point is that 'symbol' is an atomic concept. A symbol doesn't consist of the stream of characters in its name-string. There might be a specialized need for a symbol->stream function, perhaps in a debugger or some other introspective program where streams exist but lists don't, but that's far beyond a general-purpose library. That's why using SRFI-1 as a checklist for streams-ext makes no sense. > > > >> <snip> > > >> >> [I would argue the name and API should be changed to >> stream-drop-right to match SRFI-1, though.] > > > Sounds like a synonym in a SRFI 41 based "streams-ext". > > > Stream-length and stream-reverse are certainly candidates to be dropped > from a stream library. I'm not entirely sure how I feel about them. > > > You feel badly ;-) They imply streams are finite. I prefer the general idea > by the user that streams are infinite, at least until they run out of steam > ... err, stream. > I included stream-length and stream-reverse because they are used regularly in Haskell programs, and Scheme programmers who are porting Haskell code, say as an academic exercise, might find them useful. I continue to maintain, as I did in SRFI-41, that if you need to materialize an entire stream, you do better to find a way to re-cast your program to use lists. > > > > You and Alejandro seem to be suggesting that you would use streams in > preference to lists in a variety of programs. Take as given that streams > will be much slower than lists, at least in current Scheme implementations. > I can't imagine using streams for much more than toy programs or academic > exercises. I would always find a better way. > >> >> >> Now, if you want to argue that the SRFI-1 API is too large, >> that's another story :) > > > It is. I never use SRFI-1. My personal standard library has take, drop, > take-while, drop-while, range, iterate, filter, zip, a simple list > comprehension macro, and pattern matching. > > > Maybe the R6RS authors were on to something ;-) > The guiding principle in any library must be to keep it small and simple. I quoted Saint-Exupéry in SRFI-41, but could have quoted Einstein "Everything should be as simple as possible, but no simpler." Occam's Razor also applies. SRFI-1 and streams-ext violate that principle to their own detriment. > > > >> >> -- >> Alex > > > I continue to maintain that it makes no sense to use SRFI-1 as a checklist > for implementing a streams extension library. I hate to keep repeating > myself, but streams are not lists. The two data types are used in two > entirely different sets of circumstances, with different usage patterns. > > > I agree. We are walking into "sequence" territory here. > > I kinda think everything that can be treated as a sequence should have an, > optional, sequence oriented interface. But built on a type specialized > interface. (Yes, I would prefer 'list-map', etc. in the base API.) > That idea is more Lispy than Schemely. > > > > All that said, if you want to write a streams-ext library that mimics > SRFI-1, feel free. Just be sure it is based on SRFI-41, not SRFI-40. If > you are concerned that there is some conflict between the old streams-ext > and the streams-derived of SRFI-41, and don't mind using the same name for > two different things, you can build streams-ext on top of streams-primitive > and provide exactly what you want. > > > Yes. > > Please look at the supplied "srfi-41-utils" extn 1st. (These are yours BTW > Mr. Bewig, just packaged.) > Phil works much better than Mr Bewig. I still think of Mr Bewig as my father, and he's been dead for six years. > > > > Phil > _______________________________________________ > Chicken-users mailing list > Chicken-users@nongnu.org > http://lists.nongnu.org/mailman/listinfo/chicken-users > > > Best Wishes, > Kon > > > Earlier in this thread Alex discussed a natural language parser based on streams; it uses streams, not lists, because it is the parser itself that determines where the end of the sentence is located in the input stream. That seems to me an appropriate use of streams. Alejandro mentioned the use of streams in svnwiki; he mentioned using streams of characters throughout his program, and also mentioned input/output using streams. Although I don't know the details, that again seems to me an appropriate use of streams. In both cases, it seems to me that streams-ext based on a SRFI-1 checklist is the wrong thing to do. It must certainly be better to build a small library of stream combinators specific to the task; if a few small stream utilities are needed, it might make sense to build a small streams-ext, but based on actual need, not a checklist. My own experience of my personal standard library is instructive. I resisted adding zip to my library for many years, out of a sense of minimalism. When I needed zip, it was just as easy to write (apply map list xss) as (zip xss). I finally put zip in my standard library a year or so ago, but I think I still write (apply map list xss) about as often as I write (zip xss), due to force of habit. Zip is better, because it more clearly states to the reader what it is. Zip belongs in my standard library. But that realization comes from years of use, not from a checklist. Maybe someday I'll add butlast-n to my standard library, but at the moment I don't find a need for it. As long as we're discussing streams, may I ask a question? How are people using SRFI-41? I've heard from several people who are using SRFI-41 for academic purposes, college professors who use SRFI-41 to present laziness to their students. But I've heard of very few uses of SRFI-41 "in anger", and I'm pleased to hear from Alex and Alejandro. Anyone else? Phil
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
