Why no dropRepeats in Elm-0.15?

[jvoigtlaender]

That function was in the standard lib for quite some time. It has uses, for example here:

https://groups.google.com/d/msg/elm-discuss/2CHk-bE0Gpw/7Jw76C8LCwUJ

Also, it was used in the runtime, see #198.

[evancz]

I think it can be defined in terms of foldp and filterMap so I wanted to get rid of the lower-level implementation. I did not get around to doing it though. The key question was "what exactly should we be exposing?"

dropRepeatsBy : (a -> b) -> Stream a -> Stream a
dropRepeatsWith : (a -> a -> Bool) -> Stream a -> Stream a
dropRepeats : Stream a -> Stream a
dropRepeatsByReference : Stream a -> Stream a

smooth : Varying a -> Varying a
...

All of these seem plausible to me, but I wasn't sure what to pick as the actual API, needed to do other stuff, and was pretty sure most could be defined in terms of existing stuff. What do you think of the options?

[evancz]

I think it can be defined in terms of foldp and filterMap so I wanted to get rid of the lower-level implementation. I did not get around to doing it though. The key question was "what exactly should we be exposing?"

dropRepeatsBy : (a -> b) -> Stream a -> Stream a
dropRepeatsWith : (a -> a -> Bool) -> Stream a -> Stream a
dropRepeats : Stream a -> Stream a
dropRepeatsByReference : Stream a -> Stream a

smooth : Varying a -> Varying a
...

All of these seem plausible to me, but I wasn't sure what to pick as the actual API, needed to do other stuff, and was pretty sure most could be defined in terms of existing stuff. What do you think of the options?

[jvoigtlaender]

Yeah, now that Stream.filterMap exists, the need for dropRepeats is indeed reduced. So maybe even wait with introducing it altogether. Potentially, uses of it will disappear as people are steered towards other solutions using filterMap directly rather than dropRepeats (possibly implemented using filterMap) plus something else.

If introducing it back, my preference would be for dropRepeats and/or dropRepeatsWith of the above.

I wouldn't want smooth available. In fact, in a world where Varying and Stream are distinguished (and in which Varyings are combined only via mapN, while Streams are combined only via merge, fairMerge, mergeMany), I'd prefer that one cannot even observe repeated "events" with the same value on a Varying. That is, I would prefer if Stream.fromVarying would always do an implicit dropRepeats. But that probably is for consideration at another time.

For the moment, I'd be fine closing this issue here. Let other people bring it up again if they really miss dropRepeats sorely.

[jvoigtlaender]

Yeah, now that Stream.filterMap exists, the need for dropRepeats is indeed reduced. So maybe even wait with introducing it altogether. Potentially, uses of it will disappear as people are steered towards other solutions using filterMap directly rather than dropRepeats (possibly implemented using filterMap) plus something else.

If introducing it back, my preference would be for dropRepeats and/or dropRepeatsWith of the above.

I wouldn't want smooth available. In fact, in a world where Varying and Stream are distinguished (and in which Varyings are combined only via mapN, while Streams are combined only via merge, fairMerge, mergeMany), I'd prefer that one cannot even observe repeated "events" with the same value on a Varying. That is, I would prefer if Stream.fromVarying would always do an implicit dropRepeats. But that probably is for consideration at another time.

For the moment, I'd be fine closing this issue here. Let other people bring it up again if they really miss dropRepeats sorely.

[evancz]

Okay, sounds good to me!

I don't think I agree on Stream.fromVarying in that one way to think of a Varying value is as (a, Stream a) and I think it'd be unfortunate to have to do expensive structural equality checks all the time.

We've seen a use case for dropRepeatsByReference in Prezi, which is having a bunch of core logic in Elm that feeds into many many ports. If we change one thing, we don't want all the ports to hear about it. Dropping by reference is interesting in that it's super cheap and it covers this case well.

In any case, I'm happy to hold off on this and let the community sort it out. I think we may be able to connect this to throttling of streams (perhaps dropRepeats is an edge behavior of a more general throttling abstraction?) but I have no idea what that might look like!

[evancz]

Okay, sounds good to me!

I don't think I agree on Stream.fromVarying in that one way to think of a Varying value is as (a, Stream a) and I think it'd be unfortunate to have to do expensive structural equality checks all the time.

We've seen a use case for dropRepeatsByReference in Prezi, which is having a bunch of core logic in Elm that feeds into many many ports. If we change one thing, we don't want all the ports to hear about it. Dropping by reference is interesting in that it's super cheap and it covers this case well.

In any case, I'm happy to hold off on this and let the community sort it out. I think we may be able to connect this to throttling of streams (perhaps dropRepeats is an edge behavior of a more general throttling abstraction?) but I have no idea what that might look like!