Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

2016-12-12 Thread Janis Voigtländer 
Okay, so I think that your implementation strategy is viable and addresses
the use cases that the earlier tick batching trick addressed. One could do
this as you propose with tasks, handling the “what about chained
continuations?” concern (that I had brought up) by deferring any andThened
tasks that are not Task.succeeds to later, not even attempting to include
their result messages into the current “epoch”.

I wonder how predictable this implementation would be for a user of
animations/ticks. They would have to keep a model in mind of what happens
when. The situation with non-chainable tick effects is conceptually
simpler. Or, to put it differently, maybe the actual use cases for tick
effects are all such that one only wants to “trigger something in the next
epoch directly”, and giving the user the ability to andThen on a tick may
tempt them into bad structuring of their code? Constraints in an API can be
very valuable, so if there are certain effects (ticks and possibly others)
for which better user code will result from taking the ability of
andThen-chaining
away from the user, then that would be justification for having a
separation between Task and Cmd (independently of the question of whether
andThen *can* be given some involved semantics on those effects). But I’m
not making a strong statement on that being the case here. And in any case,
you could reply that such a separation, taking andThen away from the user
for certain effects, could be put on top of an only-Tasks implementation
via a wrapper type that exposes only some of the Task operations; so it
would not require making both Task and Cmd primitive types. And you would
probably be right.
​

2016-12-13 1:54 GMT+01:00 Mark Hamburg :

> More "implementation" notes for this theoretical discussion. If you
> dropped off earlier, you can stay dropped off and leave it to Janis and me.
> If you are following along, here's another little tweak:
>
> I just looked at the implementation of tasks and saw that they make very
> heavy use of andThen. They probably don't need to be implemented this
> way, but they are. So, I would simplify the logic I present above and and
> get rid of the deferred queue. When an animation frame occurs, it enqueues
> all of the active tasks for the tick and then runs the execution queue
> until it is empty before actually invoking the view function. The moment
> something triggers code that does not resolve immediately, it ceases to be
> an issue ahead of the view rendering, but until that happens we chew
> through everything that is outstanding. This could be a bit more work
> before doing the animation rendering, but it's simpler code and simpler to
> explain.
>
> Mark
>
> On Mon, Dec 12, 2016 at 6:03 AM, Mark Hamburg 
> wrote:
>
>> Ah. Sorry. My misunderstanding. I went looking for the Effects.tick
>> replacement in 0.17+ and only found AnimationFrame.
>>
>> Mark
>>
>> On Sun, Dec 11, 2016 at 10:32 PM Janis Voigtländer <
>> janis.voigtlaen...@gmail.com> wrote:
>>
>>> Mark, wow, a lot of material. I’m not able to digest all of it right
>>> now. But something quick I want to say, because I have the impression that
>>> there is a misunderstanding about the current state of tick batching
>>> support.
>>>
>>>
>>> This:
>>>
>>>
>>>
>>>
>>> Since I wasn’t proposing to get rid of subscriptions and since this
>>> functionality is covered through subscriptions, my proposal arguably
>>> doesn’t cause a problem.
>>>
>>>
>>>
>>>
>>> baffles me. I’m not sure what you mean by “this functionality is covered
>>> through subscriptions”. Tick batching wasn’t covered through signals (the
>>> closest predecessors of subscriptions), and isn’t covered through
>>> subscriptions (or at all!) right now.
>>>
>>>
>>> Specifically and relatedly, concerning this:
>>>
>>>
>>>
>>>
>>> The special behavior for tick wasn’t particularly documented for the
>>> 0.16 Effects module and isn’t really documented for the 0.17+
>>> AnimationFrame module.
>>>
>>>
>>>
>>>
>>> I should clarify that the tick batching trick as existed in the 0.16
>>> Effects module is *not implemented* for Elm 0.17+. Apparently since
>>> gamey stuff is not anymore in Elm’s focus, Evan didn’t bring the “first
>>> ever effect manager” over to the new world when effect managers as such
>>> became a thing.
>>>
>>>
>>> (Did I indicate previously that tick batching as existed before is a
>>> thing currently in core or other 0.17/0.18 packages? I don’t think so.
>>> I was only bringing it up as a thing that can be done with effect managers
>>> and benefits from, maybe even is absolutely dependent on, having separate
>>> concepts of Task and Cmd. To decide about maintaining that latter
>>> stance, will require digesting your material more fully.)
>>>
>>>
>>> ​
>>>
>>> 2016-12-11 21:26 GMT+01:00 Mark Hamburg :
>>>
>>> Since I wasn't proposing to get rid of subscriptions and since this
>>> functionality is covered through

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

