Example usage of laziness: We have an expensive layout algorithm which depends both on the data being laid out and the view size. Whenever either of these changes, we need to re-run the layout algorithm but we would prefer to do the computation only when absolutely necessary and only once for any given set of parameters.
What keeps us from using lazy views for this is that the actual view instantiation optimizes based on the portion that is visible. If we used the view system to memoize the layout independent of the visible range then we couldn't introduce a dependency on the visible range below that point in the hierarchy. Mark P.S. Cyclic structures can be avoided by having the compiler perform a strongly connected component analysis (e.g., using Tarjan's algorithm) and disallowing any SCC's that include anything other than function definitions. In fact, not doing so likely leaves open other cyclic cases and hence getting rid of Lazy likely does not eliminate cycles and instead just narrows the cases for which Elm is suitable. > On Nov 26, 2017, at 4:22 PM, N H <[email protected]> wrote: > > Basically, the way things work in Elm is that things exist if people need > them -- and can demonstrate the need. So far, there haven't been much need > for memoization, outside of the render loop. In fact, the main place where > lazy has been used at all has been for generating fuzzy values for elm-test. > There, I benchmarked and proved that elm-test is faster _without_ > memoization. If you can identify a _real_ problem that you have that needs > implicit memoization at the function level (rather than the render level, > which elm-lang/virtual-dom provides) then make a case for it. > >> On 20 November 2017 at 11:51, W. Gordon Goodsman <[email protected]> >> wrote: >> Oh, I understand the rationale, but it limits the general usefulness of lazy >> lists, as certain types of problems need memoization, and without Lazy as it >> currently exists there is no way to accomplish it without JavaScript. >> >> Just because the creators of the language don't see a need for it doesn't >> mean it doesn't exist. Even for a lazy list of random numbers, no >> memoization means that new random numbers will be computed every time the >> list is scanned, meaning the lazy list won't appear to be static. >> >>> On Nov 20, 2017 17:35, "'Rupert Smith' via Elm Discuss" >>> <[email protected]> wrote: >>>> On Friday, November 17, 2017 at 1:25:02 PM UTC, GordonBGood wrote: >>>> The rational to depreciating these seems to be performance when applied to >>>> their limited use in tests and I see that, as I tried to make changes to >>>> Lazy that would improve its lack of performance when run on some >>>> JavaScript engines that handle internal functions calling functions very >>>> poorly. >>> >>> Gordon, it took me a bit of digging through various docs and updates on >>> elm-dev to understand it, but... the rational for deprecating elm-core/lazy >>> with memoization, is that it allowed recursive structures to be created on >>> the heap, and all other ways in which that was possible have been >>> eliminated. This is all described here: >>> >>> https://gist.github.com/evancz/07436448b7d6c947f21742dab46d1218 >>> >>> It seems to be partly motivated by making garbage collection simpler - >>> presumably with WebAssembly in mind. I honestly don't know much of a real >>> advantage that is, but it seems that was the trade-off decision that has >>> already been made. >>> -- >>> 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/BM_ZmUk-vck/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. > > -- > 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.
