Proposal: rename foldl til foldLeft and foldr to foldRight

[Robin Heggelund Hansen]

In Elm 0.18, primes are being removed as valid characters in a variable/function name. The reason being, which I whole heartedly agree with, that removing primes will incentivize people to write proper names, and also because the difference between model and model' isn't always easy to spot.

In the same spirit, I propose that we change the name of foldl to foldLeft, and the name of foldr to foldRight. The difference between foldl and foldr isn't to spot at a cursory glance. foldLeft is also more self-describing than foldl, it also matches what I say when I read foldl aloud while explaining code to others.

FYI: Scala has also called their functions foldLeft and foldRight.

I think this proposal would benefit both seasoned and new Elm developers.

[Max Goldstein]

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.

[Ambrose Laing]

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.

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

[Robin Heggelund Hansen]

Please stay on topic. This thread is strictly about the naming of foldl and foldr, nothing else.

[Martin DeMello]

I would be strongly opposed to renaming either foldl or foldr to just fold; that always confuses me when languages do it.

martin

On Thu, Oct 20, 2016 at 8:32 AM, Max Goldstein <maxgol...@gmail.com> 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Radford]

Changes like this I think make sense if it is part of a more general effort - i.e 'Elm is going to be known as the language with proper function names"i.e it sounds like a BDFL call. Has that every been stated by Evan or is it just something that appears to be in the same line of thinking as removing primes etc?

Not saying it's a bad idea BTW - especially since some people new to Elm won't be familiar with the terse style functions you see commonly in FP languages  -'foldr' 'cons' etc if they haven't used one of those languages

[Rupert Smith]

-1 from me. foldl and foldr are so commonly in use in other functional languages that they are an acceptable short hand. Who cares what Scala does.

[Peter Damoc]

On Mon, Oct 24, 2016 at 2:12 PM, 'Rupert Smith' via Elm Discuss <elm-d...@googlegroups.com> wrote:

-1 from me. foldl and foldr are so commonly in use in other functional languages that they are an acceptable short hand. Who cares what Scala does.

The main target of Elm are developers who come from imperative languages like javascript, python or ruby. 
People with a background in FP might actually get a little bit frustrated with Elm due to it deliberately leaving out certain facilities like type-classes.  

The thing is that if Elm convinces even a very small fraction of the JS devs to move to FP, that would be a huge win for FP. 

Considering this, it would actually make more sense to call foldl reduce and remove foldr all together while providing that functionality via reversing the list/array. 

This could make things more familiar for JS/Python/Ruby while maybe frustrating people coming from Haskell/OCaml/Erlang/Elixir.  

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Robin Heggelund Hansen]

Define "other functional languages". Clojure(script) doesn't have fold, but reduce. F# has fold and foldBack.

What other languages do is, however, besides the point. The question is, what is more readable? It's easier to confuse foldl with foldr than it is to confuse fold(Left) with foldRight. This goes for both new and existing Elm developers.

[Mike MacDonald]

There is also the TIMTOWTDI approach, favored by languages like Ruby: alias them. Have both `foldl` and `foldLeft`, `select` and `filter`, `inject` and `reduce`. I am not necessarily advocating this position, just enumerating another potential option.

[Brian Marick]

On Oct 20, 2016, at 9:12 AM, Robin Heggelund Hansen <skinn...@gmail.com> wrote:

In Elm 0.18, primes are being removed as valid characters in a variable/function name. 

That’s unfortunate. Non-alphabetical characters can be really useful for signaling intent.

For example, an ending <?> can usefully be a quick signal that the function is a boolean predicate. That’s less useful in a statically-typed language, but “less useful” is not the same thing as “useless”. 

Adding a prime mark has a long, even pre-computer, history of signaling. <x’> quickly tells the reader that the value is intimately bound up with <x> but has a contextually relevant difference. To be less abstract:

When working with SVG, it’s really awkward that `Svg.Attributes.x` takes a String argument, given that graphics often involves working with numeric values. So it’s not a horrible idea for graphics code to establish a convention that primed names take a (consistently, thus predictably) nonstandard type. 

I confidently predict that removing primes won’t result in `xInteger` definitions but rather `x2` - which I’d argue is less clear than x’

