Parse Error: (incorrect indentation or misplaced bracket) - parsing

I'm starting out to learn Haskell. Even though I'm a dunce extraordinaire, I am intent on making this work. The error I received is listed as the title. This is the code that I wrote to try to implement the behavior of replicating a list (n) times and concatenating its new length as a new list. Now I have a basic understanding of how parsing works in Haskell, below my original code I will give example of some modified code to see if my understanding on parsing is adequate. My question for now is how I can properly indent or structure my block in order to not receive this error (is that specific enough :O) -- is there a piece of information I'm missing when it comes to creating instances and formatting? PLEASE DO NOT TELL ME OR OFFER SUGGESTIONS IF YOU NOTICE THAT MY CURRENT INSTANCE OR MAIN FUNCTION ARE SYNTACTICALLY WRONG. I want to figure it out and will deal with that GHC error when I get to it. (I hope that's the proper way to learn). BUT if I could ask for anyone's help in getting past this first obstacle in understanding proper formatting, I'd be grateful.
module Main where
import Data.List
n :: Int
x :: [Char]
instance Data stutter n x where
x = []
n = replicate >>= x : (n:xs)
stutter >>= main = concat [x:xs]
let stutter 6 "Iwannabehere" -- <-- parse error occurs here!!!
--Modified code with appropriate brackets, at least where I think they go.
module Main where
import Data.List
n :: Int
x :: [Char]
instance Data stutter n x where{
;x = []
;n = replicate >>= x : (n:xs)
;stutter >>= main = concat [x:xs]
;
};let stutter 6 "Iwannabehere" -- there should be no bracket of any kind at the end of this
I placed the 'let' expression on the outside of the block, I don't believe it goes inside and I also receive a parsing error if I do that. Not correct but I thought I'd ask anyway.

I'm not sure what the instance Data stutter n x is supposed to be, the instance XYZ where syntax is used solely for typeclasses, but you have a couple syntax errors here.
First of all, while GHC says that the error is on let stutter 6 "Iwannabehere", your first error occurs before that with stutter >>= main = concat [x:xs]. A single = sign is reserved for assignments, which are merely definitions. You can have assignments at the top level, inside a where block, or inside a let block (the where includes typeclass instance definitions). You can't have an assignment be part of an expression like x >>= y = z.
Your next syntax error is the let itself. let blocks can not appear at the top level, they only appear within another definition. You use let in GHCi but the reasons for that are outside the scope of this answer. Suffice to say that entering expression in GHCi is not equivalent to the top level of a source file.
Next, if you were to use a let block somewhere, it can only contain definitions. The syntax looks more like
let <name> [<args>] = <definition>
[<name> [<args>] = <definition>]
in <expression>
And this whole block makes an expression. For example, you could write
def f(x, y, z):
w = x + y + z
u = x - y - z
return w * u
in Python, and this would be equivalent to the Haskell function definition
f x y z = let w = x + y + z
u = x - y - z
in w * u
It only defines local variables. There is another form when you're using it inside do blocks where you can exclude the in <expression> part, such as
main = do
name <- getLine
let message = if length name > 5 then "short name" else "long name"
goodbye n = putStrLn ("Goodbye, " ++ n)
putStrLn message
goodbye name
Note that there is no need to use in here. You can if you want, it just means you have to start a new do block:
main = do
name <- getLine
let message = ...
goodbye n = ...
in do
putStrLn message
goodbye name
And this isn't as pretty.
Hopefully this points you more towards correct syntax, but it looks like you have some misunderstandings about how Haskell works. Have you looked at Learn You a Haskell? It's a pretty gentle and fun introduction to the language that can really help you learn the syntax and core ideas.

