On Tuesday, March 18, 2003 2:21 AM, Sven Hartrumpf [SMTP:xxxxxx@FernUni-Hagen.de] 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