Signal as a Monad

[fosskers]

Signals are clearly Applicative Functors since:

instance Functor Signal where
   fmap = lift

instance Applicative Signal where
   pure = constant
   (<*>) = (~)

Before I had even discovered () I noticed the Applicative nature of Signals and was wondering how to implement the equivalent of (<*>) in Elm. Eventually I found () and thought it cool that it was native Elm. Upon closer inspection though we find it the opposite of Haskell, with (~) written in terms of lift* and not the other way around:

-- Elm.
(~) : Signal (a -> b) -> Signal a -> Signal b
f ~ a = lift2 (\f' a' -> f' a') f a

-- Pattern-matched / Haskell-like?
(~) : Signal (a -> b) -> Signal a -> Signal b
Signal f ~ a = lift f a

As far as I can tell, Signals are also Monads. If Signal is pattern-matchable, we could do the following, like the above:

(>>=) : Signal a -> (a -> Signal b) -> Signal b
Signal a >>= f = f a

(>>) : Signal a -> Signal b -> Signal b
a >> b = a >>= \_ -> b
-- And so on.

If it isn't pattern-matchable, could something be hacked in Native.Signal just like the Applicative definition? I've found a few times I've wanted Monadic code. Or will Applicative always be better with Signals? Am I missing some key Elm design choice?

[Apanatshka]

Actually, yes, you are missing a key design choice. But don't worry, you're not the only one who asked. I think these threads on the mailing list may be relevant.
But really the resource to look at is Evans thesis on Elm.

Because just referring to other resources is lazy, I'll also try to answer your question more directly:
Basically a monadic API for Signals allows you to "start" and "stop" Signals. So if you want purely functional semantics, you get Monadic FRP, and old concept that was very expressive but has lots of performance issues. Basically when you have this much control over Signals in a pure language, you need to save the history of every Signal for the duration of the program, giving you memory usage that grows linearly with time. At this point you should really read this post, because Evan explains it a lot better than I do.

For me a good reason not to want monadic Signals is because it complicates the meaning of code. In general can you imagine what something of type Signal (Signal Int) would look like? Because that basically says you have a time-dependant value that at any time is a value that is again dependant on time. I don't think there is nice way for that to make sense.
So what I do when I run into a Signal-of-Signal situation, is refactor my code. It mostly comes down to writing pure functions whenever you possibly can, like the advice Haskell folks give about the IO Monad. The only times I really miss some expressiveness is when introducing state using foldp. But I have an idea for improving Elm with respect to introducing state, so I expect that will be fixed some time in the future.

[laszlopandy]

Yes there is a intentional design choice in Elm to not include monadic bind
for signals. Having it would allow people to have functions which
dynamically create signals. (Of course it is always possible to write such
functions, but without bind you cannot do anything with their values).

Allowing people to dynamically create signals has two problems. First, it
breaks referential transparency because you could theoretically create a
stateful signal which depends on all previous mouse positions. If that
signal only started reading mouse positions when it was dynamically
created, then you could have two identical expressions which return
different results (because of being evaluated at different times).

Secondy, dynamic signals can lead to unintentional space and time leaks.
You can find examples in Haskell FRP libraries. Basically, it puts a lot of
burden on the programmer to make sure their code does not prevent previous
values or signals from being garbage collected.

On Tuesday, December 24, 2013, Colin Woodbury wrote:

Signals are clearly Applicative Functors since:

instance Functor Signal where
fmap = lift
instance Applicative Signal where
pure = constant
(<*>) = (~)

Before I had even discovered () I noticed the Applicative nature of
Signals and was wondering how to implement the equivalent of (<_>) in
Elm. Eventually I found () and thought it cool that it was native Elm.
Upon closer inspection though we find it the opposite of Haskell, with (~)
written in terms of lift_ and not the other way around:

-- Elm.() : Signal (a -> b) -> Signal a -> Signal bf ~ a = lift2 (\f' a' -> f' a') f a
-- Pattern-matched / Haskell-like?() : Signal (a -> b) -> Signal a -> Signal bSignal f ~ a = lift f a

