Thanks for your responses.
If it used equality then imagine suddenly comparing a huge model that you
> passed in, the speed benefits are entirely gone at that point.
I'm not sure if huge model always requires huge cost. If `{ largeModel =
largeModel }` is passed and two largeModel are reference equal, it is cheap
cost to compare them.
view model = lazy someViewHelper model.data
> someViewHelper data = someView { data = data }
Yeah, this is good for workaround, but it needs interface to be changed. I
often pass large-grained models to let views choose what parameters to use
by their responsibility, but this way lazy never works. So breaking into
small models are possible but I wonder it is good for maintainability.
2016-09-13 11:54 GMT-05:00 Mark Hamburg <[email protected]>:
> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/AFnzfJtzfRA/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
