Re: guile style

[jerry <jdinardo@nycap.rr.com>]

On 6/19/21 1:59 PM, Linus Björnstam wrote:

Unlike Donald Knuth, I can't stop myself from premature optimization and
so far, in my short Guile career, I have almost always used my option 3.
I will look into srfi-158 and srfi-171 because they look very interesting.

Based on the responses here, I get the feeling that there is no one 
right way which makes me happy. The reason that I reached out to the 
mailing list is that I recently read that explicit recursion was the 
"goto" of Lisp. Because I like things to be fast/efficient, I always try 
to find a tail call optimized recursion algorithm. I am just looking 
into prompts which apparently will let me break out of folds which was
often an annoyance for me in Haskell. Thanks for all the responses.


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