This page is part of the web mail archives of SRFI 40 from before July 7th, 2015. The new archives for SRFI 40 contain all messages, not just those from before July 7th, 2015.
On Tuesday, March 18, 2003 2:21 AM, Sven Hartrumpf [SMTP:Sven.Hartrumpf@xxxxxxxxxxxxxxxx] wrote: > I am not a stream expert, so I will concentrate on interface design > questions. This _lazy list SRFI_ should IMHO be closer to the popular > _list SRFI_ (SRFI-1). > Since streams and lists are significantly different, conceptually, I used the Haskell prelude as my primary model, not SRFI-1, although I do admit some correspondence to SRFI-1. Of course, since Haskell doesn't have lists in the Scheme sense, I felt free to modify the names where I felt it was appropriate. I also applied some sense of "schemeliness" to the names, though I am happy to admit that your sense of "schemeliness" may be different than mine. > Here are my comments in textual order: > > Drop: > stream-take-until, stream-drop-until > (No equivalent in SRFI-1 and stream-take-while/stream-drop-while > might suffice.) > > Rename: > stream-split -> stream-split-at > stream-split-until -> stream-break > stream-split-while -> stream-span > Break and span are the Haskell names for these functions. I didn't use them because I can never remember which is which. > The one line definition of stream-partition seems to be incomplete. > > Rename: > stream-fold-left -> stream-fold > (Is the order of arguments for func reversed compared to SRFI-1?) > stream-scan... -> ...? (fold-pair...?, is this the corresponding function?) > stream-fold-..-one -> stream-reduce (with slightly different semantics!) > The order of arguments follows the Haskell prelude. The names are like Haskell, but spelled out in full instead of abbreviated. Personally, I prefer accumulate and reduce for foldleft and foldright, but most other people seem to have the opposite preference, and accumulate and reduce don't promote to scanleft and scanright in any sensible way. Looking at SRFI-1, Olin Shivers spent a lot of time discussing the relative merits of these names, and finally decided that he was the SRFI author so he got to pick the names he liked, since there is no particular reason to prefer any one over the others. > Restricted usefulness: > port->word-stream (because it relies on char-alphabetic?, similarly for > port->line-stream > How about a predicate for characters as an argument? > You can specify your own reader function to the generic port->stream. Port->line-stream is frequently useful for text-processing filters, and port->word-stream has analogues in every scripting language I can think of (awk, perl, python, lua, tcl, etc), so I think it is okay to have it in the library. > Rename: > stream-concat -> stream-concatenate > ... and probably some more ... > You get the idea what I am after :-) > Unix shell programmers would spell this stream-cat. And there is another message in this discussion about how the names are already too long. I'll never make everybody happy. > And: > People should report functions (inspired by SRFI-1) that > - make sense for streams AND > - are currently not in SRFI-40. > I am generally not too worried about function names, and am happy to change a name if there is some reason, or due to a strong sentiment from the group. For instance, stream-init was changed to stream-butlast, at the suggestion of a reader of a preliminary draft of the SRFI, on the grounds that stream-init sounded too much like a function that initializes something rather than what it really does. However, absent some compelling reason such as that, I am reasonably happy with the names I have chosen, which seem to me both descriptive and "schemely," and won't lightly change them at this point. That's not to say there aren't problems. The family of functions stream-merge, stream-interleave, and stream-alternate are confusingly named, and any suggestions would certainly be considered. There will certainly be a problem naming the suggested variants of unfoldn. The name stream-transform has been used in this discussion, but doesn't really describe what it does. There are probably other examples as well. If you want to propose a name that solves some of these problems, feel free. > Greetings > Sven Many thanks for your comments. Phil