How to ask user to play again in console F# - f#

Question

Okay so i'm currently making mastermind in console in fsharp, and im trying to figure out how to ask the user if they want to play again.
let main() =
choosePuzzleMaker()
puzzleGuess()
c <- guess b [([],(0,0))]
while a <> c && d <> 8 do
c <- guess b [(c, validate a c)]
d <- d+1
if d <> 8 then
printfn "GZ! FUCKING MASTERMIND! You completed in %A turns and the code was %A" d a
else
printfn "That didn't go well...?"
printfn "Game Over!"
PlayAgain()
main()
where i tried defining PlayAgain() as:
let rec PlayAgain() =
printfn "Do you want to play again? Please type:
1: Yes
2: No\n"
match System.Console.ReadLine() with
| "1"|"yes"|"Yes" -> printfn "Alright!!!"
choosePuzzleMaker()
| "2"|"no"|"No" -> printfn "The game is over!"
| _ -> printfn "Invalid option! Please try again!"
(PlayAgain())
However, that didn't work so my quesiton is:
How would you make the console take a response yes/no and make the program begin again?

Answer 1

It looks like your problem is a simple indentation mistake. F#, like Python, defines code blocks by indentation. Let me show you an example:
// Some variables
let x = 5
let y = 3
let z = 1
let add1_wrong x =
printfn "Adding 1 to %d produces..." x
printfn "The wrong answer: %d" (x + 1) // Oops! This is wrong
let add1_correct x =
printfn "Adding 1 to %d produces..." x
printfn "The right answer: %d" (x + 1) // This is correct
add1_wrong x
add1_wrong y
add1_wrong z
add1_correct x
add1_correct y
add1_correct z
Try running that in F# Interactive and you'll get the following output:
The wrong answer: 6
Adding 1 to 5 produces...
Adding 1 to 3 produces...
Adding 1 to 1 produces...
Adding 1 to 5 produces...
The right answer: 6
Adding 1 to 3 produces...
The right answer: 4
Adding 1 to 1 produces...
The right answer: 2
Notice how "The wrong answer: 6" was printed right away, before you ever called the add1_wrong function? The way the code is written, it looks like the author intended to put the printfn "The wrong answer" line inside the add1_wrong function, but he made an indentation mistake and put it outside the function instead. So it gets run at the same time as the rest of the code that sets the x, y, and z variables and calls add1_wrong and add1_right.
If you don't yet understand what's going on in that sample code, stop reading now and keep reading it until you understand it. (Or ask a followup question if you still don't understand it after two or three readthroughs, because that means that I haven't explained it very well). It's important that you see the indentation mistake in my sample code before proceeding, because the code you posted has the same mistake in it. Actually, you have two indentation mistakes, but only one of them is causing the problem you've asked us about.
Here's your main() function, exactly as you typed it in this question, with the two indentation mistakes in it:
let main() =
choosePuzzleMaker()
puzzleGuess()
c <- guess b [([],(0,0))]
while a <> c && d <> 8 do
c <- guess b [(c, validate a c)]
d <- d+1
if d <> 8 then
printfn "GZ! FUCKING MASTERMIND! You completed in %A turns and the code was %A" d a
else
printfn "That didn't go well...?"
printfn "Game Over!"
PlayAgain()
main()
And now, here's the same function, with both indentation mistakes solved:
let main() =
choosePuzzleMaker()
puzzleGuess()
c <- guess b [([],(0,0))]
while a <> c && d <> 8 do
c <- guess b [(c, validate a c)]
d <- d+1
if d <> 8 then
printfn "GZ! FUCKING MASTERMIND! You completed in %A turns and the code was %A" d a
else
printfn "That didn't go well...?"
printfn "Game Over!"
PlayAgain()
main()
The c <- guess b [([],(0,0))] line has been indented to match the other lines, and the PlayAgain() call at the end has been indented to be inside your main() function, instead of outside it the way you originally wrote it.
This is what Mark Seemann meant when he wrote in the comments that "the program only calls PlayAgain once". The way you wrote it, the PlayAgain function is not called at the end of main(). Instead, you were calling it once, then calling main() once, and then exiting your program.
By the way, there are lots of other things that I (and other experienced F# programmers) would suggest doing differently in your code -- for example, the names a, b, c and d aren't good names, because they don't give you a clue about what's supposed to be in those names. I'd suggest renaming them as follows:
a should be called correctAnswer
b should be called... actually, I haven't a clue what b is. I know it's passed into the guess function, but I have no idea how it gets used. And that, by the way, is why it's a bad variable name. Even if I don't see any code that uses it, the name alone should give me a clue as to how it's intended to be used.
c should be called thisGuess
d should be called rounds or numberOfGuesses.
Hope that helps you figure out (and fix) your mistake. Let us know if you need further help.
UPDATE: To answer your latest comment, there's a simple solution to your problem, and a clever solution. I'll show you both, because the clever solution will teach you a very valuable programming technique that's used all the time in functional programming languages like F#.
First, the simple solution. In F#, if you need to have two functions that call each other, that's called mutual recursion, and there are two keywords that you'd use to support it: the rec and and keywords. It looks like this:
// Note that these two functions would form an infinite loop!
let rec f x =
g (x + 1)
and g x =
f (x * 2)
The rec keyword tells the F# compiler "The function I'm defining is going to be calling itself, directly or indirectly, at some point -- so please make its name available within the function itself." The and keyword creates a group of functions that all have their names available to each other.
So one way you could solve this is to do the following:
let rec PlayAgain() =
// ...
and main() =
// ...
That would work, but I recommend a second solution. One of the key ideas in functional programming is treating functions as "things" that you can manipulate. That is, you can store functions in lists or arrays, pass them as parameters to other functions, and so on. Which brings us to a very powerful technique for taking a function like your PlayAgain function, and making it more general and re-useable. If a function like PlayAgain has the general structure "Do some calculations or make a decision. Then, depending on what the results were, either do A or B next" -- then what you do is make A and B parameters of the function! In other words, you turn it from a function that takes no parameters into a function that takes one or two parameters, where the parameters are the "what to do next" functions. (Normally you'd take two parameters in a function that decides between two scenarios. But in the case of your PlayAgain function, one of the two "what to do next" steps is "do nothing", so it makes sense to have it take only one parameter). This is known as continuation-passing style -- "continuation" is the traditional functional-programming terminology for any "what to do next" step.
Here's what that would look like:
let rec PlayAgain whatToDoNext =
printfn "Do you want to play again? Please type:
1: Yes
2: No\n"
match System.Console.ReadLine() with
| "1"|"yes"|"Yes" -> printfn "Alright!!!"
whatToDoNext()
| "2"|"no"|"No" -> printfn "The game is over!"
| _ -> printfn "Invalid option! Please try again!"
(PlayAgain())
That's it! All I did was give PlayAgain a parameter, and then call that parameter in the appropriate place. Now we rewrite your main() function as follows (changing just the last line, and using let rec so that the name main will be available inside the main() function):
let rec main() =
choosePuzzleMaker()
puzzleGuess()
c <- guess b [([],(0,0))]
while a <> c && d <> 8 do
c <- guess b [(c, validate a c)]
d <- d+1
if d <> 8 then
printfn "GZ! FUCKING MASTERMIND! You completed in %A turns and the code was %A" d a
else
printfn "That didn't go well...?"
printfn "Game Over!"
PlayAgain main
And with that, you've avoided the use of and, and you've discovered a powerful new programming technique. I strongly recommend that F# beginners avoid using the and keyword if possible, because it tends to add unnecessary complication to reading the code later. And, as in this case, it can often be avoided by simply making the "what to do next" step a parameter, which also means that the PlayAgain function will be more easily reused as-is in later programs.