From borgauf at gmail.com Sun Apr 4 04:26:09 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Sat, 3 Apr 2021 23:26:09 -0500
Subject: [Haskell-beginners] Type class instance with Num
Message-ID:
I'm following LYHFGG and I have this
class YesNo a where
yesno :: a -> Bool
instance YesNo Int where
yesno 0 = False
yesno _ = True
but then I have to specify Int here
> yesno (5 :: Int)
True
Just with 5 gives this error
Ambiguous type variable ‘a0’ arising from the literal ‘5’
prevents the constraint ‘(Num a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
I tried this
instance YesNo (Num a) where
yesno 0 = False
yesno _ = True
but got cryptic errors. What can I do to make yesno take any of Num's
numbers?
LB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bob at redivi.com Sun Apr 4 04:39:23 2021
From: bob at redivi.com (Bob Ippolito)
Date: Sat, 3 Apr 2021 21:39:23 -0700
Subject: [Haskell-beginners] Type class instance with Num
In-Reply-To:
References:
Message-ID:
You need something like this:
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
class YesNo a where
yesno :: a -> Bool
instance (Num a, Eq a) => YesNo a where
yesno = (/= 0)
The reason this doesn't work without turning on some "scary" flags is that
you can easily write code that is ambiguous since typeclasses are open.
Open means that some other file can define a data type that has an instance
of Num and an instance for YesNo and then there's no obvious choice which
instance should be used.
If you want a bit more detail, here's a relevant StackOverflow question:
https://stackoverflow.com/questions/8877541/how-to-write-an-instance-for-all-types-in-another-type-class
On Sat, Apr 3, 2021 at 9:26 PM Galaxy Being wrote:
> I'm following LYHFGG and I have this
>
> class YesNo a where
> yesno :: a -> Bool
>
> instance YesNo Int where
> yesno 0 = False
> yesno _ = True
>
> but then I have to specify Int here
>
> > yesno (5 :: Int)
> True
>
> Just with 5 gives this error
>
> Ambiguous type variable ‘a0’ arising from the literal ‘5’
> prevents the constraint ‘(Num a0)’ from being solved.
> Probable fix: use a type annotation to specify what ‘a0’ should be.
>
> I tried this
>
> instance YesNo (Num a) where
> yesno 0 = False
> yesno _ = True
>
> but got cryptic errors. What can I do to make yesno take any of Num's
> numbers?
>
> LB
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From borgauf at gmail.com Wed Apr 7 16:47:03 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Wed, 7 Apr 2021 11:47:03 -0500
Subject: [Haskell-beginners] Is map (map f) just map f?
Message-ID:
I'm in Bird's *Thinking Functionally with Haskell* and the topic is natural
transformations. He says
filter p . map f = map f . filter (p . f)
and he has a proof, but one step of the proof he goes from
filter p . map f = concat . map (map f) . map (test (p . f))
to
filter p . map f = map f . concat . map (test (p . f))
which means
concat . map (map f) => map f . concat
which means
map (map f) = map f
... or I'm getting this step wrong somehow. To begin with, I'm having a
hard time comprehending map(map f), Any ideas on how this is possible?
LB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From tanuki at gmail.com Wed Apr 7 17:06:47 2021
From: tanuki at gmail.com (Akhra Gannon)
Date: Wed, 7 Apr 2021 10:06:47 -0700
Subject: [Haskell-beginners] Is map (map f) just map f?
In-Reply-To:
References:
Message-ID:
Check the types!
map :: (a -> b) -> [a] -> [b]
Therefore:
map f :: [a] -> [b]
map . map :: (a -> b) -> [[a]] -> [[b]]
map (map f) :: [[a]] -> [[b]]
And,
concat :: [[a]] -> [a]
Put it all together and you should see how that rewrite works!
On Wed, Apr 7, 2021, 9:47 AM Galaxy Being wrote:
> I'm in Bird's *Thinking Functionally with Haskell* and the topic is
> natural transformations. He says
>
> filter p . map f = map f . filter (p . f)
>
> and he has a proof, but one step of the proof he goes from
>
> filter p . map f = concat . map (map f) . map (test (p . f))
>
> to
>
> filter p . map f = map f . concat . map (test (p . f))
>
> which means
>
> concat . map (map f) => map f . concat
>
> which means
>
> map (map f) = map f
>
> ... or I'm getting this step wrong somehow. To begin with, I'm having a
> hard time comprehending map(map f), Any ideas on how this is possible?
>
> LB
>
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From borgauf at gmail.com Thu Apr 8 05:03:32 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Thu, 8 Apr 2021 00:03:32 -0500
Subject: [Haskell-beginners] Is map (map f) just map f?
In-Reply-To:
References:
Message-ID:
So basically I can see that the type definitions would seem to deliver the
same thing. I test it
> (concat . (map (map (*5)))) [[1],[2],[3]]
[5,10,15]
> (map (*5) . concat) [[1],[2],[3]]
[5,10,15]
and can also conclude they give the same answer. So is this an example of
referential transparency, i.e., the ability to substitute code and be
assured both forms/expressions deliver the same answer?
On Wed, Apr 7, 2021 at 12:07 PM Akhra Gannon wrote:
> Check the types!
>
> map :: (a -> b) -> [a] -> [b]
>
> Therefore:
>
> map f :: [a] -> [b]
>
> map . map :: (a -> b) -> [[a]] -> [[b]]
>
> map (map f) :: [[a]] -> [[b]]
>
> And,
>
> concat :: [[a]] -> [a]
>
> Put it all together and you should see how that rewrite works!
>
>
> On Wed, Apr 7, 2021, 9:47 AM Galaxy Being wrote:
>
>> I'm in Bird's *Thinking Functionally with Haskell* and the topic is
>> natural transformations. He says
>>
>> filter p . map f = map f . filter (p . f)
>>
>> and he has a proof, but one step of the proof he goes from
>>
>> filter p . map f = concat . map (map f) . map (test (p . f))
>>
>> to
>>
>> filter p . map f = map f . concat . map (test (p . f))
>>
>> which means
>>
>> concat . map (map f) => map f . concat
>>
>> which means
>>
>> map (map f) = map f
>>
>> ... or I'm getting this step wrong somehow. To begin with, I'm having a
>> hard time comprehending map(map f), Any ideas on how this is possible?
>>
>> LB
>>
>>
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From utprimum at gmail.com Thu Apr 8 05:55:29 2021
From: utprimum at gmail.com (Ut Primum)
Date: Thu, 8 Apr 2021 07:55:29 +0200
Subject: [Haskell-beginners] Is map (map f) just map f?
In-Reply-To:
References:
Message-ID:
Yes, thanks to referential transparency you can substitute
concat . map (map f)
with
map f . concat
in an expression and be sure you'll always get the same result
Il gio 8 apr 2021, 07:04 Galaxy Being ha scritto:
> So basically I can see that the type definitions would seem to deliver the
> same thing. I test it
>
> > (concat . (map (map (*5)))) [[1],[2],[3]]
> [5,10,15]
> > (map (*5) . concat) [[1],[2],[3]]
> [5,10,15]
>
> and can also conclude they give the same answer. So is this an example of
> referential transparency, i.e., the ability to substitute code and be
> assured both forms/expressions deliver the same answer?
>
>
> On Wed, Apr 7, 2021 at 12:07 PM Akhra Gannon wrote:
>
>> Check the types!
>>
>> map :: (a -> b) -> [a] -> [b]
>>
>> Therefore:
>>
>> map f :: [a] -> [b]
>>
>> map . map :: (a -> b) -> [[a]] -> [[b]]
>>
>> map (map f) :: [[a]] -> [[b]]
>>
>> And,
>>
>> concat :: [[a]] -> [a]
>>
>> Put it all together and you should see how that rewrite works!
>>
>>
>> On Wed, Apr 7, 2021, 9:47 AM Galaxy Being wrote:
>>
>>> I'm in Bird's *Thinking Functionally with Haskell* and the topic is
>>> natural transformations. He says
>>>
>>> filter p . map f = map f . filter (p . f)
>>>
>>> and he has a proof, but one step of the proof he goes from
>>>
>>> filter p . map f = concat . map (map f) . map (test (p . f))
>>>
>>> to
>>>
>>> filter p . map f = map f . concat . map (test (p . f))
>>>
>>> which means
>>>
>>> concat . map (map f) => map f . concat
>>>
>>> which means
>>>
>>> map (map f) = map f
>>>
>>> ... or I'm getting this step wrong somehow. To begin with, I'm having a
>>> hard time comprehending map(map f), Any ideas on how this is possible?
>>>
>>> LB
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> Beginners at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From borgauf at gmail.com Sat Apr 10 03:59:07 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Fri, 9 Apr 2021 22:59:07 -0500
Subject: [Haskell-beginners] Strange use of undefined (et al.) in list
comprehension
Message-ID:
I'm looking at Bird's *Thinking Functionally with Haskell *and he gives two
list comprehensions, asking under what conditions they deliver the same
results
[e | x <- xs, p x, y <- ys]
[e | x <- xs, y <- ys, p x]
First, I'm confused about what is the input and what is the predicate. The y
<- ys in the first LC seems to be in a predicate position, and in the
second it's a second input after x <- xs with p x in the predicate position
. . . confusing me.
The answer examples Bird gives are beyond me:
They deliver the same result only if ys is a finite list:
> [1 | x <- [1,3], even x, y <- undefined]
[]
> [1 | x <- [1,3], y <- undefined, even x]
Exception: Prelude.undefined
> [1 | x <- [1,3], y <- [1..], even x]
{Interruped}
I'm not sure what's being said here, or what points are being made.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mlow at ualberta.ca Sat Apr 10 05:17:20 2021
From: mlow at ualberta.ca (Matthew Low)
Date: Fri, 9 Apr 2021 23:17:20 -0600
Subject: [Haskell-beginners] Strange use of undefined (et al.) in list
comprehension
In-Reply-To:
References:
Message-ID:
>
> First, I'm confused about what is the input and what is the predicate
The haskell 2010 report (
https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-420003.11)
says that after the | we can have any type of qualifier, which can be 1. a
generator (I think you called this the input) 2. a local binding (we don't
care about these in your example, there are none) or 3. boolean guards,
which are any expression that evaluate to Bool (your predicates). So there
isn't really a `predicate postion`, predicates can occur anywhere after the
`|`.
As for the behaviour, its easiest to see what happens with a regular list
of inputs:
λ> [(x,y) | x <- [1,2], y <- ['A', 'B']]
[(1,'A'),(1,'B'),(2,'A'),(2,'B')]
so `y` acts as an inner loop and `x` the outer.
> [1 | x <- [1,3], even x, y <- undefined]
>
Here we start the outer loop over x, and only if x is even, then we loop
over y. But x is never even, so we never loop over y, so we never evaluate
`undefined` (Haskell is lazy). So essentially filter out all elements of x
and are left with []
> [1 | x <- [1,3], y <- undefined, even x]
>
Now we've moved the guard into the inner loop, after we try to evaluate y.
So we blow up trying to do that and GHCi catches the exception
[1 | x <- [1,3], y <- [1..], even x]
>
Similar to the above, the (even x) isn't guarding the evaluation of y, so
we're stuck generating all the infinite pairings of x = 1, y = 1...
On Fri, Apr 9, 2021 at 9:59 PM Galaxy Being wrote:
> I'm looking at Bird's *Thinking Functionally with Haskell *and he gives
> two list comprehensions, asking under what conditions they deliver the same
> results
>
> [e | x <- xs, p x, y <- ys]
> [e | x <- xs, y <- ys, p x]
>
> First, I'm confused about what is the input and what is the predicate. The y
> <- ys in the first LC seems to be in a predicate position, and in the
> second it's a second input after x <- xs with p x in the predicate
> position . . . confusing me.
>
> The answer examples Bird gives are beyond me:
>
> They deliver the same result only if ys is a finite list:
>
> > [1 | x <- [1,3], even x, y <- undefined]
> []
> > [1 | x <- [1,3], y <- undefined, even x]
> Exception: Prelude.undefined
> > [1 | x <- [1,3], y <- [1..], even x]
> {Interruped}
>
> I'm not sure what's being said here, or what points are being made.
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From borgauf at gmail.com Sat Apr 10 15:49:07 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Sat, 10 Apr 2021 10:49:07 -0500
Subject: [Haskell-beginners] Strange use of undefined (et al.) in list
comprehension
In-Reply-To:
References:
Message-ID:
So the Bool predicates and the generators are not purposefully grouped
separately -- it just appears that way from the simplistic beginner book
examples. But the evaluation is, indeed, left-to-right in that the first
example above has even x evaluated directly after x <- [1,3], whereas in
the second example the y <- undefined is evaluated directly after x <-
[1,3], then
the even x, correct? Again, the beginner book examples give the impression
that any and all predicates are A) always pushed to the far right, closest
to the right bracket, and B) follow no order of application such as being
bound to the form closest to the left. So yes, it's visually obvious that
there is an outer-inner looping happening when you see the output of two
generators doing combinations, but, again, the beginner treatments I've
seen make no explicit mention of order in an LC. This is all news to me,
but thanks! That's what these forums are for!
On Sat, Apr 10, 2021 at 12:18 AM Matthew Low wrote:
> First, I'm confused about what is the input and what is the predicate
>
> The haskell 2010 report (
> https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-420003.11)
> says that after the | we can have any type of qualifier, which can be 1. a
> generator (I think you called this the input) 2. a local binding (we don't
> care about these in your example, there are none) or 3. boolean guards,
> which are any expression that evaluate to Bool (your predicates). So there
> isn't really a `predicate postion`, predicates can occur anywhere after the
> `|`.
>
> As for the behaviour, its easiest to see what happens with a regular list
> of inputs:
>
> λ> [(x,y) | x <- [1,2], y <- ['A', 'B']]
> [(1,'A'),(1,'B'),(2,'A'),(2,'B')]
>
> so `y` acts as an inner loop and `x` the outer.
>
> > [1 | x <- [1,3], even x, y <- undefined]
>>
> Here we start the outer loop over x, and only if x is even, then we loop
> over y. But x is never even, so we never loop over y, so we never evaluate
> `undefined` (Haskell is lazy). So essentially filter out all elements of x
> and are left with []
>
> > [1 | x <- [1,3], y <- undefined, even x]
>>
> Now we've moved the guard into the inner loop, after we try to evaluate y.
> So we blow up trying to do that and GHCi catches the exception
>
> [1 | x <- [1,3], y <- [1..], even x]
>>
> Similar to the above, the (even x) isn't guarding the evaluation of y, so
> we're stuck generating all the infinite pairings of x = 1, y = 1...
>
> On Fri, Apr 9, 2021 at 9:59 PM Galaxy Being wrote:
>
>> I'm looking at Bird's *Thinking Functionally with Haskell *and he gives
>> two list comprehensions, asking under what conditions they deliver the same
>> results
>>
>> [e | x <- xs, p x, y <- ys]
>> [e | x <- xs, y <- ys, p x]
>>
>> First, I'm confused about what is the input and what is the predicate.
>> The y <- ys in the first LC seems to be in a predicate position, and in
>> the second it's a second input after x <- xs with p x in the predicate
>> position . . . confusing me.
>>
>> The answer examples Bird gives are beyond me:
>>
>> They deliver the same result only if ys is a finite list:
>>
>> > [1 | x <- [1,3], even x, y <- undefined]
>> []
>> > [1 | x <- [1,3], y <- undefined, even x]
>> Exception: Prelude.undefined
>> > [1 | x <- [1,3], y <- [1..], even x]
>> {Interruped}
>>
>> I'm not sure what's being said here, or what points are being made.
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mlow at ualberta.ca Sat Apr 10 19:19:20 2021
From: mlow at ualberta.ca (Matthew Low)
Date: Sat, 10 Apr 2021 13:19:20 -0600
Subject: [Haskell-beginners] Strange use of undefined (et al.) in list
comprehension
In-Reply-To:
References:
Message-ID:
Glad it helped! You might also be interested in the forums at
https://discourse.haskell.org/ - there is a dedicated learning topic, which
has a question at a bunch of different levels including very beginning.
On Sat, Apr 10, 2021 at 9:49 AM Galaxy Being wrote:
> So the Bool predicates and the generators are not purposefully grouped
> separately -- it just appears that way from the simplistic beginner book
> examples. But the evaluation is, indeed, left-to-right in that the first
> example above has even x evaluated directly after x <- [1,3], whereas in
> the second example the y <- undefined is evaluated directly after x <-
> [1,3], then the even x, correct? Again, the beginner book examples give
> the impression that any and all predicates are A) always pushed to the far
> right, closest to the right bracket, and B) follow no order of application
> such as being bound to the form closest to the left. So yes, it's visually
> obvious that there is an outer-inner looping happening when you see the
> output of two generators doing combinations, but, again, the beginner
> treatments I've seen make no explicit mention of order in an LC. This is
> all news to me, but thanks! That's what these forums are for!
>
>
>
> On Sat, Apr 10, 2021 at 12:18 AM Matthew Low wrote:
>
>> First, I'm confused about what is the input and what is the predicate
>>
>> The haskell 2010 report (
>> https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-420003.11)
>> says that after the | we can have any type of qualifier, which can be 1. a
>> generator (I think you called this the input) 2. a local binding (we don't
>> care about these in your example, there are none) or 3. boolean guards,
>> which are any expression that evaluate to Bool (your predicates). So there
>> isn't really a `predicate postion`, predicates can occur anywhere after the
>> `|`.
>>
>> As for the behaviour, its easiest to see what happens with a regular list
>> of inputs:
>>
>> λ> [(x,y) | x <- [1,2], y <- ['A', 'B']]
>> [(1,'A'),(1,'B'),(2,'A'),(2,'B')]
>>
>> so `y` acts as an inner loop and `x` the outer.
>>
>> > [1 | x <- [1,3], even x, y <- undefined]
>>>
>> Here we start the outer loop over x, and only if x is even, then we loop
>> over y. But x is never even, so we never loop over y, so we never evaluate
>> `undefined` (Haskell is lazy). So essentially filter out all elements of x
>> and are left with []
>>
>> > [1 | x <- [1,3], y <- undefined, even x]
>>>
>> Now we've moved the guard into the inner loop, after we try to evaluate
>> y. So we blow up trying to do that and GHCi catches the exception
>>
>> [1 | x <- [1,3], y <- [1..], even x]
>>>
>> Similar to the above, the (even x) isn't guarding the evaluation of y, so
>> we're stuck generating all the infinite pairings of x = 1, y = 1...
>>
>> On Fri, Apr 9, 2021 at 9:59 PM Galaxy Being wrote:
>>
>>> I'm looking at Bird's *Thinking Functionally with Haskell *and he gives
>>> two list comprehensions, asking under what conditions they deliver the same
>>> results
>>>
>>> [e | x <- xs, p x, y <- ys]
>>> [e | x <- xs, y <- ys, p x]
>>>
>>> First, I'm confused about what is the input and what is the predicate.
>>> The y <- ys in the first LC seems to be in a predicate position, and in
>>> the second it's a second input after x <- xs with p x in the predicate
>>> position . . . confusing me.
>>>
>>> The answer examples Bird gives are beyond me:
>>>
>>> They deliver the same result only if ys is a finite list:
>>>
>>> > [1 | x <- [1,3], even x, y <- undefined]
>>> []
>>> > [1 | x <- [1,3], y <- undefined, even x]
>>> Exception: Prelude.undefined
>>> > [1 | x <- [1,3], y <- [1..], even x]
>>> {Interruped}
>>>
>>> I'm not sure what's being said here, or what points are being made.
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> Beginners at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mlow at ualberta.ca Sat Apr 10 19:26:08 2021
From: mlow at ualberta.ca (Matthew Low)
Date: Sat, 10 Apr 2021 13:26:08 -0600
Subject: [Haskell-beginners] Strange use of undefined (et al.) in list
comprehension
In-Reply-To:
References:
Message-ID:
I missed this question:
> But the evaluation is, indeed, left-to-right ... correct?
Correct (though note that in the second example, evaluating y <- undefined
will throw and exception so (even x) will not be evaluated)
On Sat, Apr 10, 2021 at 1:19 PM Matthew Low wrote:
> Glad it helped! You might also be interested in the forums at
> https://discourse.haskell.org/ - there is a dedicated learning topic,
> which has a question at a bunch of different levels including very
> beginning.
>
> On Sat, Apr 10, 2021 at 9:49 AM Galaxy Being wrote:
>
>> So the Bool predicates and the generators are not purposefully grouped
>> separately -- it just appears that way from the simplistic beginner book
>> examples. But the evaluation is, indeed, left-to-right in that the first
>> example above has even x evaluated directly after x <- [1,3], whereas in
>> the second example the y <- undefined is evaluated directly after x <-
>> [1,3], then the even x, correct? Again, the beginner book examples give
>> the impression that any and all predicates are A) always pushed to the far
>> right, closest to the right bracket, and B) follow no order of application
>> such as being bound to the form closest to the left. So yes, it's visually
>> obvious that there is an outer-inner looping happening when you see the
>> output of two generators doing combinations, but, again, the beginner
>> treatments I've seen make no explicit mention of order in an LC. This is
>> all news to me, but thanks! That's what these forums are for!
>>
>>
>>
>> On Sat, Apr 10, 2021 at 12:18 AM Matthew Low wrote:
>>
>>> First, I'm confused about what is the input and what is the predicate
>>>
>>> The haskell 2010 report (
>>> https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-420003.11)
>>> says that after the | we can have any type of qualifier, which can be 1. a
>>> generator (I think you called this the input) 2. a local binding (we don't
>>> care about these in your example, there are none) or 3. boolean guards,
>>> which are any expression that evaluate to Bool (your predicates). So there
>>> isn't really a `predicate postion`, predicates can occur anywhere after the
>>> `|`.
>>>
>>> As for the behaviour, its easiest to see what happens with a regular
>>> list of inputs:
>>>
>>> λ> [(x,y) | x <- [1,2], y <- ['A', 'B']]
>>> [(1,'A'),(1,'B'),(2,'A'),(2,'B')]
>>>
>>> so `y` acts as an inner loop and `x` the outer.
>>>
>>> > [1 | x <- [1,3], even x, y <- undefined]
>>>>
>>> Here we start the outer loop over x, and only if x is even, then we loop
>>> over y. But x is never even, so we never loop over y, so we never evaluate
>>> `undefined` (Haskell is lazy). So essentially filter out all elements of x
>>> and are left with []
>>>
>>> > [1 | x <- [1,3], y <- undefined, even x]
>>>>
>>> Now we've moved the guard into the inner loop, after we try to evaluate
>>> y. So we blow up trying to do that and GHCi catches the exception
>>>
>>> [1 | x <- [1,3], y <- [1..], even x]
>>>>
>>> Similar to the above, the (even x) isn't guarding the evaluation of y,
>>> so we're stuck generating all the infinite pairings of x = 1, y = 1...
>>>
>>> On Fri, Apr 9, 2021 at 9:59 PM Galaxy Being wrote:
>>>
>>>> I'm looking at Bird's *Thinking Functionally with Haskell *and he
>>>> gives two list comprehensions, asking under what conditions they deliver
>>>> the same results
>>>>
>>>> [e | x <- xs, p x, y <- ys]
>>>> [e | x <- xs, y <- ys, p x]
>>>>
>>>> First, I'm confused about what is the input and what is the predicate.
>>>> The y <- ys in the first LC seems to be in a predicate position, and
>>>> in the second it's a second input after x <- xs with p x in the
>>>> predicate position . . . confusing me.
>>>>
>>>> The answer examples Bird gives are beyond me:
>>>>
>>>> They deliver the same result only if ys is a finite list:
>>>>
>>>> > [1 | x <- [1,3], even x, y <- undefined]
>>>> []
>>>> > [1 | x <- [1,3], y <- undefined, even x]
>>>> Exception: Prelude.undefined
>>>> > [1 | x <- [1,3], y <- [1..], even x]
>>>> {Interruped}
>>>>
>>>> I'm not sure what's being said here, or what points are being made.
>>>>
>>>> _______________________________________________
>>>> Beginners mailing list
>>>> Beginners at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> Beginners at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: