I agree that for your application in testing where memoization is not
required, your implementation is much faster. In fact, your new
implementation of a lazy list without memoization isn't really a lazy list
but rather a Co-Inductive Stream (CIS), where the use of a forcing function
is actually a nop and unnecessary, and the next Stream function could be
called directly.
I have used such CIS's effectively where memoization was not required and
had associated cost.
However, it seems to me to be flawed thinking to eliminate memoization from
the publically accessible libraries just because no one has yet used it.
There are classes of problems that are inefficient and unnecessarily repeat
calculations without memoization.
For example, the Hamming numbers sequence can be produced elegantly using
true memoized lazy lists in Haskell as:
hamming() = 1 : foldr [] [5,3,2] where
u n s = r where
r = merge s (map (n*) (1:r))
merge [] b = b
merge a@(x:xs) b@(y:ys)
| x < y = x : merge xs b
| otherwise = y : merge a ys
Using memoized lazy lists, this algorithm is almost as elegant and
efficient in Elm as in Haskell, but using only CIS's makes it both time and
space inefficient, with redundantly repeated calculations and the streams
unable to be garbage collected due to the functions needing to retain back
pointers into the streams all the way back to the beginning.
There are many similar examples in mathematics and perhaps in graphics
applications.
It seems to me to be a mistake to limit the generality of the language
libraries just because the authors don't see a use case. While it is true
that many JavaScript engines (all except Microsoft Edge) limit the
efficiency of how memoization must be implemented for Elm (a function
generating a function), this won't always necessarily be true, and almost
certainly won't be true if and when Elm generates wasm code, now supported
by all major browsers.
CIS's are easy enough to generate that they could be defined where needed
as for the testing case, or could be a separate library.
Meanwhile the memoized Lazy type library really is needed, else there is no
way to implement memoization without custom JavaScript, which is frowned
upon.
On Nov 27, 2017 07:23, "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/to
>>> pic/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 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.
