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 <mhamburg...@gmail.com>:
> 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 <overmind...@gmail.com>
> 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 elm-discuss+unsubscr...@googlegroups.com.
>> 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
> 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.
