| Hello Involved,
I really hate to respond to this thread but since I ported from the SRFI 41 reference implementation maybe I should. On May 6, 2009, at 5:46 PM, Phil Bewig wrote: On Wed, May 6, 2009 at 4:56 PM, Alex Shinn <address@hidden> wrote: Hi,
<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" :-) <snip>
When would it make sense to convert the name of a symbol to a stream of characters?
If your interface only accepts streams. <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.
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 ;-)
--
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.)
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
_______________________________________________
Chicken-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-users
|