To clarify, by hack I meant that it seemed like a workaround specifically
to keep "case" in the OP's code, when it seemed like they were looking for
the functionality of guards.
amindfv / Tom
On Dec 11, 2011 1:39 PM, "Yitzchak Gale" wrote:
> Brandon Allbery wrote:
> >>> > case () of
> >>> > ()
Brandon Allbery wrote:
>>> > case () of
>>> > () | s == reverse s -> putStrLn "palindrome"
>>> > _ -> putStrLn "nope"
Tom Murphy wrote:
>> This is kind of a hack of case, though. I think what the OP was looking
>> for is
>> isPalindrome word
>> | (word == reverse word) = p
On Fri, Dec 9, 2011 at 05:16, Yves Parès wrote:
> I agree with all that, but in *this *special case, I think that
>
I should also note that the OP mentioned using if, but was
surprised/confused by the behavior of case, which is why that's what we've
been focusing on.
--
brandon s allbery
I agree with all that, but in *this *special case, I think that
case something of
True ->
False ->
is less nice and obvious than
if something
then
else
2011/12/9 Brandon Allbery
> On Fri, Dec 9, 2011 at 04:16, Yves Parès wrote:
>
>> Why do you people hate 'if'
On Fri, Dec 9, 2011 at 04:16, Yves Parès wrote:
> Why do you people hate 'if' statements?
>
It's more that the language spec does; if statements, along with a number
of other things, desugar to case which is the fundamental conditional
construct.
(And more personally, I find the indentation beh
Why do you people hate 'if' statements?
2011/12/9 Brandon Allbery
> On Thu, Dec 8, 2011 at 15:52, Tom Murphy wrote:
>
>> On Wed, Dec 7, 2011 at 11:46 PM, Brandon Allbery wrote:
>>
>>> > case () of
>>> > () | s == reverse s -> putStrLn "palindrome"
>>> > _ -> putStrLn "nope
On Thu, Dec 8, 2011 at 15:52, Tom Murphy wrote:
> On Wed, Dec 7, 2011 at 11:46 PM, Brandon Allbery wrote:
>
>> > case () of
>> > () | s == reverse s -> putStrLn "palindrome"
>> > _ -> putStrLn "nope"
>>
>
>
> This is kind of a hack of case, though. I think what the OP was lo
On Wed, Dec 7, 2011 at 11:46 PM, Brandon Allbery wrote:
> On Wed, Dec 7, 2011 at 23:24, Alexej Segeda > wrote:
>
>> case s of
>>(s == reverse s)-> putStrLn (s ++ " is a
>> palindrome")
>>otherwise -> putStrLn (s ++ " is not a
>
Alexej> The interesting thing is, that if I change the "case ... of"
Alexej> statement to an "if ... then ... else" statement, this magically
Alexej> starts to work. Since I no longer am enrolled (I have to take
Alexej> the course next year), I can't ask a teacher, but my curiosity
Alexej> still bu
On Wed, Dec 7, 2011 at 23:24, Alexej Segeda
wrote:
> case s of
>(s == reverse s)-> putStrLn (s ++ " is a
> palindrome")
>otherwise -> putStrLn (s ++ " is not a
> palindrome")
>
case does pattern matching, not Boolean expression
Hi!
A couple of months ago, I wrote an exam in an introductory Haskell course and
failed, all because of an assignment that I was convinced would work, but for
some reason, it didn't. The assignment was to write a function that would take
a line, then determine whether it's a palindrome or not
I wrote:
>> A more basic issue is that fn is in the IO monad,
>> but its use inside the mapM will need it to be in the ST
>> monad.
Daniel Fischer wrote:
> No,
> return (fn particle) :: ST s (IO ())
> , so that's fine.
Ah, true. But I doubt that Andrew really meant to
do the calculation in ST s (
BTW, this is a case where it may be more convenient to use forM:
forM ps $ \pix -> do
particle <- read_grid g pix
return $ fn particle
(untested...)
forM is just another way of saying (flip mapM).
/ Emil
Andrew Coppin skrev:
colour_grid :: (Particle -> IO ()) -> Grid ph -> IO ()
col
Am Sonntag, 24. August 2008 17:21 schrieb Yitzchak Gale:
> Alfonso Acosta wrote:
> > I haven't tried to run the code, but my first bet is that, due to the
> > rank-2 polymorphism of ST, you should use parenthesis instead of $ in
> > the case of runST.
>
> Perhaps if Andrew is using an old compiler.
Alfonso Acosta wrote:
> I haven't tried to run the code, but my first bet is that, due to the
> rank-2 polymorphism of ST, you should use parenthesis instead of $ in
> the case of runST.
Perhaps if Andrew is using an old compiler.
That is no longer a problem in recent versions of GHC.
A more basi
I haven't tried to run the code, but my first bet is that, due to the
rank-2 polymorphism of ST, you should use parenthesis instead of $ in
the case of runST.
On Sun, Aug 24, 2008 at 3:25 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> colour_grid :: (Particle -> IO ()) -> Grid ph -> IO ()
> colour
colour_grid :: (Particle -> IO ()) -> Grid ph -> IO ()
colour_grid fn g = sequence_ $ runST $ do
ps <- grid_coords g
mapM
(\pix -> do
particle <- read_grid g pix
return $ fn particle
)
ps
When I attempt to run this, GHCi just gives me a very cryptic type
checker error. I ca
On 2005 April 25 Monday 02:16, Michael Vanier wrote:
> -- Generate an infinite list of coin flips.
> coinFlips :: IO [Coin]
> coinFlips = sequence cfs
> where cfs = (coinFlip : cfs)
> --
>
> [...] My understanding is th
On 4/25/05, Michael Vanier <[EMAIL PROTECTED]> wrote:
>
> I've been trying to generate an infinite list of random coin flips in GHC
> 6.4, and I've come across some strange behavior:
>
> --
> import System.Random
>
> data Coin =
On Sun, 2005-04-24 at 23:16 -0700, Michael Vanier wrote:
> I've been trying to generate an infinite list of random coin flips in GHC
> 6.4, and I've come across some strange behavior:
>
> --
> import System.Random
>
> data Coin =
Am Montag, 25. April 2005 08:16 schrieb Michael Vanier:
> I've been trying to generate an infinite list of random coin flips in GHC
> 6.4, and I've come across some strange behavior:
>
> --
> import System.Random
>
> data Coin = H
I've been trying to generate an infinite list of random coin flips in GHC
6.4, and I've come across some strange behavior:
--
import System.Random
data Coin = H | T deriving (Eq, Show)
-- Generate a random coin flip.
coinFlip :
22 matches
Mail list logo
