Writing the result of a Task to the Console

[rgrempel]

First of all, thanks for picking this up for Elm 0.16!

I was trying to use elm-console in a context where I have a Task that produces a String, and I want to write this string to the console. Here's some code to illustrate:

task : Task () String
task =
    Task.succeed "String"

io : Task () (IO ())
io =
    Task.map Console.putStrLn task

port runner : Task () (Signal (Task x ()))
port runner =
    Task.map Console.run io

Now, in this case the Task is obviously trivial, but imagine code where there really was an substantial Task involved that ultimately could be mapped to a String.

The code above will compile, but it doesn't really make any sense (and doesn't work), because a Task which results in a signal of tasks isn't really sensible within Elm, for a variety of reasons. So, it's a dead end.

So, I was trying to conceive of what is missing here. One way of thinking about it would be that we need a function of this form:

fromTask : Task x a -> IO (x, a)

Now, one complication for implementation would be arranging for the task to be executed when the IO is executed, but that doesn't seem impossible.

If one had this "bridge" between Task-world and IO-world, I think it would cover a lot of cases.

Some others one could imagine are:

onSuccess : Task x (IO a) -> IO a

onError : Task (IO x) a -> IO x

So, I'm wondering whether I'm thinking about this the right way -- is there a better way to imagine how this might work?

In passing, I think there are similar puzzles re: Signals and IO ... for instance, what if you had a Signal String and you wanted to write each String to the console as it arrived? I'm not sure how you'd do that either, but I haven't thought much about it.

[rgrempel]

OK, I belatedly realized that my practical problem was easy enough to solve -- it's easy to create a Task that itself writes a String to the console. So I don't really need to be in IO world particularly, just to get a string written.

However, I think the general issue is still potentially interesting.

[rogeriochaves]

@rgrempel I have a problem that is somewhat similar to this #8

[rgrempel]

Given #8 (comment), I think my original use case was misconceived -- it just isn't what this module is for. So, I'll close this.