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 trans
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 t
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 kin
"Edward Z. Yang" 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 same buc
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:
http://www.has
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 me