Add a new function: Signal.sendMessage : Message -> Task () ()

[rgrempel]

It would sometimes be convenient for third-party libraries to create functions that take a Message for a parameter, rather than an Address and an action. For instance, contrast these two signatures:

sendMessageWhenSomethingHappens : Address a -> a -> Task () ()

sendMessageWhenSomethingHappens : Message -> Task () ()

At the moment, the second signature is legal, but doesn't accomplish anything, because there is nothing which a third-party library can do with a Message. (Since Message is an opaque type and there are no functions which take Message as a parameter).

I'm assuming that Message is an opaque type in part so that it is possible to provide a Message without exposing the Address (or, for that matter, the action) to the function. However, it is exactly that which would sometimes also be useful when it comes to third-party libraries.

So, what I am proposing with this pull request is to include a sendMessage function that would take the Message as a parameter and return a Task which, when executed, will send the Message. I would offer these further thoughts for your consideration:

• Including the sendMessage function would still leave Message an opaque type -- one still would not be able to extract the Address or the action.
• Message does not need to be parameterized, which has some advantages if the third-party library needs to put the messages in a List. That is, you could put several messages in a List Message even if the action types were different, which would not be possible for a List (Address a, a).
• The sendMessage function would simply return a Task, which would still need to be sent to a port to be executed. This is why the function does not rely on Native.Signal.sendMessage, which does some magic to actually perform the Task. (We can't rely on that here, because then Signal.sendMessage would not be a pure function).
• It would not be possible to put this function in a signal-extra library as a preliminary step, because it cannot be implemented in a third-party library.

In the end, it just seems odd that the Message type can't be used by third-party libraries -- I would submit that a Signal.sendMessage would cure that oddity without creating any problems.

[rgrempel]

I believe that accepting this pull request would allow the following proposal to be experimentally implemented as a third-party library.

elm-lang/elm-plans#7

This might be nice, in that this change is a smaller change to core than that change would be.

[rgrempel]

I believe that accepting this pull request would allow the following proposal to be experimentally implemented as a third-party library.

elm-lang/elm-plans#7

This might be nice, in that this change is a smaller change to core than that change would be.

[evancz]

Adding to #322, seems plausible to me.

[evancz]

Adding to #322, seems plausible to me.

[mgold]

Alternatively, if the larger mailbox revamp was accepted, this would be part of it.

[mgold]

Alternatively, if the larger mailbox revamp was accepted, this would be part of it.

[rgrempel]

I should say that I do support the larger mailbox revamp, which would (as @mgold says) make this redundant.

[rgrempel]

I should say that I do support the larger mailbox revamp, which would (as @mgold says) make this redundant.