Your parse error is from the let keyword. Remove it and no error related to that will occur. let x = y is only relevant in GHCi and do-blocks, neither of which is relevant at this point. Essentially, just replace it with this line:
theWordIGet = stutter 6 "Iwannabehere"
Secondly, instance keyword in Haskell has absolutley nothing to do with what you want to do at this stage. This is not how Haskell functions are defined, which is what I'm guessing you want to do. This is what you're wanting to do to create a stutter function, assuming it simply repeats a string n times.
stutter :: Int -> String -> String
stutter n x = concat (replicate n x)
You'll also want to remove the type declarations for the (out-of-scope) values n and x: they're not objects, they're arguments for a function, which has its own signature determining the types of n and x within a function call.
Lastly, I imagine you will want to print the value of stutter 6 "Iwannabehere" when the program is executed. To do that, just add this:
main :: IO ()
main = print (stutter 6 "Iwannabehere")
In conclusion, I implore you to start from scratch and read 'Learn You a Haskell' online here, because you're going off in entirely the wrong direction - the program you've quoted is a jumble of expressions that could have a meaning, but are in the wrong place entirely. The book will show you the syntax of Haskell much better that I can write about in this one answer, and will explain fully how to make your program behave in the way you expect.

Related

John Hughes' Deterministic LL(1) parsing with Arrow and errors

I wanted to write a parser based on John Hughes' paper Generalizing Monads to Arrows. When reading through and trying to reimplement his code I realized there were some things that didn't quite make sense. In one section he lays out a parser implementation based on Swierstra and Duponchel's paper Deterministic, error-correcting combinator parsers using Arrows. The parser type he describes looks like this:
data StaticParser ch = SP Bool [ch]
data DynamicParser ch a b = DP (a, [ch]) -> (b, [ch])
data Parser ch a b = P (StaticParser ch) (DynamicParser ch a b)
with the composition operator looking something like this:
(.) :: Parser ch b c -> Parser ch a b -> Parser ch a c
P (SP e2 st2) (DP f2) . P (SP e1 st1) (DP f1) =
P (SP (e1 && e2) (st1 `union` if e1 then st2 else []))
(DP $ f2 . f1)
The issue is that the composition of parsers q . p 'forgets' q's starting symbols. One possible interpretation I thought of is that Hughes' expects all our DynamicParsers to be total such that a symbol parser's type signature would be symbol :: ch -> Parser ch a (Maybe ch) instead of symbol :: ch -> Parser ch a ch. This still seems awkward though since we have to duplicate information putting starting symbol information in both the StaticParser and DynamicParser. Another issue is that almost all parsers will have the potential to throw which means we will have to spend a lot of time inside Maybe or Either creating what is essentially the "monads do not compose problem." This could be remedied by rewriting DynamicParser itself to handle failure or as an Arrow transformer, but this is straying quite a bit from the paper. None of these issues are addressed in the paper, and the Parser is presented as if it obviously works, so I feel like I must me missing something basic. If someone can catch what I missed that would be super helpful.
I think the deterministic parsers described by Swierstra and Duponcheel are a bit different from traditional parsers: they do not handle failure at all, only choice.
See also the invokeDet function in the S&D paper:
invokeDet :: Symbol s => DetPar s a -> Input s -> a
invokeDet (_, p) inp = case p inp [] of (a, _) -> a
This function clearly assumes it will always be able to find a valid parse.
With the arrow version of the parsers described by Hughes you can write a examples like this:
main = do
let p = symbol 'a' >>> (symbol 'b' <+> symbol 'c')
print $ invokeDet p "ab"
print $ invokeDet p "ac"
Which will print the expected:
'b'
'c'
However, if you write a "failing" parse:
main = do
let p = symbol 'a' >>> (symbol 'b' <+> symbol 'c')
print $ invokeDet p "ad"
It will still print:
'c'
To make this behavior a bit more sensible, Swierstra and Duponcheel also introduce error-correction. The output 'c' is expected if we assume the erroneous character d has been corrected to be a c in the input. This requires an extra mechanism which presumably was too complicated to include in Hughes' paper.
I have uploaded the implementation I used to get these results here: https://gist.github.com/noughtmare/eced4441332784cc8212e9c0adb68b35
For more information about a more practical parser in the same style (but no longer deterministic and no longer limited to LL(1)) I really like the "Combinator Parsing: A Short Tutorial" by Swierstra. An interesting excerpt from section 9.3:
A subtle point here is the question how to deal with monadic parsers. As we described in [13] the static analysis does not go well with monadic computations, since in that case we dynamically build new parses based on the input produced thus far: the whole idea of a static analysis is that it is static. This observation has lead John Hughes to propose arrows for dealing with such situations [7]. It is only recently that we realised that, although our arguments still hold in general, they do not apply to the case of the LL(1) analysis. If we want to compute the symbols which can be recognised as the first symbol by a parser of the form p >>= q then we are only interested in the starting symbols of the right hand side if the left hand side can recognise the empty string; the good news is that in that case we statically know what value will be returned as a witness, and can pass this value on to q, and analyse the result of this call statically too. Unfortunately we will have to take special precautions in case the left hand side operator contains a call to pErrors in one of the empty derivations, since then it is no longer true that the witness of this alternative can be determined statically.
The full parser implementation by Swierstra can be found in the uu-parsinglib package, although I do not know how many of the extensions are implemented there.

Understanding Read instance

I made Read and Show instances of my data, but did not understand the Read instance
data Tests = Zero
| One Int
| Two Int Double
instance Show Tests where
show Zero = "ZERO"
show (One i) = printf "ONE %i" i
show (Two i j) = printf "TWO %i %f" i j
instance Read Tests where
readsPrec _ str = [(mkTests str, "")]
mkTests :: String -> Tests
mkTests = check . words
check :: [String] -> Tests
check ["ZERO"] = Zero
check ["ONE", i] = One (read i)
check ["TWO", i, j] = Two (read i) (read j)
check _ = error "no parse"
main :: IO ()
main = do
print Zero
print $ One 10
print $ Two 1 3.14
let x = read "ZERO" :: Tests
print x
let y = read "ONE 2" :: Tests
print y
let z = read "TWO 2 5.5" :: Tests
print z
This is output
ZERO
ONE 10
TWO 1 3.14
ZERO
ONE 2
TWO 2 5.5
Here are questions:
What is recommend way to implement Read instance?
The minimal complete definition of Read class is readsPrec | readPrec
and readPrec :: ReadPrec a description wrote
Proposed replacement for readsPrec using new-style parsers (GHC only).
Should I use readPrec instead, How? I can't find any example on the net that I can understand.
What is the new-style parsers, is it parsec?
What is the first Int argument of readsPrec :: Int -> ReadS a , is using for?
Is there anyway to somehow deriving Read from Show?
In the past I could use deriving (Show,Read) to most of the job. But this time I want to move to next level.
In my opinion the correct way to implement Read is to derive it and otherwise, it is likely better to move on to more sophisticated parsers. Here is answers to all of your questions anyways.
readPrec is a simple parser combinator based approach for that GHC provides. If you are willing to sacrifice portability for your Read instance you can use it and it makes parsing easier.
I include a small example of how you could use readPrec below
parsec is different from readPrec, however both are parser combinator like. Parsec is a much more complete parser library. Another parser combinator library is attoparsec which works very similarly to parsec.
parsec and attoparsec can't be used with the ordinary Read typeclass (at least directly) but the greater flexibility they offer makes them a good idea for any time you want more complex parsing.
The Int argument to readsPrec is for dealing with precedence when parsing. This might matter when you want to parse arithmetic expressions. You can choose to fail parsing if the precedence is higher than the precedence of the current operator.
Deriving Read from Show isn't possible unfortunately.
Here are a couple of snippets that show how I would implement Read using ReadPrec.
ReadPrec example:
instance Read Tests where
readPrec = choice [pZero, pOne, pTwo] where
pChar c = do
c' <- get
if c == c'
then return c
else pfail
pZero = traverse pChar "ZERO" *> pure Zero
pOne = One <$> (traverse pChar "ONE " *> readPrec)
pTwo = Two <$> (traverse pChar "TWO " *> readPrec) <*> readPrec
In general implementing Read is less intuitive than more heavyweight parsers. Depending on what you want to parse I highly suggest learning parsec or attoparsec since they are extremely useful when you want to parse even more complicated things.

Re-implementing List.map in OCaml/F# with correct side effect order?