2016-12-12 Thread Mark Hamburg 
A better way of putting this: Haskell's IO monad structures a particular
set of interactions with the outside world. By making all foreign
interactions go through tasks, Elm could use its task monad to structure
interactions with the outside world. The difference then is that Haskell
has more syntactic sugar around monads than Elm does.

Mark

On Mon, Dec 12, 2016 at 8:19 PM, Mark Hamburg  wrote:

> One doesn't need them to be asynchronous but making them asynchronous
> helps reinforce the notion that this is happening outside the Elm universe.
> And if you want monads, Elm's tasks are monadic.
>
> Mark
>
> On Mon, Dec 12, 2016 at 6:16 AM, 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com> wrote:
>
>> On Friday, December 9, 2016 at 8:07:33 PM UTC, Mark Hamburg wrote:
>>>
>>> While there are certainly times when synchronous calls would have been
>>> nice, I recognize that having synchronous behavior for potentially mutable
>>> external state also tends to imply a lot about execution order — something
>>> that a pure functional language expects to be more free about. Hence, I
>>> think it's reasonable to force operations that need to deal with the
>>> external world to be asynchronous.
>>>
>>
>> Consider monads in other fp langauges. You don't need to have an
>> asynchronous model to work with external state and side effects.
>>
>> I suppose you could describe Elm's event driven loop as a monad, in the
>> sense that it chains together sequences of functions over messages.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

2016-12-12 Thread Mark Hamburg 
One doesn't need them to be asynchronous but making them asynchronous helps
reinforce the notion that this is happening outside the Elm universe. And
if you want monads, Elm's tasks are monadic.

Mark

On Mon, Dec 12, 2016 at 6:16 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Friday, December 9, 2016 at 8:07:33 PM UTC, Mark Hamburg wrote:
>>
>> While there are certainly times when synchronous calls would have been
>> nice, I recognize that having synchronous behavior for potentially mutable
>> external state also tends to imply a lot about execution order — something
>> that a pure functional language expects to be more free about. Hence, I
>> think it's reasonable to force operations that need to deal with the
>> external world to be asynchronous.
>>
>
> Consider monads in other fp langauges. You don't need to have an
> asynchronous model to work with external state and side effects.
>
> I suppose you could describe Elm's event driven loop as a monad, in the
> sense that it chains together sequences of functions over messages.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] “TypeError: domNode is undefined” and other errors with Elm and 3rd party JS libraries

2016-12-12 Thread ryanbarth 
I posted this over on Stack Overflow 
,
 
but thought I would ask here too.

I have been trying to use Elm applications to work with a handful of "UI 
Widget" type libraries. In particular I have been working with highlight.js 
and CodeMirror.

This  is a set of 
pared down code snippets from the project. The "Simple" example is just the 
raw elm app with no 3rd party libraries to show the expected result of the 
application. "Highligh JS" is a version showing errors working with the 
highlight.js library. Finally "CodeMirror" shows issues working with the 
CodeMirror library.

