Re: guile style

[Linus Björnstam]

On Sat, 19 Jun 2021, at 14:16, jerry wrote:
> On 6/19/21 7:20 AM, Christopher Lam wrote:
> > Agree set! is not a desirable form. It is not consistently optimisable. 
> > I cannot find the reference in the manual.
> > 
> > Also consider the first form: you're building a list in 3 passes -- call 
> > iota to generate a list, call filter to navigate the list again, then 
> > fold to accumulate your answer. Therefore it's O(3N).
> > 
> > The preferred form is definitely from the little schemer.
> > 
> Haskell has something called stream fusion which can optimize the extra
> passes out in many cases. I wonder if Guile or any of the other scheme
> compilers can do that? 

Hi Jerry!

For this to work guile would need to be either pure or lazy. Lazy, because a 
value would only be pulled through the chain when needed, which would change 
the evaluation order in a way that would be compatible with side effects. Pure 
because without side effects fusing two loops can be done without fear.

Haskell is of course both. You can get lightweight laziness using srfi-158 - 
which isn't really loop fusion, but chaining 1000 generator clauses is still 
O(n). 

What guile does have is an eager construct that does something similar to loop 
fusion: transducers. Look at srfi-171. One can compose transducers without 
building want intermediate collections: (list-transduce (compose (tfilter 
even?) (tmap (lambda (x) (quotient x 2)))) + a-list) will keep all even numbers 
and divide them by 2, and sum them. No intermediate collections build. They 
have higher overhead, but are usually faster already at 2 steps.

Best regards
Linus Björnstam