Should reference equality be a thing in a pure functional language? At least beyond a point where certain optimizations may or may not apply? So, for example, Html.Lazy uses reference equality as a fast way to short-circuit re-running a view function (and comparing the resulting tree) and that is a big win but from the standpoint of computed values, should you be able to care? Coming from more imperative languages, I would have tended to say "yes, reference equality should be a thing because as long as the language is strict we can be clear about where values are constructed". But then I think about the number of potential optimizations that forecloses. For example, an inline function, even if it closes over no values, is a value construction but they are so common that we would really like to be able to lift them out and avoid doing the construction repeatedly. So, then we're back to something like "No, Elm does not recognize any form of reference/construction equality ... but some low-level libraries may use it to provide optimizations". And in that case, it might be nice if the record update code recognized when it didn't need to construct a new record because a corollary to not supporting reference equality as a formal notion is that constructions may not always construct new values.
Mark On Tuesday, May 17, 2016 at 9:43:36 AM UTC-7, Janis Voigtländer wrote: > > If you are even thinking about "deep down", you are not considering > reference equality. Because reference equality, which lazy uses, simply > compares that the two objects/records are at the same memory address. A > question of "deep down" cannot arise. > > Am 17.05.2016 um 17:56 schrieb Steve Schafer <[email protected] > <javascript:>>: > > Yes, I'm aware of that. The model should be equal, but there may be > something buried deep down that's causing a problem. I think it may have to > do with something that effectively looks like this: > > y = { x | a = x.a } > > While Elm thinks that x == y, JavaScript does not. I've tried to expunge > all of these, but there may be something lurking somewhere. And Elm doesn't > make it easy to figure out where such things may exist. > > > On Tuesday, May 17, 2016 at 10:59:01 AM UTC-4, Janis Voigtländer wrote: >> >> You are aware that the functions from Html.Lazy use reference equality? >> So two models are only considered equal if they are the same JS object (at >> the the same pointer address). The zipper data structures I know don’t give >> that degree of equality after moving down and up again. >> >> >> 2016-05-17 15:43 GMT+02:00 Steve Schafer <[email protected]>: >> >>> No, I have a couple of ports that handle things like monitoring text >>> selection in input fields, but that's about it. I think what's happening is >>> that the differ is getting confused because of my use of a zipper data >>> structure; when I traverse down the structure and then back up, it *should >>> *be able to tell that the structure is unchanged, but it seems not to >>> be able to do that. I need to investigate further to determine exactly >>> what's going on. >>> >>> >>> On Friday, May 13, 2016 at 11:16:56 AM UTC-4, Janis Voigtländer wrote: >>>> >>>> Was your 0.16 code using Signal.forwardTo inside the view function? If >>>> so, there’s a good chance that 0.17 will please you with much better >>>> Html.lazy behavior. >>>> >>>> >>>> 2016-05-13 16:19 GMT+02:00 Steve Schafer <[email protected]>: >>>> >>>>> I *am* using Lazy, and in my specific 0.16 application (I haven't had >>>>> a chance to update it to 0.17 yet), I haven't found the rendering >>>>> optimizations to be all that smart. My view is a handful of Bootstrap >>>>> accordion-style sections, with the inactive ones empty and the active one >>>>> displaying a fairly large HTML table, typically twenty rows by twenty >>>>> columns (think spreadsheet). A no-op update with *zero *changes to >>>>> the model incurs about 200 ms of JavaScript processing time, essentially >>>>> all of it in the virtual DOM diffing and rendering process, according to >>>>> Chrome. There's no way that I can afford redundant updates that cost that >>>>> much. >>>>> >>>>> You keep saying that the model needs to stop listening to >>>>> subscriptions if it doesn't want to handle them, but there's no practical >>>>> way to make that work for some of the scenarios that have been mentioned >>>>> here. For example, say that your app wants to handle onKeyDown for just >>>>> the >>>>> up- and down-arrow keys, and ignore all other keys. How does one make >>>>> that >>>>> work, short of dropping out to JavaScript to create a custom event stream? >>>>> >>>>> >>>>> On Thursday, May 12, 2016 at 11:21:46 AM UTC-4, Noah Hall wrote: >>>>>> >>>>>> > The problem is that update is not an ordinary function, as it has >>>>>> side effects (rendering the view). If the view is complex, those side >>>>>> effects can be computationally expensive, so you still need some way to >>>>>> minimize redundant invocations of update. And it seems like the only >>>>>> practical way to do that would be to somehow prevent no-op events from >>>>>> ever >>>>>> reaching update. An alternative would be some sort of "escape clause" >>>>>> for >>>>>> update to be able to say, "I didn't change the model at all, so don't >>>>>> update the view." >>>>>> >>>>>> If you care a lot about this performance, then you should be using >>>>>> either Html.Lazy or elm-lang/lazy. By default the renderer is already >>>>>> very fast and very clever - this is how virtual-doms work, by >>>>>> generating diffs and checking if they actually need to re-render or >>>>>> not. If you want to not trigger things, then you need to use the >>>>>> model >>>>>> to stop listening to that subscription. >>>>>> >>>>>> On Thu, May 12, 2016 at 5:03 PM, Peter Damoc <[email protected]> >>>>>> wrote: >>>>>> > On Thu, May 12, 2016 at 5:54 PM, Janis Voigtländer >>>>>> > <[email protected]> wrote: >>>>>> >> >>>>>> >> So, the suggestion is that that solution should be different, >>>>>> moving the >>>>>> >> if-then-else into the update-function (and not having NoOp on a >>>>>> mapped Sub). >>>>>> >> A potential problem I see with this is when there is more than one >>>>>> >> update-function. Several components in a TEA setting, somehow >>>>>> combined. >>>>>> >> Couldn’t the new suggestion mean that one has to duplicate the >>>>>> if-then-else >>>>>> >> logic in several update-functions? >>>>>> > >>>>>> > Not in my understanding. >>>>>> > In a TEA setting, the top most component could do all the >>>>>> processing needed >>>>>> > and pass to the children only the relevant information. >>>>>> > This top level component could also use something like Lazy in the >>>>>> view to >>>>>> > optimize for "fake" updates. >>>>>> > >>>>>> > Basically, all the logic from around the subscriptions would end up >>>>>> in the >>>>>> > too most component. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > There is NO FATE, we are the creators. >>>>>> > blog: http://damoc.ro/ >>>>>> > >>>>>> > -- >>>>>> > 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. >>>>> >>>> >>>> -- >>> 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] <javascript:>. > 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.
