Excerpts from Heinrich Apfelmus's message of Mon Apr 25 04:01:03 -0400 2011:
The thing is that lazy evaluation is referentially transparent while I
don't care about [(1,4),(2,2)] vs [(2,2),(1,4)] is not.
Perhaps more precisely, laziness's memoization properties rely on the
referential
Edward Z. Yang wrote:
Laziness can be viewed as a form of controlled mutation, where
we overwrite a thunk with its actual value, thus only running
the code once and reaping great time benefits.
[..]
Hash tables take advantage of this fact by simply chaining together values
in a linked list if
Laziness can be viewed as a form of controlled mutation, where
we overwrite a thunk with its actual value, thus only running
the code once and reaping great time benefits.
I've been toying around with some ideas where we do alternative
forms of controlled mutation. One such idea has to do with
On Sun, 24 Apr 2011, Edward Z. Yang wrote:
Laziness can be viewed as a form of controlled mutation, where
we overwrite a thunk with its actual value, thus only running
the code once and reaping great time benefits.
Reminds me on a discussion about 'blue printing' in the past:
Edward Z. Yang ezy...@mit.edu writes:
I've been toying around with some ideas where we do alternative
forms of controlled mutation. One such idea has to do with memoization.
[..]
Hash tables take advantage of this fact by simply chaining together values
in a linked list if they land in the
Yep. It harkens to my days of forcing impure, non-thread-safe
C libraries into nice, pure, Haskell FFI bindings. I suppose what
I'd like to do here is work in the unsafe IO much more closely
with GHC's existing facilities, so that we spend as much time
as possible /not/ in unsafePerformIO. A