According to this previous answer
You could implement List.map like this:
let rec map project = function
| [] -> []
| head :: tail ->
project head :: map project tail ;;
but instead, it is implemented like this:
let rec map project = function
| [] -> []
| head :: tail ->
let result = project head in
result :: map project tail ;;
They say that it is done this way to make sure the projection function is called in the expected order in case it has side effects, e.g.
map print_int [1;2;3] ;;
should print 123, but the first implementation would print 321. However, when I test both of them myself in OCaml and F#, they produce exactly the same 123 result.
(Note that I am testing this in the OCaml and F# REPLs--Nick in the comments suggests this might be the cause of my inability to reproduce, but why?)
What am I misunderstanding? Can someone elaborate why they should produce different orders and how I can reproduce? This runs contrary to my previous understanding of OCaml code I've written in the past so this was surprising to me and I want to make sure not to repeat the mistake. When I read the two, I read it as exactly the same thing with an extraneous intermediary binding.
My only guess is that the order of expression evaluation using cons is right to left, but that seems very odd?
This is being done purely as research to better understand how OCaml executes code, I don't really need to create my own List.map for production code.
The point is that the order of function application in OCaml is unspecified, not that it will be in some specific undesired order.
When evaluating this expression:
project head :: map project tail
OCaml is allowed to evaluate project head first or it can evaluate map project tail first. Which one it chooses to do is unspecified. (In theory it would probably be admissible for the order to be different for different calls.) Since you want a specified order, you need to use the form with let.
The fact that the order is unspecified is documented in Section 6.7 of the OCaml manual. See the section Function application:
The order in which the expressions expr, argument1, …, argumentn are evaluated is not specified.
(The claim that the evaluation order is unspecified isn't something you can test. No number of cases of a particular order prove that that order is always going to be chosen.)
So when you have an implementation of map like this:
let rec map f = function
| [] -> []
| a::l -> f a :: map f l
none of the function applications (f a) within the map calls are guaranteed to be evaluated sequentially in the order you'd expect. So when you try this:
map print_int [1;2;3]
you get the output
321- : unit list = [(); (); ()]
since by the time those function applications weren't executed in a specific order.
Now when you implement the map like this:
let rec map f = function
| [] -> []
| a::l -> let r = f a in r :: map f l
you're forcing the function applications to be executed in the order you're expecting because you explicitly make a call to evaluate let r = f a.
So now when you try:
map print_int [1;2;3]
you will get
123- : unit list = [(); (); ()]
because you've explicitly made an effort to evaluate the function applications in order.

How to ask user to play again in console F#

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

How do I know if a function is tail recursive in F#

I wrote the follwing function:
let str2lst str =
let rec f s acc =
match s with
| "" -> acc
| _ -> f (s.Substring 1) (s.[0]::acc)
f str []
How can I know if the F# compiler turned it into a loop? Is there a way to find out without using Reflector (I have no experience with Reflector and I Don't know C#)?
Edit: Also, is it possible to write a tail recursive function without using an inner function, or is it necessary for the loop to reside in?
Also, Is there a function in F# std lib to run a given function a number of times, each time giving it the last output as input? Lets say I have a string, I want to run a function over the string then run it again over the resultant string and so on...
Unfortunately there is no trivial way.
It is not too hard to read the source code and use the types and determine whether something is a tail call by inspection (is it 'the last thing', and not in a 'try' block), but people second-guess themselves and make mistakes. There's no simple automated way (other than e.g. inspecting the generated code).
Of course, you can just try your function on a large piece of test data and see if it blows up or not.
The F# compiler will generate .tail IL instructions for all tail calls (unless the compiler flags to turn them off is used - used for when you want to keep stack frames for debugging), with the exception that directly tail-recursive functions will be optimized into loops. (EDIT: I think nowadays the F# compiler also fails to emit .tail in cases where it can prove there are no recursive loops through this call site; this is an optimization given that the .tail opcode is a little slower on many platforms.)
'tailcall' is a reserved keyword, with the idea that a future version of F# may allow you to write e.g.
tailcall func args
and then get a warning/error if it's not a tail call.
Only functions that are not naturally tail-recursive (and thus need an extra accumulator parameter) will 'force' you into the 'inner function' idiom.
Here's a code sample of what you asked:
let rec nTimes n f x =
if n = 0 then
x
else
nTimes (n-1) f (f x)
let r = nTimes 3 (fun s -> s ^ " is a rose") "A rose"
printfn "%s" r
I like the rule of thumb Paul Graham formulates in On Lisp: if there is work left to do, e.g. manipulating the recursive call output, then the call is not tail recursive.

Resources