[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile style
Re: guile style
Sat, 19 Jun 2021 19:59:36 +0200
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?
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
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.