I could imagine libraries that said explicitly “In this library, functions doing <some thing> use the <‘> suffix, but functions doing <some other thing> use <!>. (Neither Ruby nor Clojure are really consistent, but experienced users know roughly how to react to functions ending in <!>.) Community pressure could help with that. 

[Max Goldstein]

I would love more Ruby-like names across the board, except for the presence of aliases, but Elm grew out of Haskell so it carries some of that history.

It really comes down to what Evan wants to do. People come to Elm from many languages, and everyone has preferences. Changing things makes upgrading harder, invalidates old code, and gives the larger community the impression that Elm is not stable.

[Peter Damoc]

On Tue, Oct 25, 2016 at 3:20 AM, Max Goldstein <maxgol...@gmail.com> wrote:

It really comes down to what Evan wants to do. People come to Elm from many languages, and everyone has preferences. Changing things makes upgrading harder, invalidates old code, and gives the larger community the impression that Elm is not stable.

Old code is already invalid for other reasons and getting to a highly polished 1.0 justifies the trouble that we, the innovators have to go through. 

Also, changes like these are mechanical and some kind of tooling could make it very easy to upgrade a large codebase.

reduce has a lot of notoriety built into it due to MapReduce.   

People frequently equate familiarity with good. :) 

[Wouter In t Velt]

Op dinsdag 25 oktober 2016 02:20:29 UTC+2 schreef Max Goldstein:

Changing things makes upgrading harder, invalidates old code, and gives the larger community the impression that Elm is not stable.

The question is whether different naming for "foldl" and "foldr" would bring enough benefits to be worth all these (temporary) drawbacks.

So:

• "foldLeft" and "foldRight" are easier to keep apart/ more readable - regardless of someone's previous language
• "reduce" and ("foldr" or nothing or something else) would be more familiar to people coming from JS (and possibly other languages too)

My own background is JS, so "reduce" is familiar. 

But at the same time, I use "foldl" way more often in Elm than I ever used "reduce" in JS, and in very different ways.

What I see as a structural drawback to "foldLeft" and "foldRight" is the length of the function names: shorter names are better, and (for me at least) the extra characters in the function names do not give me any relevant info or benefits.

90% of the time I use any fold, my output is the same in both directions. (like .sum or .maximum etcetera). 

I have never used "foldr" (yet).

[Robin Heggelund Hansen]

fold and foldRight then?

[Andrew Radford]

As people pointed out - it's a BDFL call, but it feels to me that this is the closest candidate to the spirit of the recent 'Let's go mainstream' BDFL calls. 

(Assuming that foldRight is sufficiently less commonly used so as to not make the ample suffix 'Right' burdensome, and the lack of suffix for fold reasonable)

On Tuesday, 25 October 2016 10:48:30 UTC+1, Robin Heggelund Hansen wrote:

fold and foldRight then?

[James Hamilton]

I agree with your sentiment in principle. I suppose the underlying question is whether or not this is actually going to be such a benefit to future users of elm that it would be worth inconveniencing current users who want to upgrade. Personally I'm quite comfortable with foldr and foldl but I understand the foldLeft and foldRight are more expressive. 

I used to use ember and its constant churn drove me to find an alternative which led me to elm. Not that the community elm behaves anything like ember in this regard, but still this blog post rather sums up the danger of making a lot of inconvenient changes for apparently abstract reasons. 

[Robin Heggelund Hansen]

I did a lot of work in ember myself, and I feel your pain, but this is still a 0.x product, and so it should be expected that some breakage is performed while we reach the best possible state of the language. It's different for Ember, which had a lot of breakage post 1.0.

[Rupert Smith]

On Tuesday, October 25, 2016 at 1:45:35 PM UTC+1, James Hamilton wrote:

I agree with your sentiment in principle. I suppose the underlying question is whether or not this is actually going to be such a benefit to future users of elm that it would be worth inconveniencing current users who want to upgrade. Personally I'm quite comfortable with foldr and foldl but I understand the foldLeft and foldRight are more expressive. 

I used to use ember and its constant churn drove me to find an alternative which led me to elm. Not that the community elm behaves anything like ember in this regard, but still this blog post rather sums up the danger of making a lot of inconvenient changes for apparently abstract reasons. 

Also, have you ever actually encountered a bug which was caused by misreading foldl for foldr or the other way around? I really don't find it hard to tell them apart. 

[Robin Heggelund Hansen]

Once, that I remember, after a refactoring. But this is more to do with the ease of reading code. I've several times seen foldr and read foldl. In general, I find names that differ by only a single letter a bad thing. Like wether and whether. Sure, now that i've pointed out that there is a difference here, it's easy enough to point it out. But given the proper context it can be easy to confuse one with the other, especially when the compiler (or the spell checker) don't point it out for you.

[Juan Soto]

I'm an observer (not an Elm programmer) but these discussions are interesting to me. I guess the question Elm programmers have to ask themselves is what Elm's purpose is? Haskell/traditional Functional ML language in the browser? PureScript fits that mold already, but if so the recent changes and this one go against that. A functional ML language aimed at the general population? Then I agree with the changes for readability, though to be honest `foldr` and `foldRight` are pretty close so I'd opts for an alias until 1.0.0.

[Sham Beam]

Does Elm have a deprecated keyword? It could ease the transition if
renaming does happen.

> <https://medium.com/@frustrated_ember_developer/ember-js-another-year-of-churn-instability-and-festering-frustrations-4d01838361cb#.ha438hsub> rather

> sums up the danger of making a lot of inconvenient changes for
> apparently abstract reasons.
>

> --
> 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...@googlegroups.com
> <mailto:elm-discuss...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Sham Beam

[James Hamilton]

That is a fair point, actually. I think the idea of aliasing the functions on 0.18 might be a good temporary measure which would allow the community to get used to the new function names without breaking any code and then the old ones can be removed in a later version. 

[Rupert Smith]

On Thursday, October 20, 2016 at 3:12:57 PM UTC+1, Robin Heggelund Hansen wrote:

In the same spirit, I propose that we change the name of foldl to foldLeft, and the name of foldr to foldRight. The difference between foldl and foldr isn't to spot at a cursory glance. foldLeft is also more self-describing than foldl, it also matches what I say when I read foldl aloud while explaining code to others.

Also worth pointing out that these libraries (and possibly others) have adopted the convention of using a single 'l' or 'r' to mean from-the-left and from-the-right: 

http://package.elm-lang.org/packages/Fresheyeball/elm-function-extra/1.1.0/Function-Extra

http://package.elm-lang.org/packages/elm-community/list-extra/3.1.0/List-Extra

http://package.elm-lang.org/packages/elm-community/array-extra/1.0.1/Array-Extra

[Wouter In t Velt]

Op woensdag 26 oktober 2016 13:21:03 UTC+2 schreef Rupert Smith:

Also worth pointing out that these libraries (and possibly others) have adopted the convention of using a single 'l' or 'r' to mean from-the-left and from-the-right: 

And the List library also has a scanl function (no scanr), which - should some renaming of foldl happen - would be nice to keep consistent.

[Robin Heggelund Hansen]

I think aliasing would just push the problem further into the future. At some point breakage would have to happen, there's no reason to not having it being done right now. It's not like your code base will be any smaller when the aliasing is removed.

True, the change should be reflected in similar functions. Just like library authors are encouraged to change the definition for andThen to be used with pipes instead of backticks (requires arguments to be flipped).

[Max Goldstein]

Evan has said that the best time to make breaking changes is right now. He's also said that he likes to batch changes, so they're easier for him to work on and make more sense when adopted as a community. For example, flipping andThen and removing backticks go together.

[Mike MacDonald]

Aliases could also remain forever, so people could choose which they prefer. However, this seems counter to the prevailing direction for Elm.

[Joey Eremondi]

Yeah, aliases make easy to write, but harder to read and learn, since a user might have only ever seen one and might not know what the other does.

--

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+unsubscribe@googlegroups.com.

[ratvis]

As someone barely literate in functional programming, and coming from javascript or ruby land, the thing that trips you up for a second is that it's not called reduce. 

Seeing two things named wordL and wordR, it's pretty clear for me what the difference between them might be.