Reduce vs. Fold in Common Lisp
n16f.net
Reduce vs. Fold in Common Lisp
1–10 of 30 posts
Re: Reduce vs. Fold in Common Lisp
#2No, it's either two or zero arguments.
Re: Reduce vs. Fold in Common Lisp
#3…REDUCE functions can be called with zero, one or two list values. No, it's either two or zero arguments.
[1] http://www.lispworks.com/documentation/lw60/CLHS/Body/f_redu...
Re: Reduce vs. Fold in Common Lisp
#4If returning the initial value when the list is empty is considered a special case (or "surprising aspect") of REDUCE, then it's the same for FOLD, no?
Re: Reduce vs. Fold in Common Lisp
#5\f \x (f a0 (f a1 (f a2 x)))
So fold is just applying a list (function) to 2 arguments. Or you can be helpful and make something like fold := \f \x \l l f x which is useful for binding the f and the x and applying to multiple lists (everything is Curried of course)
LISP is not quite based on lambda calculus, so it should be no surprise it doesn't quite get reduce(i.e. fold) right.
See also church numerals, which are like lists but without the elements, they also have a 'fold':
\f \x f (f (f x))) == 3
We can make trees! Which again also have a 'fold'
\f \x f a0 (x a1) (f a2 (x a3) (x a4))
And many other more exotic folding data structures.
Re: Reduce vs. Fold in Common Lisp
#6>Fold is also simpler than REDUCE since it does not have any special case, making it easier to reason about its behaviour. If returning the initial value when the list is empty is considered a special case (or "surprising aspect") of REDUCE, then it's the same for FOLD, no?
Re: Reduce vs. Fold in Common Lisp
#7>Fold is also simpler than REDUCE since it does not have any special case, making it easier to reason about its behaviour. If returning the initial value when the list is empty is considered a special case (or "surprising aspect") of REDUCE, then it's the same for FOLD, no?
This shows up more clearly in statically-typed functional languages, where variadic functions like this are far less common. In that case, you typically see that `reduce` returns an option type, whereas `fold` does not. The types would look something like `fold :: (a -> b -> a) -> a -> List b -> a` vs `reduce :: (a -> a -> a) -> List a -> Option a`.
Re: Reduce vs. Fold in Common Lisp
#8Re: Reduce vs. Fold in Common Lisp
#9The history here is that Common Lisp gets reduce from APL ( https://aplwiki.com/wiki/Reduce ). It's not an attempt an ML-style fold, but a different formalism from a different lineage.
Re: Reduce vs. Fold in Common Lisp
#10The history here is that Common Lisp gets reduce from APL ( https://aplwiki.com/wiki/Reduce ). It's not an attempt an ML-style fold, but a different formalism from a different lineage.
The nifty thing about this operator in the array-langs compared to the usual fold function is that they usually define identity elements for all primitive functions, which means that no initial value has to be provided: https://aplwiki.com/wiki/Identity_element
The downside of this approach though, is that using reduce with non-primitive functions can result in domain errors (at least in APL). I think BQN's version of the operator is a bit nicer, in that it allows you to specify an initial value in this situation: https://mlochbaum.github.io/BQN/doc/fold.html