On Wed, May 6, 2009 at 11:26 PM, Kon Lovett
<address@hidden> 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
<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" :-)
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.