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
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
http://hackage.h
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
Tha
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
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
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
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 wro
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
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)
> 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,Ju
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
> diffe
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
> > http://users.ecs.soton.ac
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
> http://users.ecs.soton.ac.uk/pocm06r/fpsig/?p=11
>
> we (the FPSIG group) defined:
> data BTree a = Le
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 (
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) ++ (findAllPa
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 tea
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
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 undecidab
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: C
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").
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 non-terminatin
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
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
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 particular
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
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, f
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 act
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 af
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 argumen
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.
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 nee
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 equiva
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 = Le
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
Haskell-
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 ques
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 retu
37 matches
Mail list logo