As far as I can tell, Signals are also Monads. If Signal is
pattern-matchable, we could do the following, like the above:

(>>=) : Signal a -> (a -> Signal b) -> Signal bSignal a >>= f = f a
(>>) : Signal a -> Signal b -> Signal ba >> b = a >>= _ -> b-- And so on.

If it isn't pattern-matchable, could something be hacked in Native.Signaljust like the Applicative definition? I've found a few times I've wanted
Monadic code. Or will Applicative always be better with Signals? Am I
missing some key Elm design choice?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/413
.

[mgold]

There is also this quote from the PLDI paper:

The type system rules out programs that use signals of signals, for the following reason. Intuitively, if we have signals of signals, then after a program has executed for, say 10 minutes, we might create a signal that (through the use of foldp) depends on the history of an input signal, say Window.width. To compute the current value of this signal, should we use the entire history of Window.width? But that would require saving all history of Window.width from the beginning of execution, even though we do not know whether the history will be needed later. Alternatively, we could compute the current value of the signal just using the current and new values of Window.width (i.e., ignoring the history). But this would allow the possibility of having two identically defined signals that have different values, based on when they were created. We avoid these issues by ruling out signals of signals.

You should come to recognize the type of functions that cause trouble: a -> Signal b for some _non_polymorphic a and b. Notice that this is the type of the function you would pass to bind. It's problematic because it creates a signal-of-signal if you lift it.

For future reference, please use the mailing list for open-ended discussions like this (and search its archives first). The community tries to use GitHub primarily for specific, actionable bugs, rather than design choices.

[laszlopandy]

Ok Jeff explained it better. Thanks Jeff.

On Tuesday, December 24, 2013, Laszlo Pandy wrote:

Yes there is a intentional design choice in Elm to not include monadic
bind for signals. Having it would allow people to have functions which
dynamically create signals. (Of course it is always possible to write such
functions, but without bind you cannot do anything with their values).

Allowing people to dynamically create signals has two problems. First, it
breaks referential transparency because you could theoretically create a
stateful signal which depends on all previous mouse positions. If that
signal only started reading mouse positions when it was dynamically
created, then you could have two identical expressions which return
different results (because of being evaluated at different times).

Secondy, dynamic signals can lead to unintentional space and time leaks.
You can find examples in Haskell FRP libraries. Basically, it puts a lot of
burden on the programmer to make sure their code does not prevent previous
values or signals from being garbage collected.

On Tuesday, December 24, 2013, Colin Woodbury wrote:

Signals are clearly Applicative Functors since:

instance Functor Signal where
fmap = lift
instance Applicative Signal where
pure = constant
(<*>) = (~)

Before I had even discovered () I noticed the Applicative nature of
Signals and was wondering how to implement the equivalent of (<_>) in
Elm. Eventually I found () and thought it cool that it was native Elm.
Upon closer inspection though we find it the opposite of Haskell, with (~)
written in terms of lift_ and not the other way around:

-- Elm.() : Signal (a -> b) -> Signal a -> Signal bf ~ a = lift2 (\f' a' -> f' a') f a
-- Pattern-matched / Haskell-like?() : Signal (a -> b) -> Signal a -> Signal bSignal f ~ a = lift f a

As far as I can tell, Signals are also Monads. If Signal is
pattern-matchable, we could do the following, like the above:

(>>=) : Signal a -> (a -> Signal b) -> Signal bSignal a >>= f = f a
(>>) : Signal a -> Signal b -> Signal ba >> b = a >>= _ -> b-- And so on.

If it isn't pattern-matchable, could something be hacked in Native.Signaljust like the Applicative definition? I've found a few times I've wanted
Monadic code. Or will Applicative always be better with Signals? Am I
missing some key Elm design choice?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/413
.

[fosskers]

Thanks for the thorough answers guys! I understand the problem now. And yes I'll still to the lists from now on.