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 <gordonbg...@gmail.com> 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" < > elm-discuss@googlegroups.com> 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/to >> pic/elm-discuss/BM_ZmUk-vck/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. > -- 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.
