On Fri, 7 Dec 2007, Andrew Coppin wrote:
Ian Lynagh wrote:
On Tue, Dec 04, 2007 at 03:07:01PM -0800, Ryan Ingram wrote:
Is there a reason why strictness is defined as
f _|_ = _|_
instead of, for example,
forall x :: Exception. f (throw x) = throw x
Errors and exceptions are
Ian Lynagh wrote:
On Tue, Dec 04, 2007 at 03:07:01PM -0800, Ryan Ingram wrote:
Is there a reason why strictness is defined as
f _|_ = _|_
instead of, for example,
forall x :: Exception. f (throw x) = throw x
There's discussion along these lines in
Use of isNothing and fromJust and a cascade of ifs is generally a poor
sign, much better to use case:
findAllPath pred (Branch lf r rt)
| pred r =
case (findAllPath pred lf,findAllPath pred rt) of
(Nothing,Nothing) - Nothing
(Nothing,Just
On Dec 6, 2007 9:30 AM, Alistair Bayley [EMAIL PROTECTED] wrote:
Use of isNothing and fromJust and a cascade of ifs is generally a poor
sign, much better to use case:
findAllPath pred (Branch lf r rt)
| pred r =
case (findAllPath pred lf,findAllPath pred rt) of
Alistair Bayley wrote:
Nested Maybe cases put me in mind of the Maybe monad. Although in this
case it''s not trivial; we also need to involve the Maybe [a] instance
of Data.Monoid too (for the mappend function). I do wonder if I'm
abusing the monadic instances of Maybe though; is this really any
Jules Bean wrote:
I think the 'right' answer for this case is to drop the maybes and just
use lists, which is what the OP himself realised.
Yes, part of the fun of programming is when
you realize that you have been re-implementing the
right data type inside of a wrong one.
Alistair Bayley
On 12/6/07, Luke Palmer [EMAIL PROTECTED] wrote:
I have actually seen this pattern a lot recently. Recently I have
started using a function:
mergeMaybes :: (a - a - a) - Maybe a - Maybe a - Maybe a
mergeMaybes f Nothing y = y
mergeMaybes f x Nothing = x
mergeMaybes f (Just x) (Just y) =
On 12/6/07, Ryan Ingram [EMAIL PROTECTED] wrote:
On 12/6/07, Luke Palmer [EMAIL PROTECTED] wrote:
I have actually seen this pattern a lot recently. Recently I have
started using a function:
mergeMaybes :: (a - a - a) - Maybe a - Maybe a - Maybe a
mergeMaybes f Nothing y = y
OK, last post. I clearly need more sleep.
On 12/6/07, Ryan Ingram [EMAIL PROTECTED] wrote:
mergeMaybes f x y = liftM2 f `mplus` x `mplus` y
mergeMaybes f x y = liftM2 f x y `mplus` x `mplus` y
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Tue, Dec 04, 2007 at 03:07:01PM -0800, Ryan Ingram wrote:
Is there a reason why strictness is defined as
f _|_ = _|_
instead of, for example,
forall x :: Exception. f (throw x) = throw x
There's discussion along these lines in
http://hackage.haskell.org/trac/ghc/ticket/1171
Thanks
Hasn't Ryan raised an interesting point, though?
Bottom is used to denote non-termination and run-time errors. Are they
the same thing? To me, they're not. A non-terminating program has
different behaviour from a failing program.
When it comes to strictness, the concept is defined in a
Roberto Zunino wrote:
Neil Mitchell wrote:
is there any automated
way to know when a function is strict in its arguments?
Yes, strictness analysis is a very well studied subject -
...and is undecidable, in general. ;-)
*thinks*
Conjecture #1: All nontrivial properties of
Tillmann Rendel wrote:
Andrew Coppin wrote:
*thinks*
Conjecture #1: All nontrivial properties of a computer program are
undecidable in general.
That is the well-known Rice's theorem.
Wait - Rice's *theorem*? So Rice *proved* this?
OMG, I was *right* about something! :-D
Conjecture #2:
On Dec 5, 2007 1:51 PM, Luke Palmer [EMAIL PROTECTED] wrote:
On Dec 4, 2007 9:41 PM, Paulo J. Matos [EMAIL PROTECTED] wrote:
Hello all,
As you might have possibly read in some previous blog posts:
http://users.ecs.soton.ac.uk/pocm06r/fpsig/?p=10
On Dec 5, 2007 11:56 AM, Andrew Coppin [EMAIL PROTECTED] wrote:
I was merely noting that questions of the form is X decidable? are
usually undecidable. (It's as if God himself wants to tease us...)
I take issue with your definition of usually then.
Whenever X is decidable is undecidable, 'X is
On Wed, 2007-12-05 at 10:01 +0100, Pablo Nogueira wrote:
Hasn't Ryan raised an interesting point, though?
Bottom is used to denote non-termination and run-time errors. Are they
the same thing?
Up to observational equality, yes.
To me, they're not. A non-terminating program has
different
On Dec 5, 2007 12:30 PM, Andrew Coppin [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
On Dec 5, 2007 11:56 AM, Andrew Coppin [EMAIL PROTECTED] wrote:
I was merely noting that questions of the form is X decidable? are
usually undecidable. (It's as if God himself wants to tease us...)
I
Luke Palmer wrote:
On Dec 5, 2007 11:56 AM, Andrew Coppin [EMAIL PROTECTED] wrote:
I was merely noting that questions of the form is X decidable? are
usually undecidable. (It's as if God himself wants to tease us...)
I take issue with your definition of usually then.
Whenever X is
On Dec 5, 2007 11:44 AM, Jules Bean [EMAIL PROTECTED] wrote:
the general pattern is : replace isNothing with a case match on Nothing,
replace fromJust with a case match on Just, don't be afraid to case two
expressions at once.
That's a nice little insight. I'll remember that.
Paulo J. Matos wrote:
Hello all,
Hi.
findAllPath :: (a - Bool) - (BTree a) - Maybe [[a]]
findAllPath pred (Leaf l) | pred l = Just [[l]]
| otherwise = Nothing
findAllPath pred (Branch lf r rt) | pred r = let lfpaths = findAllPath pred lf
On Dec 4, 2007 10:00 PM, Neil Mitchell [EMAIL PROTECTED] wrote:
Hi
findAllPath :: (a - Bool) - (BTree a) - [[a]]
findAllPath pred = g where
g (Leaf l) | pred l = [[l]]
g (Branch lf r rt) | pred r = map (r:) $ (findAllPath pred
lf) ++ (findAllPath pred rt)
Andrew Coppin wrote:
*thinks*
Conjecture #1: All nontrivial properties of a computer program are
undecidable in general.
That is the well-known Rice's theorem.
(A very handy one in exams about theoretical computer science, since you
can smash so many questions with follows from Rice).
On Dec 5, 2007 10:44 AM, Jules Bean [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote:
Hello all,
Hi.
findAllPath :: (a - Bool) - (BTree a) - Maybe [[a]]
findAllPath pred (Leaf l) | pred l = Just [[l]]
| otherwise = Nothing
findAllPath pred (Branch lf r rt) |
See
http://doi.acm.org/10.1145/301631.301637
and
http://dx.doi.org/10.1016/S1571-0661(05)80288-9
Pablo Nogueira wrote:
Hasn't Ryan raised an interesting point, though?
Bottom is used to denote non-termination and run-time errors. Are they
the same thing? To me, they're not. A
Hello all,
As you might have possibly read in some previous blog posts:
http://users.ecs.soton.ac.uk/pocm06r/fpsig/?p=10
http://users.ecs.soton.ac.uk/pocm06r/fpsig/?p=11
we (the FPSIG group) defined:
data BTree a = Leaf a
| Branch (BTree a) a (BTree a)
and a function that
Hi
findAllPath :: (a - Bool) - (BTree a) - [[a]]
findAllPath pred = g where
g (Leaf l) | pred l = [[l]]
g (Branch lf r rt) | pred r = map (r:) $ (findAllPath pred
lf) ++ (findAllPath pred rt)
g _ = []
without even using maybe. However, 2 questions
Neil Mitchell wrote:
is there any automated
way to know when a function is strict in its arguments?
Yes, strictness analysis is a very well studied subject -
...and is undecidable, in general. ;-)
Zun.
___
Haskell-Cafe mailing list
On Tue, Dec 04, 2007 at 09:41:36PM +, Paulo J. Matos wrote:
Hello all,
As you might have possibly read in some previous blog posts:
http://users.ecs.soton.ac.uk/pocm06r/fpsig/?p=10
http://users.ecs.soton.ac.uk/pocm06r/fpsig/?p=11
we (the FPSIG group) defined:
data BTree a = Leaf a
Is there a reason why strictness is defined as
f _|_ = _|_
instead of, for example,
forall x :: Exception. f (throw x) = throw x
where an exception thrown from pure code is observable in IO.
In the second case we need to prove that the argument is evaluated at some
point, which is also
On Tue, Dec 04, 2007 at 03:07:01PM -0800, Ryan Ingram wrote:
Is there a reason why strictness is defined as
f _|_ = _|_
instead of, for example,
forall x :: Exception. f (throw x) = throw x
where an exception thrown from pure code is observable in IO.
In the second case we need to
On 12/4/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Is there a reason why 2 + 2 is defined as 4 instead of, for example,
5?
Wow. That wasn't really necessary. 4 has a clear meaning (the number after
the number after the number after the number after zero) which is equivalent
to 2 + 2. I'm
I don't even understand what your notation means.
But apart from that, there are good reasons to define strictness
denotationally instead of operationally. Remember that _|_ is not only
exceptions, but also non-termination.
For instance, the following function is strict without using its
On Tue, Dec 04, 2007 at 03:35:28PM -0800, Ryan Ingram wrote:
On 12/4/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Is there a reason why 2 + 2 is defined as 4 instead of, for example,
5?
Wow. That wasn't really necessary. 4 has a clear meaning (the number after
the number after the
On Tue, Dec 04, 2007 at 03:35:28PM -0800, Ryan Ingram wrote:
On 12/4/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Well, one usually says something like f is strict in its 2nd argument
which on casual reading tends to make me think that it has something to do
with the argument. By the actual
On 12/4/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
When you see an expression of the form:
f a
you generally want to evaluate a before applying; but if a is _|_, this
will only give the correct result if f a = _|_. Merely 'guaranteed to
evaluate' misses out on some common cases, for
On Tue, Dec 04, 2007 at 07:43:36PM -0800, Ryan Ingram wrote:
On 12/4/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
When you see an expression of the form:
f a
you generally want to evaluate a before applying; but if a is _|_, this
will only give the correct result if f a = _|_. Merely
36 matches
Mail list logo
