Email list hosting service & mailing list manager

Re: [PATCH] add SRFI: srfi-121; generators John Cowan (21 Jan 2021 18:40 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Mark H Weaver (23 Jan 2021 00:59 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Shiro Kawai (23 Jan 2021 02:15 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Arthur A. Gleckler (23 Jan 2021 02:18 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Mark H Weaver (23 Jan 2021 06:38 UTC)
Re: [PATCH] add SRFI: srfi-121; generators John Cowan (26 Jan 2021 03:30 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Linus Björnstam (26 Jan 2021 07:08 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Marc Nieper-Wißkirchen (26 Jan 2021 07:15 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Linus Björnstam (26 Jan 2021 16:03 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Arthur A. Gleckler (08 Apr 2021 15:54 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Linus Björnstam (11 Apr 2021 15:52 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Arthur A. Gleckler (11 Apr 2021 16:17 UTC)
Re: [PATCH] add SRFI: srfi-121; generators Linus Björnstam (27 Jan 2021 15:33 UTC)

Re: [PATCH] add SRFI: srfi-121; generators Linus Björnstam 26 Jan 2021 06:49 UTC

Sorry, I though this was in the guile mailing list.

--
  Linus Björnstam

On Tue, 26 Jan 2021, at 07:48, Linus Björnstam wrote:
> Hi Y'all!
>
> I have an efficient, almost done implementation of srfi-121. I believe
> it lacks generator-unfold, but that is all. make-coroutine-generator is
> implemented using delimited continuations and runs a lot faster than
> the one in the reference implementation, with the caveat that it is
> apparently slightly incompatible: the coroutine generator usage in
> (srfi 146 hash) yielded the wrong result - despite my version passing
> all tests.
>
> If the maintainers of guile are interested, I could clean this code up
> and add accumulators and make sure it conforms to the srfi document.
>
> I have already spent some time integrating srfi-171 into guile, so I'm
> not entirely unfamiliar with the task.
>
> Best regards
>   Linus Björnstam
>
> On Tue, 26 Jan 2021, at 04:29, John Cowan wrote:
> > Note that 121 is withdrawn, so people should implement 158.
> >
> > On Sat, Jan 23, 2021 at 1:38 AM Mark H Weaver <xxxxxx@netris.org> wrote:
> > > Hi Arthur,
> > >
> > > "Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:
> > > > It's not a bad idea for the sample implementation to be as clear as
> > > > possible at the expense of performance.
> > >
> > > I agree that it's desirable for one of the sample implementations to be
> > > as simple and clear as possible, for the purpose of clarifying the
> > > specification.
> > >
> > > > But it certainly wouldn't hurt to have a supplemental document making
> > > > recommendations about possible performance improvements, or even a
> > > > second implementation.
> > >
> > > Sounds good.  For SRFIs such as 121 and 158, where efficiency is
> > > important, I think that a second sample implementation tuned for
> > > performance would be a useful addition.
> > >
> > >      Regards,
> > >        Mark