"Ch. A. Herrmann" <[EMAIL PROTECTED]> writes:
> that's true, of course. Furthermore, aside from "x==x", optimizations
> could deal with "x-x", "x && (not x)" and many other expressions.
>
> Concerning "safety". As far as I can see there is only a single reason:
> Partially correct programs term
On 26-Sep-2000, Ch. A. Herrmann <[EMAIL PROTECTED]> wrote:
> What happens, if
>
>(a) an optimizer replaces (x==x) by True?
>If the optimizer is not permitted to do that,
>its power appears to be limited severely.
If I was implementing an optimizing Haskell compiler, I would
I wrote,
Ch> Concerning "safety". As far as I can see there is only a single
Ch> reason: Partially correct programs terminate more often.
and forgot to say:
"provided that the Haskell classes like Eq or Num have
an underlying semantics and the programmer has an obligation
that the progr
Hi,
> "Bjorn" == Bjorn Lisper <[EMAIL PROTECTED]> writes:
Bjorn> I imagine expressions like x==x could appear as the result of
Bjorn> transformations in program specialisation, like specialising
Bjorn> f x x
Bjorn> where
Bjorn> f x y = if x==y then
Bjorn> Rep
Michael Marte wrote:
> (First I defined
>
> class Eager a where
> eager :: a -> a
>
> and some instances:
>
> instance Eager Int where
> eager i = i `seq` i
For Int (and other base types), forcing to WHNF is as far as you can go,
so I think you can simplify the above to
> instance
Hello,
thank you for the discussion on eager evaluation.
For solving my memory problem I finally used the
x == x `seq` return x
approach because it is easier to derive Eq classes automatically than to
write some sequentialisation functions.
(First I defined
class Eager a where
e
John Hughes <[EMAIL PROTECTED]> writes:
> As far as the power of the optimizer is concerned, my guess is programmers
> very rarely write x==x (unless they MEAN to force x!), so the loss of
> optimization doesn't matter. Of course, in principle, an optimizer *could*
> replace x==x by x`seq`True (i
>As far as the power of the optimizer is concerned, my guess is programmers
>very rarely write x==x (unless they MEAN to force x!), so the loss of
>optimization doesn't matter.
I imagine expressions like x==x could appear as the result of
transformations in program specialisation, like specialisi
"Ch. A. Herrmann" wrote:
> Hi,
>
> John> There's an easier way to force structures hyperstrictly. To
> John> force x to be evaluated to normal form before computing y,
> John> write (x==x) `seq` y
>
> I'm heavily confused here.
>
> What happens, if
>
>(a) an optimizer replaces (x=
Tue, 26 Sep 2000 13:29:39 +0200 (MET DST), John Hughes <[EMAIL PROTECTED]> pisze:
> Of course, in principle, an optimizer *could* replace x==x by
> x`seq`True (if x is known to be of base type), and the x`seq` might
> well be removed by later transformations (if x can be shown to be
> defined, so
John> There's an easier way to force structures hyperstrictly. To
John> force x to be evaluated to normal form before computing y,
John> write (x==x) `seq` y
I'm heavily confused here.
What happens, if
(a) an optimizer replaces (
On Tue, 26 Sep 2000, Ch. A. Herrmann wrote:
> John> write (x==x) `seq` y
> I'm heavily confused here.
> What happens, if
>
>(a) an optimizer replaces (x==x) by True?
>If the optimizer is not permitted to do that,
>its power appears to be limited severely.
Remember that
Hi,
John> There's an easier way to force structures hyperstrictly. To
John> force x to be evaluated to normal form before computing y,
John> write (x==x) `seq` y
I'm heavily confused here.
What happens, if
(a) an optimizer replaces (x==x) by True?
If the optimizer is no
Simon PJ says:
Did you try "seq"?
x `seq` y
should evalute x to WHNF before returning y. If x is a pair
you may need to say
seqPair x `seq` y
where
seqPair (a,b) = a `seq` b
in order to force the compon
Did you try "seq"?
x `seq` y
should evalute x to WHNF before returning y. If x is a pair
you may need to say
seqPair x `seq` y
where
seqPair (a,b) = a `seq` b
in order to force the components.
Simon
| -Original Message-
| From: Michael Marte [mailto:[EMAIL P
15 matches
Mail list logo