There are things you can do in your code to help and things that Elm could
do (maybe already does) in its implementation to help:
For the data construction issue, you need to create an intervening function
that does the construction:
view model = lazy someViewHelper model.data
someViewHelper data = someView { data = data }
But probably not:
view model = lazy (\data -> someView { data = data }) model.data
The compiler could optimize that but might not. That leads to the list of
things the compiler could do (and may be doing) to help:
- Lift constant expressions. This would help with anonymous functions,
config records, etc.
- Optimize { m | field = value } to return m if m.field is already equal
(referentially) to value.
Sadly, this last optimization doesn't get us anywhere if we are routinely
working with tagged union members since we can't just return the value we
already have. The compiler could cache the last few values constructed with
any given type tag but that creates a drag on the GC.
Mark
P.S. I shifted my code for a while to a form where update had the
signature: update : Msg -> Model -> ( Maybe Model, Cmd Msg ) with the maybe
on the result being used so that unchanged could be indicated by returning
Nothing. This, however, makes sequences of updates harder because we don't
have the model always available which is nice for writing operators like
the following:
(!>) : (model, Cmd msg) -> (model -> (model, Cmd msg)) -> (model, Cmd msg)
(!>) : (oldModel, oldCmd) update =
let
(newModel, newCmd) = update oldModel
in
(newModel, Cmd.batch [oldCmd, newCmd])
The version that works with maybe results needs triples for the state which
can largely be hidden but does tend to then require beginUpdate and
endUpdate functions as well.
On Tue, Sep 13, 2016 at 7:34 AM, OvermindDL1 <[email protected]> wrote:
> Lazy is purely and entirely for speed reason, the referential equality is
> for that purpose. If it used equality then imagine suddenly comparing a
> huge model that you passed in, the speed benefits are entirely gone at that
> point. It is very much a corner case that should not be used except in
> very specific situations. :-)
>
>
> On Tuesday, September 13, 2016 at 7:43:28 AM UTC-6, James Wilson wrote:
>>
>> I had similar feelings; lazy uses a magical referential equality between
>> things that afaik isn't exposed elsewhere; to me it would be more
>> obvious/clear if it used the same sort of equality as everything else (==),
>> which I'd hope would be able to short circuit the meat of the checking if
>> referentially equal anyway.
>>
>> Basically, I'd be interested to hear more about the decision to use
>> referential equality with lazy too :)
>>
>> On Tuesday, 13 September 2016 12:09:05 UTC+1, Yosuke Torii wrote:
>>>
>>> Hi,
>>>
>>> I have a question about Html.Lazy.
>>>
>>> Now I'm optimizing rendering using Html.Lazy but I feel it is difficult
>>> to use. I found the arguments are not often *referentially* equal and
>>> the view functions are unfortunately called. There are some problems around
>>> this.
>>>
>>>
>>> 1. Sometimes new values are created every time.
>>>
>>> view model = lazy someView { data = model.data }
>>>
>>> 2. Views do not know how arguments are passed.
>>>
>>> view model = lazy grandchildView model
>>>
>>> 3. It is not easy to know if optimization succeeds or not.
>>>
>>> view model = Debug.log "Unfortunately called!" <| text (toString model)
>>>
>>>
>>> I made a demo to describe this problem.
>>>
>>> Source: https://github.com/jinjor/elm-issues/blob/master/src/HtmlLaz
>>> y.elm
>>> Demo: https://jinjor.github.io/elm-issues/html-lazy.html
>>> (9 example views, but 4 ~ 9 are not optimized unfortunately)
>>>
>>> So my question is:
>>>
>>> - Is it a bad idea to compare by *normal *equal?
>>> - Have anyone already solved this problem?
>>>
>>>
>>> Thanks.
>>>
>> --
> 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
