One could define fold as a generic operation that replaces the empty list 
with a constant (for example an identity element) and replaces the "cons" 
operator with a function that takes an element and a partial result.  This 
is consistent with other ways to define generalized folds over recursive 
data structures.  For example for trees you can replace the leaf node with 
a constant and replace the internal node with a binary function.  The key 
idea here is that fold directly reflects the natural structure of the 
underlying data structure.  ie, the way you would draw a picture of the 
underlying data structure is exactly the picture of the execution order. 
 If we are consistent with this, then fold will be defined for lists to be 
the same as foldRight for lists.  For more detailed exposition to motivate 
this definition, see the paper "Merging Monads and Folds for Functional 
Programming", by Meijer and Jeuring. 
<http://dspace.library.uu.nl/bitstream/handle/1874/20910/jeuring_95_mergingmonads.pdf>

One could also define a fold (as scala does) to be not-necessarily-linear 
-- the execution order is unspecified and left up to the implementer.  So 
in scala, a fold can split up a list into many pieces (sublists) and 
process the sublists in parallel, and then fold them up to obtain the final 
answer.  In this case, it is not necessaria foldLeft or a foldRight.  It 
could actually be a fold-from-the-middle or even 
fold-from-many-places-in-the-middle.  In order to make sure the answer is 
well-defined, the folding operator is required to be associative.

IMO it would be a good idea to avoid confusion with these alternative 
semantics by not reusing the name "fold" at all, or else adopting one of 
the conventional meanings (if we can agree what the most common meaning is).

On Thursday, October 20, 2016 at 11:32:12 AM UTC-4, Max Goldstein wrote:
>
> Normally I'm opposed to syntax or name changes. But I think this or some 
> variation is a good idea. (Maybe foldl becomes fold, since it's usually the 
> one you want.)
>
> That said, it's all subject to Evan's approval. 
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to