Re: [elm-discuss] Re: keeping functions out of the model

[Mark Hamburg]

> On Oct 5, 2016, at 6:17 PM, Joel Clermont  wrote:
> 
> Equality: Similar to serialization, is this just a matter of me having to be 
> smarter when doing manual optimizations that look at model equality? Or is 
> there something in the runtime/compiler that is going to break or be less 
> optimized as a result?

If you (or anyone else contributing code to your project including any public 
Elm packages) use == with values that might contain functions, you have a 
lurking runtime error waiting to happen.

Spreading the paranoia,
Mark

-- 
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: keeping functions out of the model

[Max Goldstein]

Thank you for your kind words, Joel.

If 0.18 debugging totally breaks an animations, I'll think of something. 
These are some valid concerns but I haven't seen a smoking gun yet.

-- 
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: keeping functions out of the model

[Max Goldstein]

Zinggi: My objection is that the easing function is part of the logical 
identity of the animation. It's tedious to keep track of the function 
separately. Also, animation concepts like velocity and retargetting rely on the 
easing function. "The same animation with a different easing function"… is not 
the same animation. 

-- 
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: keeping functions out of the model

[Mark Hamburg]

On Oct 5, 2016, at 5:22 AM, Noah Hall  wrote:
> 
> It makes it hard to perform eq on.

This is the big one from my standpoint. To optimize lazy views (and memory/gc 
behavior), I've at times written "smart" update functions that check for 
equality with existing values before constructing new values. This then started 
blowing up with a runtime exception caused by comparing functions for equality. 
Now, I'm paranoid and both avoid functions in models and equality comparisons 
because someone else may not have exhibited one or the other of these forms of 
caution.

It would be nice if Elm would treat functions that aren't obviously equal as 
unequal but I recognize that this could lead to compiler optimizations changing 
the behavior of programs which isn't great either.

Mark

-- 
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: keeping functions out of the model

[Zinggi]

This also has the added benefit that you can then use the same animation 
with different easing functions without having to duplicate the whole 
Animation record.

On Wednesday, 5 October 2016 10:01:25 UTC+2, Zinggi wrote:
>
> I think you could create an animation library that doesn't store any 
> functions in its model and still be able to let a user provide whatever 
> easing function they want.
>
> E.g. remove the ease key from your AnimRecord and let all functions that 
> currently take an Animation have an additional parameter easingFunction:
>
> animate : EasingFunction -> Time -> Animation -> Float
>
> This way a user of your library doesn't have to put any functions in their 
> model and you get both a function free model and endless customization by 
> providing whatever easing function a user needs.
>
> Am I missing something?
>
>
> On Wednesday, 5 October 2016 07:56:04 UTC+2, Max Goldstein wrote:
>>
>> Serialization: animations are view state. They can safely be left out of 
>> a serialized and persisted model.
>>
>> Print out the model: True, but if you're using animation in an app, 
>> you're beyond poking at the model in the REPL.
>>
>> Harder to equate: My animation library provides an "equals" function. In 
>> addition to sampling the easing function, it accounts for a few other ways 
>> animations can have different representations but be considered equal (e.g. 
>> start at time t with delay k == start at time t+k with no delay).
>>
>> "just store the things needed to create the function" -> This is 
>> essentially the "EasingDescription" idea I talked about above. The problem 
>> is that easing functions can be created in many way (sinusoids, 
>> polynomials, exponentials, bounces) and I want to allow the client to 
>> specify any function.
>>
>

-- 
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: keeping functions out of the model

[Zinggi]

I think you could create an animation library that doesn't store any 
functions in its model and still be able to let a user provide whatever 
easing function they want.

E.g. remove the ease key from your AnimRecord and let all functions that 
currently take an Animation have an additional parameter easingFunction:

animate : EasingFunction -> Time -> Animation -> Float

This way a user of your library doesn't have to put any functions in their 
model and you get both a function free model and endless customization by 
providing whatever easing function a user needs.

Am I missing something?


On Wednesday, 5 October 2016 07:56:04 UTC+2, Max Goldstein wrote:
>
> Serialization: animations are view state. They can safely be left out of a 
> serialized and persisted model.
>
> Print out the model: True, but if you're using animation in an app, you're 
> beyond poking at the model in the REPL.
>
> Harder to equate: My animation library provides an "equals" function. In 
> addition to sampling the easing function, it accounts for a few other ways 
> animations can have different representations but be considered equal (e.g. 
> start at time t with delay k == start at time t+k with no delay).
>
> "just store the things needed to create the function" -> This is 
> essentially the "EasingDescription" idea I talked about above. The problem 
> is that easing functions can be created in many way (sinusoids, 
> polynomials, exponentials, bounces) and I want to allow the client to 
> specify any function.
>

-- 
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: keeping functions out of the model

[Max Goldstein]

Serialization: animations are view state. They can safely be left out of a 
serialized and persisted model.

Print out the model: True, but if you're using animation in an app, you're 
beyond poking at the model in the REPL.

Harder to equate: My animation library provides an "equals" function. In 
addition to sampling the easing function, it accounts for a few other ways 
animations can have different representations but be considered equal (e.g. 
start at time t with delay k == start at time t+k with no delay).

"just store the things needed to create the function" -> This is 
essentially the "EasingDescription" idea I talked about above. The problem 
is that easing functions can be created in many way (sinusoids, 
polynomials, exponentials, bounces) and I want to allow the client to 
specify any function.

-- 
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: keeping functions out of the model

[Max Goldstein]

Hi, I'm the author of the second library you mentioned. It's natural to 
represent easing functions as, well, functions.

One way to avoid this would be to change (or supplement) 
elm-community/easing-functions 
 to contain a big union 
type of all the easings possible. Then we could have a function that turns 
that type into an easing function. The animation models would contain a 
reference to this EasingDescription rather than the function itself.

There are some major downsides to this approach, not counting the work 
involved and library clutter. First, consumers of the animation library 
will have to know about the EasingDescription; it couples the two libraries 
and causes the abstraction to leak. Second, animations will only be able to 
use easing functions that have descriptions, not any easing function they 
like. Finally, my library allows animations to be undone or retargeted, 
which involves working with the easing function in ways beyond the 
description.

So, a better approach might be to sample the easing function provided 
(perhaps 100 times in 0..1) and use linear interpolation between these 
samples. Many samples gives a more accurate animation but consumes more 
memory. This approach also means that retrieving an easing function from an 
animation will be inexact.

Even so, until someone tells me that everything will explode if you have 
functions in your model, I'm going to sit tight.

-- 
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.