Signal.mapMaybe : (a -> Maybe b) -> Signal a -> Signal b

[jhftrifork]

I have a type Action which represents user inputs. These appear in a signal of type Signal Action. Some user inputs should result in HTTP requests being sent. For this I want to use Http.send : Signal (Request a) -> Signal (Response String). So, given my Signal Action, I want to create a Signal (Request String). Since only some actions should produce a request, a map is not appropriate. Since the actions that produce a request must be transformed into requests, a filter is not appropriate either. I need a little of both, which I would call

Signal.mapMaybe : (a -> Maybe b) -> Signal a -> Signal b

(This is modelled after Data.Maybe.mapMaybe.)

I am not aware of how to implement this myself using the Signal API. The most general function available is foldp, but I don't know how to use this. It demands an "initial state", which doesn't make sense for a signal of HTTP requests. (Elm doesn't seem to make the behavior/event distinction that some libraries do.)

Could someone with some experience help me out?

[jvoigtlaender]

You might be looking for filterMap in @Apanatshka's Signal.Extralibrary:

http://package.elm-lang.org/packages/Apanatshka/elm-signal-extra/latest/Signal-Extra#filterMap

Also, it might make its way into the 0.15 version of Elm in some form, which is currently being discussed to indeed introduce something like the behavior/event distinction you mention.

[jvoigtlaender]

You might be looking for filterMap in @Apanatshka's Signal.Extralibrary:

http://package.elm-lang.org/packages/Apanatshka/elm-signal-extra/latest/Signal-Extra#filterMap

Also, it might make its way into the 0.15 version of Elm in some form, which is currently being discussed to indeed introduce something like the behavior/event distinction you mention.

[jhftrifork]

Ah, thanks, that library could be useful ... however, all of those functions still require me to provide an "initial value" for the resulting Signal. I genuinely don't know what the initial value for a signal of type Signal (Request String) should be, or could be. I've had the same problem with my Signal Action value, but I was able to hackily "solve" it by creating a NoAction : Action value, which I could use as the initial value.

In Elm currently, Http.send appears to send an initial HTTP request in situations which to me are unexpected. The lack of a behavior/event distinction appears to be the cause. Take this program:

import Signal
import Mouse
import Text
import Http

main = Signal.map Text.asText (Http.send (Signal.map (\click -> Http.get "http://elm-lang.org/") Mouse.clicks))

The behavior of this program is to send a GET request to http://elm-lang.org/ on initial page load, and every time that the mouse is clicked. The fact that it sends a request on initial page load is unexpected, at least to me. I don't actually know how to fix the bug in that program. Could someone show me how?

Out of interest, could you point me to the discussion on introducing the behavior/event distinction in Elm? Chalk me up as very much in favor of that.

[jhftrifork]

Ah, thanks, that library could be useful ... however, all of those functions still require me to provide an "initial value" for the resulting Signal. I genuinely don't know what the initial value for a signal of type Signal (Request String) should be, or could be. I've had the same problem with my Signal Action value, but I was able to hackily "solve" it by creating a NoAction : Action value, which I could use as the initial value.

In Elm currently, Http.send appears to send an initial HTTP request in situations which to me are unexpected. The lack of a behavior/event distinction appears to be the cause. Take this program:

import Signal
import Mouse
import Text
import Http

main = Signal.map Text.asText (Http.send (Signal.map (\click -> Http.get "http://elm-lang.org/") Mouse.clicks))

The behavior of this program is to send a GET request to http://elm-lang.org/ on initial page load, and every time that the mouse is clicked. The fact that it sends a request on initial page load is unexpected, at least to me. I don't actually know how to fix the bug in that program. Could someone show me how?

Out of interest, could you point me to the discussion on introducing the behavior/event distinction in Elm? Chalk me up as very much in favor of that.

[jvoigtlaender]

About the potential introduction of a behavior/event distinction: Everything on the mailing list last month mentioning "stream" and/or "varying" would be relevant. There is a lot of discussion back and forth, about naming and about semantics. At the moment, the pendulum seems to be swinging back to a situation where the distinction is not made prominent, only an optional thing for this release, but potentially introduced for real with the next release. But see for yourself:

• a thread on the mailing list that is titled "Try 0.15 alpha online", but starts with the words "LIST ONLY! Not for posting around the internet!", so I'm not giving the link here
• https://groups.google.com/d/msg/elm-discuss/O4IUJjMNXVE/T5YtI8KdnDcJ
• https://groups.google.com/d/msg/elm-discuss/xq6iKNACsxw/Sq_UMcJ6xpcJ
• https://groups.google.com/d/msg/elm-discuss/w2Rmim4IUn4/94JZ4gmn8GwJ
• possibly other threads as well

[jvoigtlaender]

About the potential introduction of a behavior/event distinction: Everything on the mailing list last month mentioning "stream" and/or "varying" would be relevant. There is a lot of discussion back and forth, about naming and about semantics. At the moment, the pendulum seems to be swinging back to a situation where the distinction is not made prominent, only an optional thing for this release, but potentially introduced for real with the next release. But see for yourself:

• a thread on the mailing list that is titled "Try 0.15 alpha online", but starts with the words "LIST ONLY! Not for posting around the internet!", so I'm not giving the link here
• https://groups.google.com/d/msg/elm-discuss/O4IUJjMNXVE/T5YtI8KdnDcJ
• https://groups.google.com/d/msg/elm-discuss/xq6iKNACsxw/Sq_UMcJ6xpcJ
• https://groups.google.com/d/msg/elm-discuss/w2Rmim4IUn4/94JZ4gmn8GwJ
• possibly other threads as well

[evancz]

@jvoigtlaender and @Apanatshka, how come no one has made a library for this? Has someone? I think we all know how it would be done, right?

[evancz]

@jvoigtlaender and @Apanatshka, how come no one has made a library for this? Has someone? I think we all know how it would be done, right?

[Apanatshka]

Made a library for what? Signal utility functions are already in elm-signal-extra.

[Apanatshka]

Made a library for what? Signal utility functions are already in elm-signal-extra.

[evancz]

For streams/events. We all know that we can model a thing with no default value with Signal (Maybe a) where it starts as Nothing and then is Just on every event. Why has no one made a library that exposes an API for streams that uses this fact? I guess I have not been encouraging of such things?

[evancz]

For streams/events. We all know that we can model a thing with no default value with Signal (Maybe a) where it starts as Nothing and then is Just on every event. Why has no one made a library that exposes an API for streams that uses this fact? I guess I have not been encouraging of such things?

[Apanatshka]

I had that planned for elm-signal-extra. But @rehno-lindeque beat me to it with his "deferred" signals experiment. I don't think it was fully developed though, so I can probably add a simple steam-ish thing to elm-signal-extra.

[Apanatshka]

I had that planned for elm-signal-extra. But @rehno-lindeque beat me to it with his "deferred" signals experiment. I don't think it was fully developed though, so I can probably add a simple steam-ish thing to elm-signal-extra.

[jhftrifork]

@jvoigtlaender thanks for the links. Interesting. It looks like you guys are serious about introducing the behavior/event distinction. (Btw, I prefer the "varying" terminology. "Behavior" is a terrible choice.) I peeked at the newer HTTP library; it looks much more mature. I hope it becomes usable ASAP, given that HTTP is fundamental to most web applications (!).

[jhftrifork]

@jvoigtlaender thanks for the links. Interesting. It looks like you guys are serious about introducing the behavior/event distinction. (Btw, I prefer the "varying" terminology. "Behavior" is a terrible choice.) I peeked at the newer HTTP library; it looks much more mature. I hope it becomes usable ASAP, given that HTTP is fundamental to most web applications (!).

[rehno-lindeque]

Oh by the way, please don't use the deferred signals library :) I'd like to remove it from elm-packages now that elm's semantics are progressing.

I haven't been able to follow any of the work that is going on very closely (so, sorry if this is a naive response), but the opinion I settled on the last time that I thought about this was that "foldl" semantics everywhere with Maybe's for events would be the best thing. https://groups.google.com/d/msg/elm-discuss/o12cuZbEv4M/uuyBmfpOOMIJ

I came to this because I felt that there's almost always special behavior (spinners on the screen etc) associated with the "uninitiated / unloaded" state of something in bigger apps. I suspect that counting mouse clicks, for example, is actually not representative of what people will use signals for.

[rehno-lindeque]

Oh by the way, please don't use the deferred signals library :) I'd like to remove it from elm-packages now that elm's semantics are progressing.

I haven't been able to follow any of the work that is going on very closely (so, sorry if this is a naive response), but the opinion I settled on the last time that I thought about this was that "foldl" semantics everywhere with Maybe's for events would be the best thing. https://groups.google.com/d/msg/elm-discuss/o12cuZbEv4M/uuyBmfpOOMIJ

I came to this because I felt that there's almost always special behavior (spinners on the screen etc) associated with the "uninitiated / unloaded" state of something in bigger apps. I suspect that counting mouse clicks, for example, is actually not representative of what people will use signals for.

[jvoigtlaender]

I'm closing this issue, since there seems to be nothing actionable to it anymore. (Interesting discussion, but that has served its purpose.)

[jvoigtlaender]

I'm closing this issue, since there seems to be nothing actionable to it anymore. (Interesting discussion, but that has served its purpose.)