| Although I have not looked into this much, My guess is it is an issue in
| the simplifier, normally when something is examined with a case
| statement, the simplification context sets its status to 'NoneOf []',
| which means we know it is in WHNF, but we don't have any more info about
| it. I wou
On Mon, Mar 19, 2007 at 03:22:29PM +, Simon Peyton-Jones wrote:
> | This reminds me of something I discovered about using strict fields in
> | AVL trees (with ghc). Using strict fields results in slower code than
> | doing the `seq` desugaring by hand.
>
> That is bad. Can you send a test cas
On Tue, Mar 20, 2007 at 01:53:47PM +, Malcolm Wallace wrote:
> Now, in the definition
> x = x `seq` foo
> one can also make the argument that, if the value of x (on the lhs of
> the defn) is demanded, then of course the x on the rhs of the defn is
> also demanded. There is no need for the
So we have an equation
x = seq x foo
In Haskell recursive equations are solved and you get the smallest
fix point.
The smallest solution to this equation is x = _|_, there are other
solutions,
but why should we deviate from giving the smallest fix point for seq
when we
do it for everythin
On Tue, 20 Mar 2007, "Bernie Pope" <[EMAIL PROTECTED]> wrote:
> Malcolm wrote:
>> x = x `seq` foo
> We can translate the definition of x into:
>
> x = fix (\y -> seq y foo)
>
> Isn't it the case that, denotationally, _|_ and foo are valid
> interpretations of the rhs?
>
> If we want to choos
x `seq` x=== x
and so
x = x `seq` x === x = x
but, in general,
x = x `seq` foo =/= x = foo
consider
x = x `seq` ((1:) x)
x = x `seq` ((1:) (x `seq` ((1:) x)))
x = x `seq` ((1:) (x `seq` ((1:) (x `seq` ((1:) x)
..
ignoring evaluation order, partially
Malcolm wrote:
> The Haskell Report's definition of `seq` does _not_ imply an order of
> evaluation. Rather, it is a strictness annotation.
That is an important point.
> Now, in the definition
> x = x `seq` foo
> one can also make the argument that, if the value of x (on the lhs of
> the
On Tue, Mar 20, 2007 at 01:53:47PM +, Malcolm Wallace wrote:
>
> Now, in the definition
> x = x `seq` foo
> one can also make the argument that, if the value of x (on the lhs of
> the defn) is demanded, then of course the x on the rhs of the defn is
> also demanded. There is no need for t
On Mar 20, 2007, at 9:53 AM, Malcolm Wallace wrote:
Ian Lynagh <[EMAIL PROTECTED]> wrote:
data Fin a = FinCons a !(Fin a) | FinNil
w = let q = FinCons 3 q
in case q of
FinCons i _ -> i
is w 3 or _|_?
Knowing that opinions seem to be heavily stacked against my
Ian Lynagh <[EMAIL PROTECTED]> wrote:
> data Fin a = FinCons a !(Fin a) | FinNil
> w = let q = FinCons 3 q
> in case q of
>FinCons i _ -> i
>
> is w 3 or _|_?
Knowing that opinions seem to be heavily stacked against my
interpretation, nevertheless I'd like to try
Simon Peyton-Jones wrote:
| This reminds me of something I discovered about using strict fields in
| AVL trees (with ghc). Using strict fields results in slower code than
| doing the `seq` desugaring by hand.
That is bad. Can you send a test case that demonstrates this behaviour?
OK, I'll try
| This reminds me of something I discovered about using strict fields in
| AVL trees (with ghc). Using strict fields results in slower code than
| doing the `seq` desugaring by hand.
That is bad. Can you send a test case that demonstrates this behaviour?
| If I have..
|
| data AVL e = E
|
Simon Peyton-Jones wrote:
| strict fields have no effect on deconstructing data types.
That's GHC's behaviour too. I think it's the right one too! (It's
certainly easy to explain.)
This reminds me of something I discovered about using strict fields in
AVL trees (with ghc). Using strict fie
| FinCons 3 q
| desugars to
|
| q `seq` FinCons 3 q wherever it appears,
|
| strict fields have no effect on deconstructing data types.
That's GHC's behaviour too. I think it's the right one too! (It's certainly
easy to explain.)
Simon
___
Haskell-p
[EMAIL PROTECTED] writes:
> Jón Fairbairn wrote:
> > [EMAIL PROTECTED] writes:
> >
> >> Besides, having
> >>
> >> let q = FinCons 3 q in q
> >>
> >> not being _|_ crucially depends on memoization.
> >
> > Does it?
> PS: Your derivations are fine in the case of a non-strict FinCons. But
> the
Given the translation of strict constructors I can't anything but _|_
as the answer.
On Mar 16, 2007, at 15:50 , Ian Lynagh wrote:
Hi all,
A while ago there was a discussion on haskell-cafe about the semantics
of strict bits in datatypes that never reached a conclusion; I've
checked with Ma
Ross Paterson wrote:
> On Fri, Mar 16, 2007 at 05:40:17PM +0100, apfelmus wrote:
>> the translation loops
>> as we could (should?) apply
>>
>> FinCons
>> => \x y -> FinCons x $! y
>> => \x y -> (\x' y' -> FinCons x' $! y') x $! y
>> => ...
>>
>> ad infinitum.
>
> Yes, perhaps that ought to
Jón Fairbairn wrote:
> [EMAIL PROTECTED] writes:
>
>> Besides, having
>>
>> let q = FinCons 3 q in q
>>
>> not being _|_ crucially depends on memoization.
>
> Does it?
Sorry for having introduced an extra paragraph, I meant that q =/= _|_
under the new WHNF-rule would depend on memoization. A
On Fri, Mar 16, 2007 at 05:00:15PM +, Jón Fairbairn wrote:
> Does it? Mentally I translate that as
>
>let q = Y (\q -> FinCons 3 q) in q
>
but it would actually translate to
>let q = Y (\q -> q `seq` FinCons 3 q) in q
for strict fields, whenever a constructor appears, it is transl
Hello,
I also think that the first version is the correct one (i.e., the
result is _|_).
-Iavor
On 3/16/07, Ross Paterson <[EMAIL PROTECTED]> wrote:
On Fri, Mar 16, 2007 at 05:40:17PM +0100, [EMAIL PROTECTED] wrote:
> The translation
>
> > q = FinCons 3 q
> > === (by Haskell 98 report 4.2.1/
On Fri, Mar 16, 2007 at 05:40:17PM +0100, [EMAIL PROTECTED] wrote:
> The translation
>
> > q = FinCons 3 q
> > === (by Haskell 98 report 4.2.1/Strictness Flags/Translation
> > q = (FinCons $ 3) $! q
>
> is rather subtle: the first FinCons is a strict constructor whereas the
> second is "t
[EMAIL PROTECTED] writes:
> Besides, having
>
> let q = FinCons 3 q in q
>
> not being _|_ crucially depends on memoization.
Does it? Mentally I translate that as
let q = Y (\q -> FinCons 3 q) in q
=>
Y (\q-> FinCons 3 q)
=>
(\q -> FinCons 3 q) (Y (\q-> FinCons 3 q))
=>
FinCon
Ian Lynagh wrote:
> Here I will just quote what Malcolm said in his original message:
>
> The definition of seq is
> seq _|_ b = _|_
> seq a b = b, if a/= _|_
>
> In the circular expression
> let q = FinCons 3 q in q
> it is clear that the second component of
23 matches
Mail list logo
