guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)


From: Andy Wingo
Subject: Re: 01/02: Re-implement (ice-9 streams) in terms of (srfi srfi-41)
Date: Wed, 11 Mar 2015 09:30:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Hi!

Sorry, I tried to grab you by chat but I think we missed each other.

On Wed 11 Mar 2015 03:58, Mark H Weaver <address@hidden> writes:

>> commit aead655a45e689b332cfd148ecbb6d764e2c8eb8
>> Author: Andy Wingo <address@hidden>
>> Date:   Thu Mar 5 09:44:53 2015 +0100
>>
>>     Re-implement (ice-9 streams) in terms of (srfi srfi-41)
>>     
>>     * module/ice-9/streams.scm: Re-implement in terms of SRFI-41.  Passes
>>       tests.
>
> I think we can't do this because (ice-9 streams) are based on native
> Guile promises which provide built-in thread synchronization, whereas
> SRFI-41 streams are based on SRFI-45 promises which do not include
> thread synchronization.

Interesting, this isn't the objection I thought you might have :)

The motivating case is GDB, that because it supports guile before 2.0.9
that we can't use the excellent SRFI-41 streams there.  On the other
hand that's terrible to add new users to ice-9 streams, and indeed
terrible in Guile to have two disjoint lazy stream types.  (Perhaps this
is another problem that could be solved with polymorphism?  Dunno.)
Since GDB will expose streams in its interface, that means more and more
users of ice-9 streams, yuck.  `make-stream' is terrible.

Anyway reimplementing ice-9 streams in terms of srfi-41 provides a
migration path away from ice-9 streams, such that we can deprecate the
module and hopefully remove it some time.  I think you probably agree
that would be nice to do if we can manage it.

So, the question is -- is there a level of legacy fidelity of an
ice-9-streams-on-top-of-srfi-41 that would allow us to make this change?
Is it "identical" or is "pretty close" sufficient?  I submit that
"pretty close" is OK, for some definitions of pretty close, as long as
the changes are documented in NEWS.

So, what if we just document this change?  We could roll it back of
course but blah, srfi-41 is so much nicer.

Andy
-- 
http://wingolog.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]