[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile style
Re: guile style
Sat, 19 Jun 2021 22:21:39 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
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.
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.