Sorry, it is of course Jan-Willem's compiler that is called Eager
Haskell, the Ghc version was called optimistic Haskell.
There's also the old precursor to these, the Optimistic G-machine,
that performs some non-lazy computations. (And it can even do them
while garbage collecting!)
No, I wasn't suggesting that evaluate can tell the difference, just
that you can add dubious "functions".
You can evaluate with eager evaluation and some kind of threads+fair
scheduler. Both pH and the (short lived) Eager Haskell version of
ghc did this. (Well, I'm not sure pH ever got th
[EMAIL PROTECTED] wrote:
And what alternatives (besides call by name without sharing) are there?
http://doi.acm.org/10.1145/944705.944731
http://doi.acm.org/10.1145/581690.581694
I always think lazy evaluation is space and time optimal.
Google for "optimal reduction" (Lamping, Asperti, Gue
Lennart Augustsson wrote:
> No, you were right the first time. :) The denotational semantics is the
> important one. Haskell can be executed by other means than graph
> reduction. (That's why the report says a "non-strict" rather than
> "lazy" language.) Peculiar language constructs may allow y
On 9/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
With this in mind the equations
1) return _|_ == Return _|_
2) _|_ `seq` (return _|_) == _|_
can be interpreted:
1) when reducing a return-redex (i.e. evaluating it), we get weak-head
normal form without evaluating the argumen
On Sep 14, 2006, at 16:20 , [EMAIL PROTECTED] wrote:
Michael Shulman wrote:
On 9/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
So `seq` forces its first argument. When we define
f x = x `seq` (Return x)
we thereby get
f _|_== _|_
f [] == Return []
f (x:xs) == Return (x:x
Michael Shulman wrote:
> On 9/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> So `seq` forces its first argument. When we define
>> f x = x `seq` (Return x)
>> we thereby get
>> f _|_== _|_
>> f [] == Return []
>> f (x:xs) == Return (x:xs)
>> To compare, the semantics of (eva
On 9/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
So `seq` forces its first argument. When we define
f x = x `seq` (Return x)
we thereby get
f _|_== _|_
f [] == Return []
f (x:xs) == Return (x:xs)
To compare, the semantics of (evaluate) is
evaluate _|_== ThrowExceptio
Michael Shulman wrote:
> On 9/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> > * (a `seq` return a) = evaluate a *right now*, then produce an IO
>> action
>> > which, when executed, returns the result of evaluating a. Thus, if
>> > a is undefined, throws an exception right now.
>>
>> is
On 9/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> * (a `seq` return a) = evaluate a *right now*, then produce an IO action
> which, when executed, returns the result of evaluating a. Thus, if
> a is undefined, throws an exception right now.
is a bit misleading as there is no evaluati
Hello Michael,
you are correct. Only
> * (a `seq` return a) = evaluate a *right now*, then produce an IO action
> which, when executed, returns the result of evaluating a. Thus, if
> a is undefined, throws an exception right now.
is a bit misleading as there is no evaluation "right now". It's
On 9/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The GHC documentation says that (evaluate a) is not the same as (a
> `seq` return a). Can someone explain the difference to me, or point
> me to a place where it is explained?
(evaluate a) is "weaker" than (a `seq` return a). (a `seq` r
Michael Shulman wrote:
> The GHC documentation says that (evaluate a) is not the same as (a
> `seq` return a). Can someone explain the difference to me, or point
> me to a place where it is explained?
(evaluate a) is "weaker" than (a `seq` return a). (a `seq` return a) is
always _|_ whereas (eval
13 matches
Mail list logo