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 <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" :-)
<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
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Best Wishes,
Kon
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users