Haskell Guards involving Boolean Operations and Do












2















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?










share|improve this question




















  • 4





    Please don't edit unrelated questions into your post. Ask them as separate questions instead.

    – duplode
    Nov 24 '18 at 2:42
















2















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?










share|improve this question




















  • 4





    Please don't edit unrelated questions into your post. Ask them as separate questions instead.

    – duplode
    Nov 24 '18 at 2:42














2












2








2








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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














  • 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












3 Answers
3






active

oldest

votes


















2














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.






share|improve this answer
























  • 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



















2














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"





share|improve this answer
























  • 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











  • 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











  • @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



















2














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.






share|improve this answer
























  • 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











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
});


}
});














draft saved

draft discarded


















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









2














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.






share|improve this answer
























  • 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
















2














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.






share|improve this answer
























  • 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














2












2








2







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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













2














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"





share|improve this answer
























  • 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











  • 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











  • @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
















2














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"





share|improve this answer
























  • 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











  • 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











  • @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














2












2








2







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"





share|improve this answer













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"






share|improve this answer












share|improve this answer



share|improve this answer










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 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











  • 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



















  • 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











  • 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











  • @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

















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











2














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.






share|improve this answer
























  • 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
















2














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.






share|improve this answer
























  • 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














2












2








2







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

To store a contact into the json file from server.js file using a class in NodeJS

Redirect URL with Chrome Remote Debugging Android Devices

Dieringhausen