[Top][All Lists]

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

Re: Announcing the first actually stable release of guile-for-loops

From: Linus Björnstam
Subject: Re: Announcing the first actually stable release of guile-for-loops
Date: Fri, 24 Jan 2020 22:02:54 +0100
User-agent: Cyrus-JMAP/3.1.7-777-gdb93371-fmstable-20200123v1

On Fri, 24 Jan 2020, at 09:16, Arne Babenhauserheide wrote:
> Hi,
> Linus Björnstam <address@hidden> writes:
> > The syntax is more or less the same as racket's loops, and they are 
> > generally compatible. The code generated is for almost all cases as fast as 
> > hand-rolled code. They are all expressed as left or right folds, and are as 
> > such (apart from for/list, but read about that in the documentation) free 
> > of mutation. They are all converted to named lets.
> That’s cool!
> > (define (erathostenes n)
> >   (define vec (make-vector n #t))
> >   (for/list ([i (in-range 2 n)] #:when (vector-ref vec i))
> >     (for ([j (in-range/incr (* 2 i) n i)])
> >       (vector-set! vec j #f))
> >     i))
> >
> > The code and documentation is available here:
> >
> Is there a chance that this could get included in Guile (ice-9
> for-loops?) and become a SRFI?

John Cowan asked me to write a SRFI, but right now I don't think it is really 
in good enough shape to be a srfi. The for/foldr internals is a can of worms. 
Currently I am planning on removing the "procedural" part of that (stolen from 
what I saw in the macro expansion of racket's for/foldr) and resort to macros 
generating macros instead (due to otherwise losing syntax context information).

I could probably trim at least 100 lines of code from the implementation as it 
is now.

> If the code is non-portable (I guess the #:keywords are), the two
> existing implementations (Racket, Guile) would still be sufficient for a

The code is surprisingly portable as long as you are porting to a syntax-case 
scheme! Redefining the keywords as auxiliary syntax made porting an earlier 
version to chez scheme a 2 evening job :) I still had some annoying bugs that I 
didn't want to spend time on, but it shouldn't be hard. Some of the recent 
changes to the code was introduced to facilitate porting to non-keyword 
schemes: (in-range a b #:incr c) => (in-range/incr a b c), for example.

The only downside is that I would have to squat on when:, unless:, final:, 
break:, length: and fill:.


reply via email to

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