The source code for the above examples can be found here 
. The pertinent files are 
/src/*.elm and docs/*.html

The CodeMirror example gives the error from the title while the Highlight 
JS example results in a "corrupted" DOM.

Many 3rd party JS libraries modify the DOM. How do you work with those 
libraries cleanly in Elm?

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] onClick while shift key pressed

2016-12-12 Thread Marshall handheld Flax 
Is there an idiomatic to either: (a) trigger a message to fire only when 
the mouse is clicked *while the shift button is pressed*, or (b) include 
attributes (such as whether the shift button is pressed) as part of the 
message trigged by onClick?

Thanks so much for Elm!

Marshall

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

2016-12-12 Thread Mark Hamburg 
More "implementation" notes for this theoretical discussion. If you dropped
off earlier, you can stay dropped off and leave it to Janis and me. If you
are following along, here's another little tweak:

I just looked at the implementation of tasks and saw that they make very
heavy use of andThen. They probably don't need to be implemented this way,
but they are. So, I would simplify the logic I present above and and get
rid of the deferred queue. When an animation frame occurs, it enqueues all
of the active tasks for the tick and then runs the execution queue until it
is empty before actually invoking the view function. The moment something
triggers code that does not resolve immediately, it ceases to be an issue
ahead of the view rendering, but until that happens we chew through
everything that is outstanding. This could be a bit more work before doing
the animation rendering, but it's simpler code and simpler to explain.

Mark

On Mon, Dec 12, 2016 at 6:03 AM, Mark Hamburg  wrote:

> Ah. Sorry. My misunderstanding. I went looking for the Effects.tick
> replacement in 0.17+ and only found AnimationFrame.
>
> Mark
>
> On Sun, Dec 11, 2016 at 10:32 PM Janis Voigtländer <
> janis.voigtlaen...@gmail.com> wrote:
>
>> Mark, wow, a lot of material. I’m not able to digest all of it right now.
>> But something quick I want to say, because I have the impression that there
>> is a misunderstanding about the current state of tick batching support.
>>
>>
>> This:
>>
>>
>>
>>
>> Since I wasn’t proposing to get rid of subscriptions and since this
>> functionality is covered through subscriptions, my proposal arguably
>> doesn’t cause a problem.
>>
>>
>>
>>
>> baffles me. I’m not sure what you mean by “this functionality is covered
>> through subscriptions”. Tick batching wasn’t covered through signals (the
>> closest predecessors of subscriptions), and isn’t covered through
>> subscriptions (or at all!) right now.
>>
>>
>> Specifically and relatedly, concerning this:
>>
>>
>>
>>
>> The special behavior for tick wasn’t particularly documented for the 0.16
>> Effects module and isn’t really documented for the 0.17+ AnimationFrame
>> module.
>>
>>
>>
>>
>> I should clarify that the tick batching trick as existed in the 0.16
>> Effects module is *not implemented* for Elm 0.17+. Apparently since
>> gamey stuff is not anymore in Elm’s focus, Evan didn’t bring the “first
>> ever effect manager” over to the new world when effect managers as such
>> became a thing.
>>
>>
>> (Did I indicate previously that tick batching as existed before is a
>> thing currently in core or other 0.17/0.18 packages? I don’t think so. I
>> was only bringing it up as a thing that can be done with effect managers
>> and benefits from, maybe even is absolutely dependent on, having separate
>> concepts of Task and Cmd. To decide about maintaining that latter
>> stance, will require digesting your material more fully.)
>>
>>
>> ​
>>
>> 2016-12-11 21:26 GMT+01:00 Mark Hamburg :
>>
>> Since I wasn't proposing to get rid of subscriptions and since this
>> functionality is covered through subscriptions, my proposal arguably
>> doesn't cause a problem. But that's just getting through the loophole of
>> this specific example to dodge this particular case, so let me see if I can
>> get straight what the special property is that we need to preserve if we
>> were still trying to implement a tick command in the same manner of the
>> 0.16 tick effect. (It's worth noting as a side note that in 0.16, all
>> effects other than tick were tasks, so obviously tasks are close to
>> covering the role of commands — née effects — but tick may point to extra
>> wrinkles.) I'm not going to assume a constraint by the current task
>> implementation, but any revised implementation has to have a clear behavior
>> in conjunction with the existing task APIs since its those APIs that make
>> tasks an attractive alternative to commands.
>>
>> The special behavior for tick wasn't particularly documented for the 0.16
>> Effects module and isn't really documented for the 0.17+ AnimationFrame
>> module. Am I correct that the concern is that when the animation frame
>> "arrives":
>>
>>
>>1. We run all of the update functions before actually calling the
>>view function; and
>>2. Any tick effects that result from those updates will be batched
>>together for the next animation frame
>>
>> Was there anything else that I'm missing?
>>
>> The first point means that any implementation is going to have to be
>> built in conjunction with the Elm runtime since coordinating with the call
>> of the view function requires knowledge of when and how the view function
>> gets run. But since the whole point of this is to coordinate with the view
>> function that shouldn't be surprising nor is it particularly odd. It does
>> mean that my simple example using port tasks wouldn't work because it
>> wouldn't enjoy that coordination, but extra

Re: [elm-discuss] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

2016-12-12 Thread Zinggi 
> typed-arrays and ArrayBuffer.
That's basically it. Plus it would be nice if we could pattern match on 
binary files like in elixir/erlang.

On Monday, 12 December 2016 01:17:39 UTC+1, W. Brian Gourlie wrote:
>
> With regards to working with binary files, what all does that entail?  I 
> assume support for typed-arrays and ArrayBuffer... anything else?
>
> On Sunday, December 11, 2016 at 3:59:08 PM UTC-6, Zinggi wrote:
>>
>> (Elm discuss is fine for this. There are almost no open discussions on 
>> elm dev, as these are usually a waste of everyone's time.)
>>
>> For me, these things would be nice to have:
>>   * WebAudio API
>>   * File upload
>>   * Working with binary files, e.g. parsing
>>   * Persistent cache, offering access to local storage and maybe also 
>> IndexedDB
>>   (It's already there, but not released yet: 
>> https://github.com/elm-lang/persistent-cache)
>>   * Gamepad API
>>
>>
>> On Sunday, 11 December 2016 21:17:50 UTC+1, W. Brian Gourlie wrote:
>>>
>>> Per the elm-dev mailing list guidelines, I don't think this would be 
>>> appropriate there.  I'm also mostly interested in what other users feel are 
>>> shortcomings. Perhaps if I had a curated list of things, I could try and 
>>> bring it to the devs attention.  
>>>
>>> On Sunday, December 11, 2016 at 10:09:55 AM UTC-6, Duane Johnson wrote:

 I think this list is for discussion and is not as frequented by the elm 
 core developers, so you might try 
 https://groups.google.com/forum/?fromgroups#!forum/elm-dev

 They still show up here on occasion, but my impression is that they 
 primarily hang out over there.

 On Sat, Dec 10, 2016 at 3:03 PM, W. Brian Gourlie  
 wrote:

> I've noticed a fair amount of discussion around various shortcomings 
> of Elm's native libraries. Particular examples that affect me are the 
> limited Websocket API and no native typed-array implementation.  The 
> former 
> is limits me quite a bit, while the latter is simply a nice-to-have. I've 
> seen clamoring for file upload support as well. In any event, it would be 
> interesting to get an idea of what people feel are the Elm's biggest 
> shortcomings in terms of natively supported features.
>
> One thing that is frustrating as an Elm user is feeling in the dark 
> when it comes to feature requests. I know the team likes to batch their 
> efforts, but it's disheartening to see something sit for months 
> unanswered. 
> I'm hoping for two things to come out of this post: Get an idea of what 
> the 
> biggest pain points are in terms of natively supported API's, and to get 
> an 
> idea of what the Elm devs think. Any feedback really would be nice!
>
> Brian
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to elm-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Managing global state in Elm

2016-12-12 Thread Birowsky 
Erik, Mark, thanx a ton for your responses!

Erik, I was using that approach solely for the views but you made me think 
how I might do it in the updates too, which from here, seems like quite the 
prettification.  Thanx for that!

Mark, wow, thanx for the effort. If you could believe it, I built the whole 
thing. It was uber complicated considering it's one of the few things i've 
done in elm. There is so much plumbing and routing, in order to add a 
single api endpoint, i need to touch the codebase in exactly 8 places :}

I still don't whine tho. The good parts of Elm outshine any crap. I'm off 
to my next challenges. 

Have fun, communitymates!

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

2016-12-12 Thread Christopher Anand 
I would use an elm-only audio solution in teaching.

> On Dec 12, 2016, at 1:00 PM, Rex van der Spuy  wrote:
> 
> 
> For me, these things would be nice to have:
>   * WebAudio API
> 
> That's a big one for me too because I use Elm exclusively for game and 
> "interactive multimedia" development. 
> At the moment I have to drop into ports for Audio - I'd love to it all in Elm.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

2016-12-12 Thread Rex van der Spuy 


> For me, these things would be nice to have:
>   * WebAudio API
>

That's a big one for me too because I use Elm exclusively for game and 
"interactive multimedia" development. 
At the moment I have to drop into ports for Audio - I'd love to it all in 
Elm.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Documentation storage : IN or OUT ?

2016-12-12 Thread 'Rupert Smith' via Elm Discuss 
On Sunday, December 11, 2016 at 3:51:43 PM UTC, Ford wrote:
>
> I am wondering whether the current approach of mixing documentation with 
> real code is a good idea. I feel like placing it into separate file might 
> be better. 
>
> *Which approach do you favor and why?*
>

+1 for inline docs with code. Easier to maintain the doc as code changes. 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

2016-12-12 Thread 'Rupert Smith' via Elm Discuss 
On Friday, December 9, 2016 at 8:07:33 PM UTC, Mark Hamburg wrote:
>
> While there are certainly times when synchronous calls would have been 
> nice, I recognize that having synchronous behavior for potentially mutable 
> external state also tends to imply a lot about execution order — something 
> that a pure functional language expects to be more free about. Hence, I 
> think it's reasonable to force operations that need to deal with the 
> external world to be asynchronous.
>

Consider monads in other fp langauges. You don't need to have an 
asynchronous model to work with external state and side effects.

I suppose you could describe Elm's event driven loop as a monad, in the 
sense that it chains together sequences of functions over messages.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

2016-12-12 Thread Mark Hamburg 
Ah. Sorry. My misunderstanding. I went looking for the Effects.tick
replacement in 0.17+ and only found AnimationFrame.

Mark

On Sun, Dec 11, 2016 at 10:32 PM Janis Voigtländer <
janis.voigtlaen...@gmail.com> wrote:

> Mark, wow, a lot of material. I’m not able to digest all of it right now.
> But something quick I want to say, because I have the impression that there
> is a misunderstanding about the current state of tick batching support.
>
>
> This:
>
>
>
>
> Since I wasn’t proposing to get rid of subscriptions and since this
> functionality is covered through subscriptions, my proposal arguably
> doesn’t cause a problem.
>
>
>
>
> baffles me. I’m not sure what you mean by “this functionality is covered
> through subscriptions”. Tick batching wasn’t covered through signals (the
> closest predecessors of subscriptions), and isn’t covered through
> subscriptions (or at all!) right now.
>
>
> Specifically and relatedly, concerning this:
>
>
>
>
> The special behavior for tick wasn’t particularly documented for the 0.16
> Effects module and isn’t really documented for the 0.17+ AnimationFrame
> module.
>
>
>
>
> I should clarify that the tick batching trick as existed in the 0.16
> Effects module is *not implemented* for Elm 0.17+. Apparently since gamey
> stuff is not anymore in Elm’s focus, Evan didn’t bring the “first ever
> effect manager” over to the new world when effect managers as such became a
> thing.
>
>
> (Did I indicate previously that tick batching as existed before is a thing
> currently in core or other 0.17/0.18 packages? I don’t think so. I was
> only bringing it up as a thing that can be done with effect managers and
> benefits from, maybe even is absolutely dependent on, having separate
> concepts of Task and Cmd. To decide about maintaining that latter stance,
> will require digesting your material more fully.)
>
>
> ​
>
> 2016-12-11 21:26 GMT+01:00 Mark Hamburg :
>
> Since I wasn't proposing to get rid of subscriptions and since this
> functionality is covered through subscriptions, my proposal arguably
> doesn't cause a problem. But that's just getting through the loophole of
> this specific example to dodge this particular case, so let me see if I can
> get straight what the special property is that we need to preserve if we
> were still trying to implement a tick command in the same manner of the
> 0.16 tick effect. (It's worth noting as a side note that in 0.16, all
> effects other than tick were tasks, so obviously tasks are close to
> covering the role of commands — née effects — but tick may point to extra
> wrinkles.) I'm not going to assume a constraint by the current task
> implementation, but any revised implementation has to have a clear behavior
> in conjunction with the existing task APIs since its those APIs that make
> tasks an attractive alternative to commands.
>
> The special behavior for tick wasn't particularly documented for the 0.16
> Effects module and isn't really documented for the 0.17+ AnimationFrame
> module. Am I correct that the concern is that when the animation frame
> "arrives":
>
>
>1. We run all of the update functions before actually calling the view
>function; and
>2. Any tick effects that result from those updates will be batched
>together for the next animation frame
>
> Was there anything else that I'm missing?
>
> The first point means that any implementation is going to have to be built
> in conjunction with the Elm runtime since coordinating with the call of the
> view function requires knowledge of when and how the view function gets
> run. But since the whole point of this is to coordinate with the view
> function that shouldn't be surprising nor is it particularly odd. It does
> mean that my simple example using port tasks wouldn't work because it
> wouldn't enjoy that coordination, but extra requirements add extra
> implementation details.
>
> So, what we want is that we can divide time up with a series of animation
> frame events and at each animation frame event, we want to start a new
> epoch for collecting tick effects, run the updates driven by all effects
> collected for the previous epoch, and then do the view rendering. A naive
> implementation will just keep listening for all animation frames. A more
> sophisticated implementation will take steps to shutdown that observation
> when it is no longer necessary.
>
> The vague handwaving in the above is seemingly around what it means to say
> "run the updates driven by all effects collected for the previous epoch".
> In particular, how does this interact with task chains built using andThen,
> etc.? I am going to make a distinction between two ways to specify
> successor computation on a task. In one case with map the results or the
> error coming from the task to produce a new result or error. In the other,
> we map the results or the error coming from the task to produce a new task.
> I would argue that the first category is what leads to