unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* SRFI 41, revisited
@ 2012-09-11  5:38 Chris K. Jester-Young
  2012-09-11  5:58 ` Daniel Hartwig
  0 siblings, 1 reply; 3+ messages in thread
From: Chris K. Jester-Young @ 2012-09-11  5:38 UTC (permalink / raw)
  To: guile-devel

It's been over half a year since I last wrote about SRFI 41; two whole
releases have happened since then. I'm pretty sure I don't want to wait
for another. ;-)

Thanks to Andy and Ludovic for all the feedback last time; I think I've
implemented all the feedback, so let's get this thing across the finish
line! I just updated the srfi-41 branch with a merge of v2.0.6, and ran
the tests (which passed with no changes to the code).

So, a final review would be highly appreciated.

One thing that is still missing is the documentation. I believe Ludovic
mentioned that this can be lifted straight from the SRFI specification
if need be. (I do hope to write something more original, even if only as
a later thing. But let's not let that hold up making srfi-41 available!)

Cheers,
Chris.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SRFI 41, revisited
  2012-09-11  5:38 SRFI 41, revisited Chris K. Jester-Young
@ 2012-09-11  5:58 ` Daniel Hartwig
  2012-09-11  6:56   ` Chris K. Jester-Young
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Hartwig @ 2012-09-11  5:58 UTC (permalink / raw)
  To: guile-devel

On 11 September 2012 13:38, Chris K. Jester-Young <cky944@gmail.com> wrote:
> It's been over half a year since I last wrote about SRFI 41; two whole
> releases have happened since then. I'm pretty sure I don't want to wait
> for another. ;-)

Hello

This is not compatible with the (ice-9 streams) module is it?  At
least, it does not appear to be by quickly scanning the source.

I once tried to implement stream-cons such that it is built on top of
make-stream which turned out quite messy.

At the time I investigated the two alternate implementations (ice-9's
make-stream is constructed using a generator) and found that depending
on the use case either approach could be more efficient in terms of
coding and run-time performance.  So at least having the two options
is great.

I wonder if there is an underlying base which is common to both
methods…  Such a base is great if ice-9 streams were extended with the
useful procedures as well (stream-filter, stream-ref, etc.).

Anyway, looks quite good and I'll play more with this module during the week.

Regards



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SRFI 41, revisited
  2012-09-11  5:58 ` Daniel Hartwig
@ 2012-09-11  6:56   ` Chris K. Jester-Young
  0 siblings, 0 replies; 3+ messages in thread
From: Chris K. Jester-Young @ 2012-09-11  6:56 UTC (permalink / raw)
  To: guile-devel

On Tue, Sep 11, 2012 at 01:58:26PM +0800, Daniel Hartwig wrote:
> This is not compatible with the (ice-9 streams) module is it?  At
> least, it does not appear to be by quickly scanning the source.

Nope, the two are not related at all. As you've correctly identified,
(ice-9 streams) uses a generator, whereas SRFI 41 uses stream-cons so
that you can build streams recursively from other streams (but in a way
that doesn't bust your stack).

The magic ingredient in all of this is SRFI 45's lazy, which is not
provided by standard Scheme promises.

In so saying, SRFI 41 does provide a generator-style stream builder too,
in the form of stream-unfolds. So it shouldn't be hard to port code from
using (ice-9 streams) to SRFI 41. The other direction isn't quite so
simple. ;-)

> At the time I investigated the two alternate implementations (ice-9's
> make-stream is constructed using a generator) and found that depending
> on the use case either approach could be more efficient in terms of
> coding and run-time performance.  So at least having the two options
> is great.

Yes, I think both libraries have a place; although SRFI 41 can do
everything (ice-9 streams) can do, it's also somewhat more complicated,
and sometimes all you need is something quick and easy.

> I wonder if there is an underlying base which is common to both
> methods…  Such a base is great if ice-9 streams were extended with the
> useful procedures as well (stream-filter, stream-ref, etc.).

I don't think there is a common base, since a lot of SRFI 41's utility
functions do make use of stream-cons. But you can reimplement them for
(ice-9 streams) in order to provide the same API. Then code can more
easily switch between the two implementations without requiring too much
source changes.

> Anyway, looks quite good and I'll play more with this module during the week.

Sounds good. Thanks!

Cheers,
Chris.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-09-11  6:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-11  5:38 SRFI 41, revisited Chris K. Jester-Young
2012-09-11  5:58 ` Daniel Hartwig
2012-09-11  6:56   ` Chris K. Jester-Young

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).