From: Fergus Henderson <[EMAIL PROTECTED]>
Subject: Re: 'any' and 'all' compared with the rest of the Report
Date: Sun, 28 Jan 2001 01:24:58 +1100
> On 26-Jan-2001, Marko Schuetz <[EMAIL PROTECTED]> wrote:
> > I don't think we have absolute freedom.
On 26-Jan-2001, Marko Schuetz <[EMAIL PROTECTED]> wrote:
> I don't think we have absolute freedom. Assuming we want
>
> \forall s : bottom \le s
>
> including s = error, then we should also have error \not\le
> bottom.
You lost me here. Why should we have error \not\le bottom?
Why not just er
From: Jan-Willem Maessen <[EMAIL PROTECTED]>
Subject: Re: 'any' and 'all' compared with the rest of the Report
Date: Fri, 26 Jan 2001 12:26:17 -0500
> Marko Schuetz <[EMAIL PROTECTED]> starts an explanation of bottom
> vs. error with an assumption which I th
Marko Schuetz <[EMAIL PROTECTED]> starts an explanation of bottom
vs. error with an assumption which I think is dangerous:
> Assuming we want
>
> \forall s : bottom \le s
>
> including s = error, then we should also have error \not\le
> bottom.
He uses this, and an argument based on currying,
From: Jan-Willem Maessen <[EMAIL PROTECTED]>
Subject: Re: 'any' and 'all' compared with the rest of the Report
Date: Thu, 25 Jan 2001 11:09:07 -0500
> Bjorn Lisper <[EMAIL PROTECTED]> replies to my reply:
> > >My current work includes [among other
Bjorn Lisper <[EMAIL PROTECTED]> replies to my reply:
> >My current work includes [among other things] ways to eliminate this
> >problem---that is, we may do a computation eagerly and defer or
> >discard any errors.
>
> What you basically have to do is to treat purely data-dependent errors (like
>There is also the problem of error behavior; if we unfold an "or"
>eagerly to exploit its data parallelism we may uncover errors, even if
>it's finite:
>> or [True, error "This should never be evaluated"]
>True
>My current work includes [among other things] ways to eliminate this
>problem---tha
(Note, I've kept this on Haskell-cafe)
Bjorn Lisper wrote (several messages back):
> ... What I in turn would like to add is that specifications like
>
> any p = or . map p
>
> are on a higher level of abstraction
...
> The first specification is, for instance, directly data parallel
> which
I wrote:
> [...]
>ghc -O generates basically the following code (use -ddump-simpl to
>see this):
>
> any :: (a -> Bool) -> [a] -> Bool
> any p xs = let go ys = case ys of
Ooops, cut'n'paste error: Insert
[] -> False
here. :-}
>
Hello!
On Tue, Jan 23, 2001 at 11:10:53PM +0100, Sven Panne wrote:
> [...]
>
>Given
>
> or = foldr (||) False
> any p = or . map p
>ghc -O generates basically the following code (use -ddump-simpl to
> see this):
> any :: (a -> Bool) -> [a] -> Bool
> any p xs =
Iavor Diatchki wrote:
> [...] but in practise programs run slower.
If "practise" = "simple interpreter", yes. But...
> this is where i would expect a good compiler to do some optimisation,
> i.e to remove the need for the intermediate list.
Given
or = foldr (||) False
any p = o
hello
i myself am not an experienced Haskell user, so please correct me
if i am wrong. it is difficult in general to reason about the
performance of lazy programs, so i don't think one can assume
much. in particular i dont think 'any' and 'all' will
perform in linear space. here is why i thin
12 matches
Mail list logo
