Haskell Guards involving Boolean Operations and Do
I'm just starting to learn Haskell using the wikibook, doing fine so far since I have taken very basic courses in HS with Visual Basic and Java, but some of the exotic features of Haskell are confusing me when trying to combine more than one. One of the wikibooks has a exercise problem in writing three different strings based on certain names given as input for the user. This is fine when using if-then-else statements, but when I try to use guards I am getting a parsing error on row 6.
main = do
putStrLn "What is your name?"
n <- getLine
|(n == "Simon") || (n == "John") || (n == "Phil")
= putStrLn "Help me make this stuff"
|n == "Koen" = putStrLn "How is this a parse error"
|otherwise "Line 11 looks fine to me"
Which reads " error: parse error on input ‘|’"
Is this a problem with the guard | or the operator ||? the error lists it is on 6:9 if that helps.
EDIT: I have another question regarding a very similar topic now that someone has answered my first question. Wikibooks Haskell tutorials has listed this as another solution to their exercise, using where statements instead of if-then-else:
main = do
putStrLn "Hello, what is your name?"
name <- getLine
putStrLn (message name)
where
greatlanguage = "I think Haskell is a great programming language."
message "Simon" = greatlanguage
message "John" = greatlanguage
message "Phil" = greatlanguage
message "Koen" = "I think debugging Haskell is fun."
message _ = "Sorry, I don't know you."
Is it possible to use the || operator to somehow condense the 3 Simon, John, and Phil lines that call greatlanguage into a single line?
haskell
add a comment |
I'm just starting to learn Haskell using the wikibook, doing fine so far since I have taken very basic courses in HS with Visual Basic and Java, but some of the exotic features of Haskell are confusing me when trying to combine more than one. One of the wikibooks has a exercise problem in writing three different strings based on certain names given as input for the user. This is fine when using if-then-else statements, but when I try to use guards I am getting a parsing error on row 6.
main = do
putStrLn "What is your name?"
n <- getLine
|(n == "Simon") || (n == "John") || (n == "Phil")
= putStrLn "Help me make this stuff"
|n == "Koen" = putStrLn "How is this a parse error"
|otherwise "Line 11 looks fine to me"
Which reads " error: parse error on input ‘|’"
Is this a problem with the guard | or the operator ||? the error lists it is on 6:9 if that helps.
EDIT: I have another question regarding a very similar topic now that someone has answered my first question. Wikibooks Haskell tutorials has listed this as another solution to their exercise, using where statements instead of if-then-else:
main = do
putStrLn "Hello, what is your name?"
name <- getLine
putStrLn (message name)
where
greatlanguage = "I think Haskell is a great programming language."
message "Simon" = greatlanguage
message "John" = greatlanguage
message "Phil" = greatlanguage
message "Koen" = "I think debugging Haskell is fun."
message _ = "Sorry, I don't know you."
Is it possible to use the || operator to somehow condense the 3 Simon, John, and Phil lines that call greatlanguage into a single line?
haskell
4
Please don't edit unrelated questions into your post. Ask them as separate questions instead.
– duplode
Nov 24 '18 at 2:42
add a comment |
I'm just starting to learn Haskell using the wikibook, doing fine so far since I have taken very basic courses in HS with Visual Basic and Java, but some of the exotic features of Haskell are confusing me when trying to combine more than one. One of the wikibooks has a exercise problem in writing three different strings based on certain names given as input for the user. This is fine when using if-then-else statements, but when I try to use guards I am getting a parsing error on row 6.
main = do
putStrLn "What is your name?"
n <- getLine
|(n == "Simon") || (n == "John") || (n == "Phil")
= putStrLn "Help me make this stuff"
|n == "Koen" = putStrLn "How is this a parse error"
|otherwise "Line 11 looks fine to me"
Which reads " error: parse error on input ‘|’"
Is this a problem with the guard | or the operator ||? the error lists it is on 6:9 if that helps.
EDIT: I have another question regarding a very similar topic now that someone has answered my first question. Wikibooks Haskell tutorials has listed this as another solution to their exercise, using where statements instead of if-then-else:
main = do
putStrLn "Hello, what is your name?"
name <- getLine
putStrLn (message name)
where
greatlanguage = "I think Haskell is a great programming language."
message "Simon" = greatlanguage
message "John" = greatlanguage
message "Phil" = greatlanguage
message "Koen" = "I think debugging Haskell is fun."
message _ = "Sorry, I don't know you."
Is it possible to use the || operator to somehow condense the 3 Simon, John, and Phil lines that call greatlanguage into a single line?
haskell
I'm just starting to learn Haskell using the wikibook, doing fine so far since I have taken very basic courses in HS with Visual Basic and Java, but some of the exotic features of Haskell are confusing me when trying to combine more than one. One of the wikibooks has a exercise problem in writing three different strings based on certain names given as input for the user. This is fine when using if-then-else statements, but when I try to use guards I am getting a parsing error on row 6.
main = do
putStrLn "What is your name?"
n <- getLine
|(n == "Simon") || (n == "John") || (n == "Phil")
= putStrLn "Help me make this stuff"
|n == "Koen" = putStrLn "How is this a parse error"
|otherwise "Line 11 looks fine to me"
Which reads " error: parse error on input ‘|’"
Is this a problem with the guard | or the operator ||? the error lists it is on 6:9 if that helps.
EDIT: I have another question regarding a very similar topic now that someone has answered my first question. Wikibooks Haskell tutorials has listed this as another solution to their exercise, using where statements instead of if-then-else:
main = do
putStrLn "Hello, what is your name?"
name <- getLine
putStrLn (message name)
where
greatlanguage = "I think Haskell is a great programming language."
message "Simon" = greatlanguage
message "John" = greatlanguage
message "Phil" = greatlanguage
message "Koen" = "I think debugging Haskell is fun."
message _ = "Sorry, I don't know you."
Is it possible to use the || operator to somehow condense the 3 Simon, John, and Phil lines that call greatlanguage into a single line?
haskell
haskell
edited Dec 20 '18 at 14:32
David Walschots
8,21452647
8,21452647
asked Nov 24 '18 at 2:13
SagarmathaSagarmatha
164
164
4
Please don't edit unrelated questions into your post. Ask them as separate questions instead.
– duplode
Nov 24 '18 at 2:42
add a comment |
4
Please don't edit unrelated questions into your post. Ask them as separate questions instead.
– duplode
Nov 24 '18 at 2:42
4
4
Please don't edit unrelated questions into your post. Ask them as separate questions instead.
– duplode
Nov 24 '18 at 2:42
Please don't edit unrelated questions into your post. Ask them as separate questions instead.
– duplode
Nov 24 '18 at 2:42
add a comment |
3 Answers
3
active
oldest
votes
Guards can only be inserted in function definitions (in the form func a b | condition = ...
) and case
blocks (in the form case x of pattern | condition -> ...
); you can't insert them inside do
blocks the way you're trying to. You will need to use if ... then ... else
here instead.
Thanks for letting me know, I was hoping I could use guards within do blocks because I much prefer their look and space-saving ability compared to if-then-else.
– Sagarmatha
Nov 24 '18 at 2:29
add a comment |
There's many ways to go about this. I'd suggest you consider moving that piece of code out of the do
block to its own function.
for n :: String -> IO ()
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = putStrLn "Help me make this stuff"
| n == "Koen" = putStrLn "How is this a parse error"
|otherwise = putStrLn "Line 11 looks fine to me"
And then call it in your do
block,
main = do
putStrLn "What is your name?"
n <- getLine
foo n
Also it may be more sensible to make your auxiliary function "pure",
for n :: String -> String
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
and call it via,
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn (foo n)
If you prefer you can also make the 1st guard simpler,
foo n | n `elem` ["Simon", "John", "Phil"] = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
If you really want to inline it in the do
block then you could adapt one of those solutions via a case construction, e.g.
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn $ case n of
_ | n `elem` ["Simon", "John", "Phil"] -> "Help me make this stuff"
_ | n == "Koen" -> "How is this a parse error"
_ -> "Line 11 looks fine to me"
The second clause of your final segment should really just pattern-match on Koen, rather than using an == guard.
– amalloy
Nov 24 '18 at 3:02
Could have done that, true. But not just in the final segment. Before I could also have done e.g.foo "Koen" = "How is this a parse error"
and thenfoo _ = "Line 11 looks fine to me"
. Just didn't think mixing pattern matching and guards was worth the added complication. Particularly since he seemed keen on using guards
– Jorge Adriano
Nov 24 '18 at 3:11
I like these styles, but I have mixed feelings about then
in the lastcase n
. On one hand, I'd writecase ()
instead, since we ignore that value and only use guards. On the other hand, we are considering the possible values forn
in the guards, so writingn
there documents this fact.
– chi
Nov 24 '18 at 9:30
Not sure myself. I feel then
there adds readability, but I can see the arguments against it. Acase | cond -> ...
construct without the pattern matching would look nice, but I suppose not useful enough to justify yet another extension of the language.
– Jorge Adriano
Nov 24 '18 at 11:52
@JorgeAdriano: There is theMultiWayIf
extension, which providesif | cond1 -> … | cond2 -> … | cond3 -> …
, if that’s what you mean by yourcase | cond -> …
notation.
– Jon Purdy
Nov 25 '18 at 18:44
|
show 1 more comment
To complement the other answers, I'll add two alternatives (not necessarily better ones).
main = do
putStrLn "What is your name?"
n <- getLine
case () of
_ | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
This requires the MultiWayIf
extension to be turned on.
{-# LANGUAGE MultiWayIf #-} -- at the top of the file
main = do
putStrLn "What is your name?"
n <- getLine
if | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
Remember that even after otherwise
we need ->
, or we trigger a parse error.
Multiwayif sure looks interesting and useful, how do I enable this extension? Is it part of a library?
– Sagarmatha
Nov 25 '18 at 3:12
@Sagarmatha You need to add the line{-# LANGUAGE MultiWayIf #-}
at the top of the file as I show above.
– chi
Nov 25 '18 at 9:22
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454632%2fhaskell-guards-involving-boolean-operations-and-do%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Guards can only be inserted in function definitions (in the form func a b | condition = ...
) and case
blocks (in the form case x of pattern | condition -> ...
); you can't insert them inside do
blocks the way you're trying to. You will need to use if ... then ... else
here instead.
Thanks for letting me know, I was hoping I could use guards within do blocks because I much prefer their look and space-saving ability compared to if-then-else.
– Sagarmatha
Nov 24 '18 at 2:29
add a comment |
Guards can only be inserted in function definitions (in the form func a b | condition = ...
) and case
blocks (in the form case x of pattern | condition -> ...
); you can't insert them inside do
blocks the way you're trying to. You will need to use if ... then ... else
here instead.
Thanks for letting me know, I was hoping I could use guards within do blocks because I much prefer their look and space-saving ability compared to if-then-else.
– Sagarmatha
Nov 24 '18 at 2:29
add a comment |
Guards can only be inserted in function definitions (in the form func a b | condition = ...
) and case
blocks (in the form case x of pattern | condition -> ...
); you can't insert them inside do
blocks the way you're trying to. You will need to use if ... then ... else
here instead.
Guards can only be inserted in function definitions (in the form func a b | condition = ...
) and case
blocks (in the form case x of pattern | condition -> ...
); you can't insert them inside do
blocks the way you're trying to. You will need to use if ... then ... else
here instead.
answered Nov 24 '18 at 2:23
jwodderjwodder
33.5k35684
33.5k35684
Thanks for letting me know, I was hoping I could use guards within do blocks because I much prefer their look and space-saving ability compared to if-then-else.
– Sagarmatha
Nov 24 '18 at 2:29
add a comment |
Thanks for letting me know, I was hoping I could use guards within do blocks because I much prefer their look and space-saving ability compared to if-then-else.
– Sagarmatha
Nov 24 '18 at 2:29
Thanks for letting me know, I was hoping I could use guards within do blocks because I much prefer their look and space-saving ability compared to if-then-else.
– Sagarmatha
Nov 24 '18 at 2:29
Thanks for letting me know, I was hoping I could use guards within do blocks because I much prefer their look and space-saving ability compared to if-then-else.
– Sagarmatha
Nov 24 '18 at 2:29
add a comment |
There's many ways to go about this. I'd suggest you consider moving that piece of code out of the do
block to its own function.
for n :: String -> IO ()
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = putStrLn "Help me make this stuff"
| n == "Koen" = putStrLn "How is this a parse error"
|otherwise = putStrLn "Line 11 looks fine to me"
And then call it in your do
block,
main = do
putStrLn "What is your name?"
n <- getLine
foo n
Also it may be more sensible to make your auxiliary function "pure",
for n :: String -> String
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
and call it via,
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn (foo n)
If you prefer you can also make the 1st guard simpler,
foo n | n `elem` ["Simon", "John", "Phil"] = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
If you really want to inline it in the do
block then you could adapt one of those solutions via a case construction, e.g.
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn $ case n of
_ | n `elem` ["Simon", "John", "Phil"] -> "Help me make this stuff"
_ | n == "Koen" -> "How is this a parse error"
_ -> "Line 11 looks fine to me"
The second clause of your final segment should really just pattern-match on Koen, rather than using an == guard.
– amalloy
Nov 24 '18 at 3:02
Could have done that, true. But not just in the final segment. Before I could also have done e.g.foo "Koen" = "How is this a parse error"
and thenfoo _ = "Line 11 looks fine to me"
. Just didn't think mixing pattern matching and guards was worth the added complication. Particularly since he seemed keen on using guards
– Jorge Adriano
Nov 24 '18 at 3:11
I like these styles, but I have mixed feelings about then
in the lastcase n
. On one hand, I'd writecase ()
instead, since we ignore that value and only use guards. On the other hand, we are considering the possible values forn
in the guards, so writingn
there documents this fact.
– chi
Nov 24 '18 at 9:30
Not sure myself. I feel then
there adds readability, but I can see the arguments against it. Acase | cond -> ...
construct without the pattern matching would look nice, but I suppose not useful enough to justify yet another extension of the language.
– Jorge Adriano
Nov 24 '18 at 11:52
@JorgeAdriano: There is theMultiWayIf
extension, which providesif | cond1 -> … | cond2 -> … | cond3 -> …
, if that’s what you mean by yourcase | cond -> …
notation.
– Jon Purdy
Nov 25 '18 at 18:44
|
show 1 more comment
There's many ways to go about this. I'd suggest you consider moving that piece of code out of the do
block to its own function.
for n :: String -> IO ()
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = putStrLn "Help me make this stuff"
| n == "Koen" = putStrLn "How is this a parse error"
|otherwise = putStrLn "Line 11 looks fine to me"
And then call it in your do
block,
main = do
putStrLn "What is your name?"
n <- getLine
foo n
Also it may be more sensible to make your auxiliary function "pure",
for n :: String -> String
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
and call it via,
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn (foo n)
If you prefer you can also make the 1st guard simpler,
foo n | n `elem` ["Simon", "John", "Phil"] = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
If you really want to inline it in the do
block then you could adapt one of those solutions via a case construction, e.g.
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn $ case n of
_ | n `elem` ["Simon", "John", "Phil"] -> "Help me make this stuff"
_ | n == "Koen" -> "How is this a parse error"
_ -> "Line 11 looks fine to me"
The second clause of your final segment should really just pattern-match on Koen, rather than using an == guard.
– amalloy
Nov 24 '18 at 3:02
Could have done that, true. But not just in the final segment. Before I could also have done e.g.foo "Koen" = "How is this a parse error"
and thenfoo _ = "Line 11 looks fine to me"
. Just didn't think mixing pattern matching and guards was worth the added complication. Particularly since he seemed keen on using guards
– Jorge Adriano
Nov 24 '18 at 3:11
I like these styles, but I have mixed feelings about then
in the lastcase n
. On one hand, I'd writecase ()
instead, since we ignore that value and only use guards. On the other hand, we are considering the possible values forn
in the guards, so writingn
there documents this fact.
– chi
Nov 24 '18 at 9:30
Not sure myself. I feel then
there adds readability, but I can see the arguments against it. Acase | cond -> ...
construct without the pattern matching would look nice, but I suppose not useful enough to justify yet another extension of the language.
– Jorge Adriano
Nov 24 '18 at 11:52
@JorgeAdriano: There is theMultiWayIf
extension, which providesif | cond1 -> … | cond2 -> … | cond3 -> …
, if that’s what you mean by yourcase | cond -> …
notation.
– Jon Purdy
Nov 25 '18 at 18:44
|
show 1 more comment
There's many ways to go about this. I'd suggest you consider moving that piece of code out of the do
block to its own function.
for n :: String -> IO ()
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = putStrLn "Help me make this stuff"
| n == "Koen" = putStrLn "How is this a parse error"
|otherwise = putStrLn "Line 11 looks fine to me"
And then call it in your do
block,
main = do
putStrLn "What is your name?"
n <- getLine
foo n
Also it may be more sensible to make your auxiliary function "pure",
for n :: String -> String
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
and call it via,
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn (foo n)
If you prefer you can also make the 1st guard simpler,
foo n | n `elem` ["Simon", "John", "Phil"] = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
If you really want to inline it in the do
block then you could adapt one of those solutions via a case construction, e.g.
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn $ case n of
_ | n `elem` ["Simon", "John", "Phil"] -> "Help me make this stuff"
_ | n == "Koen" -> "How is this a parse error"
_ -> "Line 11 looks fine to me"
There's many ways to go about this. I'd suggest you consider moving that piece of code out of the do
block to its own function.
for n :: String -> IO ()
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = putStrLn "Help me make this stuff"
| n == "Koen" = putStrLn "How is this a parse error"
|otherwise = putStrLn "Line 11 looks fine to me"
And then call it in your do
block,
main = do
putStrLn "What is your name?"
n <- getLine
foo n
Also it may be more sensible to make your auxiliary function "pure",
for n :: String -> String
foo n | n == "Simon" ||
n == "John" ||
n == "Phil" = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
and call it via,
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn (foo n)
If you prefer you can also make the 1st guard simpler,
foo n | n `elem` ["Simon", "John", "Phil"] = "Help me make this stuff"
| n == "Koen" = "How is this a parse error"
|otherwise = "Line 11 looks fine to me"
If you really want to inline it in the do
block then you could adapt one of those solutions via a case construction, e.g.
main = do
putStrLn "What is your name?"
n <- getLine
putStrLn $ case n of
_ | n `elem` ["Simon", "John", "Phil"] -> "Help me make this stuff"
_ | n == "Koen" -> "How is this a parse error"
_ -> "Line 11 looks fine to me"
answered Nov 24 '18 at 2:52
Jorge AdrianoJorge Adriano
2,220918
2,220918
The second clause of your final segment should really just pattern-match on Koen, rather than using an == guard.
– amalloy
Nov 24 '18 at 3:02
Could have done that, true. But not just in the final segment. Before I could also have done e.g.foo "Koen" = "How is this a parse error"
and thenfoo _ = "Line 11 looks fine to me"
. Just didn't think mixing pattern matching and guards was worth the added complication. Particularly since he seemed keen on using guards
– Jorge Adriano
Nov 24 '18 at 3:11
I like these styles, but I have mixed feelings about then
in the lastcase n
. On one hand, I'd writecase ()
instead, since we ignore that value and only use guards. On the other hand, we are considering the possible values forn
in the guards, so writingn
there documents this fact.
– chi
Nov 24 '18 at 9:30
Not sure myself. I feel then
there adds readability, but I can see the arguments against it. Acase | cond -> ...
construct without the pattern matching would look nice, but I suppose not useful enough to justify yet another extension of the language.
– Jorge Adriano
Nov 24 '18 at 11:52
@JorgeAdriano: There is theMultiWayIf
extension, which providesif | cond1 -> … | cond2 -> … | cond3 -> …
, if that’s what you mean by yourcase | cond -> …
notation.
– Jon Purdy
Nov 25 '18 at 18:44
|
show 1 more comment
The second clause of your final segment should really just pattern-match on Koen, rather than using an == guard.
– amalloy
Nov 24 '18 at 3:02
Could have done that, true. But not just in the final segment. Before I could also have done e.g.foo "Koen" = "How is this a parse error"
and thenfoo _ = "Line 11 looks fine to me"
. Just didn't think mixing pattern matching and guards was worth the added complication. Particularly since he seemed keen on using guards
– Jorge Adriano
Nov 24 '18 at 3:11
I like these styles, but I have mixed feelings about then
in the lastcase n
. On one hand, I'd writecase ()
instead, since we ignore that value and only use guards. On the other hand, we are considering the possible values forn
in the guards, so writingn
there documents this fact.
– chi
Nov 24 '18 at 9:30
Not sure myself. I feel then
there adds readability, but I can see the arguments against it. Acase | cond -> ...
construct without the pattern matching would look nice, but I suppose not useful enough to justify yet another extension of the language.
– Jorge Adriano
Nov 24 '18 at 11:52
@JorgeAdriano: There is theMultiWayIf
extension, which providesif | cond1 -> … | cond2 -> … | cond3 -> …
, if that’s what you mean by yourcase | cond -> …
notation.
– Jon Purdy
Nov 25 '18 at 18:44
The second clause of your final segment should really just pattern-match on Koen, rather than using an == guard.
– amalloy
Nov 24 '18 at 3:02
The second clause of your final segment should really just pattern-match on Koen, rather than using an == guard.
– amalloy
Nov 24 '18 at 3:02
Could have done that, true. But not just in the final segment. Before I could also have done e.g.
foo "Koen" = "How is this a parse error"
and then foo _ = "Line 11 looks fine to me"
. Just didn't think mixing pattern matching and guards was worth the added complication. Particularly since he seemed keen on using guards– Jorge Adriano
Nov 24 '18 at 3:11
Could have done that, true. But not just in the final segment. Before I could also have done e.g.
foo "Koen" = "How is this a parse error"
and then foo _ = "Line 11 looks fine to me"
. Just didn't think mixing pattern matching and guards was worth the added complication. Particularly since he seemed keen on using guards– Jorge Adriano
Nov 24 '18 at 3:11
I like these styles, but I have mixed feelings about the
n
in the last case n
. On one hand, I'd write case ()
instead, since we ignore that value and only use guards. On the other hand, we are considering the possible values for n
in the guards, so writing n
there documents this fact.– chi
Nov 24 '18 at 9:30
I like these styles, but I have mixed feelings about the
n
in the last case n
. On one hand, I'd write case ()
instead, since we ignore that value and only use guards. On the other hand, we are considering the possible values for n
in the guards, so writing n
there documents this fact.– chi
Nov 24 '18 at 9:30
Not sure myself. I feel the
n
there adds readability, but I can see the arguments against it. A case | cond -> ...
construct without the pattern matching would look nice, but I suppose not useful enough to justify yet another extension of the language.– Jorge Adriano
Nov 24 '18 at 11:52
Not sure myself. I feel the
n
there adds readability, but I can see the arguments against it. A case | cond -> ...
construct without the pattern matching would look nice, but I suppose not useful enough to justify yet another extension of the language.– Jorge Adriano
Nov 24 '18 at 11:52
@JorgeAdriano: There is the
MultiWayIf
extension, which provides if | cond1 -> … | cond2 -> … | cond3 -> …
, if that’s what you mean by your case | cond -> …
notation.– Jon Purdy
Nov 25 '18 at 18:44
@JorgeAdriano: There is the
MultiWayIf
extension, which provides if | cond1 -> … | cond2 -> … | cond3 -> …
, if that’s what you mean by your case | cond -> …
notation.– Jon Purdy
Nov 25 '18 at 18:44
|
show 1 more comment
To complement the other answers, I'll add two alternatives (not necessarily better ones).
main = do
putStrLn "What is your name?"
n <- getLine
case () of
_ | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
This requires the MultiWayIf
extension to be turned on.
{-# LANGUAGE MultiWayIf #-} -- at the top of the file
main = do
putStrLn "What is your name?"
n <- getLine
if | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
Remember that even after otherwise
we need ->
, or we trigger a parse error.
Multiwayif sure looks interesting and useful, how do I enable this extension? Is it part of a library?
– Sagarmatha
Nov 25 '18 at 3:12
@Sagarmatha You need to add the line{-# LANGUAGE MultiWayIf #-}
at the top of the file as I show above.
– chi
Nov 25 '18 at 9:22
add a comment |
To complement the other answers, I'll add two alternatives (not necessarily better ones).
main = do
putStrLn "What is your name?"
n <- getLine
case () of
_ | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
This requires the MultiWayIf
extension to be turned on.
{-# LANGUAGE MultiWayIf #-} -- at the top of the file
main = do
putStrLn "What is your name?"
n <- getLine
if | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
Remember that even after otherwise
we need ->
, or we trigger a parse error.
Multiwayif sure looks interesting and useful, how do I enable this extension? Is it part of a library?
– Sagarmatha
Nov 25 '18 at 3:12
@Sagarmatha You need to add the line{-# LANGUAGE MultiWayIf #-}
at the top of the file as I show above.
– chi
Nov 25 '18 at 9:22
add a comment |
To complement the other answers, I'll add two alternatives (not necessarily better ones).
main = do
putStrLn "What is your name?"
n <- getLine
case () of
_ | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
This requires the MultiWayIf
extension to be turned on.
{-# LANGUAGE MultiWayIf #-} -- at the top of the file
main = do
putStrLn "What is your name?"
n <- getLine
if | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
Remember that even after otherwise
we need ->
, or we trigger a parse error.
To complement the other answers, I'll add two alternatives (not necessarily better ones).
main = do
putStrLn "What is your name?"
n <- getLine
case () of
_ | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
This requires the MultiWayIf
extension to be turned on.
{-# LANGUAGE MultiWayIf #-} -- at the top of the file
main = do
putStrLn "What is your name?"
n <- getLine
if | n == "Simon" || n == "John" || n == "Phil"
-> putStrLn "Help me make this stuff"
| n == "Koen"
-> putStrLn "How is this a parse error"
| otherwise
-> putStrLn "Line 11 looks fine to me"
Remember that even after otherwise
we need ->
, or we trigger a parse error.
answered Nov 24 '18 at 9:43
chichi
74.9k284140
74.9k284140
Multiwayif sure looks interesting and useful, how do I enable this extension? Is it part of a library?
– Sagarmatha
Nov 25 '18 at 3:12
@Sagarmatha You need to add the line{-# LANGUAGE MultiWayIf #-}
at the top of the file as I show above.
– chi
Nov 25 '18 at 9:22
add a comment |
Multiwayif sure looks interesting and useful, how do I enable this extension? Is it part of a library?
– Sagarmatha
Nov 25 '18 at 3:12
@Sagarmatha You need to add the line{-# LANGUAGE MultiWayIf #-}
at the top of the file as I show above.
– chi
Nov 25 '18 at 9:22
Multiwayif sure looks interesting and useful, how do I enable this extension? Is it part of a library?
– Sagarmatha
Nov 25 '18 at 3:12
Multiwayif sure looks interesting and useful, how do I enable this extension? Is it part of a library?
– Sagarmatha
Nov 25 '18 at 3:12
@Sagarmatha You need to add the line
{-# LANGUAGE MultiWayIf #-}
at the top of the file as I show above.– chi
Nov 25 '18 at 9:22
@Sagarmatha You need to add the line
{-# LANGUAGE MultiWayIf #-}
at the top of the file as I show above.– chi
Nov 25 '18 at 9:22
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454632%2fhaskell-guards-involving-boolean-operations-and-do%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
Please don't edit unrelated questions into your post. Ask them as separate questions instead.
– duplode
Nov 24 '18 at 2:42