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

[Linus Björnstam]

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:
> > https://hg.sr.ht/~bjoli/guile-for-loops
> 
> 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
> SRFI.

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:.

/Linus