I'm reading the Haskell book : http://learnyouahaskell.com/types-and-typeclasses
When I enter this line in the interpreter,
removeNonUppercase st = [c | c <- st, c `elem` ['A' .. 'Z']]
I get this error:
parse error on input `='
Whats causing this error ?
When defining variables or functions in the interpreter or in a GHCi script file (i.e. not a Haskell module), you need to use the let keyword.
> let removeNonUppercase st = [c | c <- st, c `elem` ['A' .. 'Z']]
This is because the interpreter essentially acts as if you were in a global do-block. Your code would be OK as-is in a Haskell source file.
If you got this error outside the interpreter, you probably either messed up the indentation, or you have some other syntax error in nearby code.
Related
I am getting this compile error:
Files.hs:47:17: parse error on input ‘->’
Failed, modules loaded: none.
In the following section of code:
main :: IO ()
main = do
args <- getArgs
let f = case args of
("W":_) -> eoltoW
-- ^ here's 47:17
("U":_) -> eoltoU
_ -> fail "2 - 3 arguments required"
case args of
[_,i,o] -> editWith f i o
[_,i] -> catWith f i
[_] -> fail "2 - 3 arguments required"
While I understand the logic could use some tidying up, I do not see where I am going wrong with case syntax. I figure it might be some weird interaction with do and let, but I can't find any clue as to how to correct it.
Note, I have ensured that I only use spaces for indentation
Edit:
It seems that adding a single space further of indentation (as below) is sufficient to prevent the error, but I am unclear as to why.
main = do
args <- getArgs
let f = case args of
("W":_) -> eoltoW
-- ^ here's 47:17
("U":_) -> eoltoU
_ -> fail "2 - 3 arguments required"
This is described in 2.7 and 10.3. Basically, the rule for let … in a do block* is that all bindings have to be indented the same way:
let a = …
b = …
c = …
Furthermore, the "…" have to be more indented than the layout list. For example, the following is a syntax error:
let a =
10
in a
In order to create a new layout-list, we need to indent it further (see note 1 in section 10.3), which is why
let a =
10
in a
is completely fine. The same holds for your case. All of the cases have to be further indented than f due to the off-side rule.
* that rule actually holds** for more, i.e. for let, where, do and of.
** well, as long as you don't introduce additional braces
I created a new quick.hs file in the ghci.exe directory. And the content is
quicksort::(Ord a)=>[a]->[a]
quicksort []=[]
quicksort (x:xs)=
let smaller = [a |a<-xs,a<=x]
larger = [a |a<-xs,a>x]
in quicksort smaller ++ [x] ++ quicksort larger
When I issue :l quick in the ghci command lline, the output is
Prelude> :l quick
[1 of 1] Compiling Main ( quick.hs, interpreted )
quick.hs:5:17: error:
parse error on input ‘=’
Perhaps you need a 'let' in a 'do' block?
e.g. 'let x = 5' instead of 'x = 5'
Failed, modules loaded: none.
I have concured this kind of problems many times. What's wrong on earth?
You say in the comments that you are sure there are no tab characters in the source file, but inspecting the source of your question, indeed there is one right before the in token. Replace that with the appropriate number of spaces and you'll be all good.
You have to remove all tabs and change it by spaces. I hope that this instruction helps you.
I am trying to use hint package from hackage to create a simple environment where user can issue lines of code for evaluation (like in ghci). I expect some of the input lines to be erroneous (eval would end the session with an error). How can I create a robust session that ignores erroneous input (or better: it reports an error but can accept other input) and keeps the previously consistent state?
Also, I would like to use it in do style, i.e. let a = 3 as standalone input line makes sense.
To clarify things: I have no problem with a single eval. What I would like to do, is allow continuing evaluation even after some step failed. Also I would like to incrementally extend a monadic chain (as you do in ghci I guess).
In other words: I want something like this, except that I get to evaluate 3 and don't stop at undefined with the error.
runInterpreter $ setImports [ "Prelude" ] >> eval "undefined" >> eval "3"
More specifically I would like something like this to be possible:
runInterpreter $ setImports ... >> eval' "let a = (1, 2)" -- modifying context
>> typeOf "b" -- error but not breaking the chain
>> typeOf "a" -- (Num a, Num b) => (a, b)
I don't expect it to work this straightforwardly, this is just to show the idea. I basically would like to build up some context (as you do in ghci) and every addition to the context would modify it only if there is no failure, failures could be logged or explicitly retrieved after each attempt to modify the context.
You didn't show any code so I don't know the problem. The most straight-forward way I use hint handles errors fine:
import Language.Haskell.Interpreter
let doEval s = runInterpreter $ setImports ["Prelude"] >> eval s
has resulted in fine output for me...
Prelude Language.Haskell.Interpreter> doEval "1 + 2"
Right "3"
Prelude Language.Haskell.Interpreter> doEval "1 + 'c'"
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-apple-darwin):
nameModule doEval_a43r
... Except that now the impossible happens... that's a bug. Notice you are supposed to get Left someError in cases like these:
data InterpreterError
= UnknownError String
| WontCompile [GhcError]
| NotAllowed String
| GhcException String
-- Defined in ‘hint-0.4.2.3:Hint.Base’
Have you looked through the ghchq bug list and/or submitted an issue?
EDIT:
And the correct functionality is back, at least as of GHC 7.10.3 x64 on OS X with hint version 0.4.2.3. In other words, it appears the bug went away from 7.10.2 to 7.10.3
The output is:
Left (WontCompile [GhcError {errMsg = ":3:3:\n No instance for (Num Char) arising from a use of \8216+\8217\n In the expression: 1 + 'c'\n In an equation for \8216e_11\8217: e_11 = 1 + 'c'\n In the first argument of \8216show_M439719814875238119360034\8217, namely\n \8216(let e_11 = 1 + 'c' in e_11)\8217"}])
Though executing the doEval line twice in GHCi does cause a panic, things seem to work once in the interpreter and properly regardless when compiled.
In the code at the bottom, two monadic actions (loadModules and setImportsQ) in Hint (Language.Haskell.Interpreter) can only be executed in one order but not the other, as shown in a minimal example below. In particular, loadModules must go first, or else the following exception will be generated when executing the interpreter.
*** Exception: compile error: WontCompile [GhcError {errMsg = "Not in scope: type
constructor or class `Int'"}]
This behavior seems to have been introduced in Hint 0.4.1.0. I must have missed something obvious..
My first questions is Hint specific: why must loadModules be called before setImportsQ?
My second question is more general: it seems that these two monadic actions do NOT feed input into each other, also the to-be-loaded module is empty, why is the order or execution important at all? This almost reminds me of the imperative world, where you not only have to worry about the input/output, but also the order of certain side effects.
The code is below. Note that MyModule.hs is an empty .hs file.
module Main where
import Language.Haskell.Interpreter
import Control.Monad
custom=["MyModule"] --mymodule.hs is just an empty .hs source file in the same folder
context=[("Data.Int",Nothing)]
main = do
x <- interp ("1") (as ::Int)
return ()
interp e as_type = do
interpreterResult <- runInterpreter $ do
loadModules custom --this line must go first
setImportsQ context --this line must go second
interpret e as_type
f <- case interpreterResult of
Left e -> error $ "compile error: " ++ show e
Right result -> return result
return f
Haskell Stack Overflow layout preprocessor
module StackOverflow where -- yes, the source of this post compiles as is
Skip down to What to do to get it working if you want to play with this first (1/2 way down).
Skip down to What I would like if I witter on a bit and you just want to find out what help I'm seeking.
TLDR Question summary:
Can I get ghci to add filename completion to the :so command I defined in my ghci.conf?
Could I somehow define a ghci command that returns code for compilation instead of returning a ghci command, or
does ghci instead have a better way for me to plug in Haskell code as a
file-extension-specific pre-processor, so :l would work for .hs and .lhs files as usual, but use my handwritten preprocessor for .so files?
Background:
Haskell supports literate programming in .lhs source files, two ways:
LaTeX style \begin{code} and \end{code}.
Bird tracks: Code starts with > , anything else is a comment.
There must be a blank line between code and comments (to stop trivial accidental misuse of >).
Don't Bird tracks rules sound similar to StackOverflow's code blocks?
References: 1. The .ghci manual
2. GHCi haskellwiki
3. Neil Mitchell blogs about :{ and :} in .ghci
The preprocessor
I like writing SO answers in a text editor, and I like to make a post that consists of code that works,
but end up with comment blocks or >s that I have to edit out before posting, which is less fun.
So, I wrote myself a pre-processor.
If I've pasted some ghci stuff in as a code block, it usually starts with * or :.
If the line is completely blank, I don't want it treated as code, because otherwise
I get accidental code-next-to-comment-line errors because I can't see the 4 spaces I accidentally
left on an otherwise blank line.
If the preceeding line was not code, this line shouldn't be either, so we can cope with StackOverflow's
use of indentation for text layout purposes outside code blocks.
At first we don't know (I don't know) whether this line is code or text:
dunnoNow :: [String] -> [String]
dunnoNow [] = []
dunnoNow (line:lines)
| all (==' ') line = line:dunnoNow lines -- next line could be either
| otherwise = let (first4,therest) = splitAt 4 line in
if first4 /=" " --
|| null therest -- so the next line won't ever crash
|| head therest `elem` "*:" -- special chars that don't start lines of code.
then line:knowNow False lines -- this isn't code, so the next line isn't either
else ('>':line):knowNow True lines -- this is code, add > and the next line has to be too
but if we know, we should keep in the same mode until we hit a blank line:
knowNow :: Bool -> [String] -> [String]
knowNow _ [] = []
knowNow itsCode (line:lines)
| all (==' ') line = line:dunnoNow lines
| otherwise = (if itsCode then '>':line else line):knowNow itsCode lines
Getting ghci to use the preprocessor
Now we can take a module name, preprocess that file, and tell ghci to load it:
loadso :: String -> IO String
loadso fn = fmap (unlines.dunnoNow.lines) (readFile $ fn++".so") -- so2bird each line
>>= writeFile (fn++"_so.lhs") -- write to a new file
>> return (":def! rso (\\_ -> return \":so "++ fn ++"\")\n:load "++fn++"_so.lhs")
I've used silently redefining the :rso command becuase my previous attemts to use
let currentStackOverflowFile = .... or currentStackOverflowFile <- return ...
didn't get me anywhere.
What to do to get it working
Now I need to put it in my ghci.conf file, i.e. in appdata/ghc/ghci.conf
as per the instructions
:{
let dunnoNow [] = []
dunnoNow (line:lines)
| all (==' ') line = line:dunnoNow lines -- next line could be either
| otherwise = let (first4,therest) = splitAt 4 line in
if first4 /=" " --
|| null therest -- so the next line won't ever crash
|| head therest `elem` "*:" -- special chars that don't start lines of code.
then line:knowNow False lines -- this isn't code, so the next line isn't either
else ('>':line):knowNow True lines -- this is code, add > and the next line has to be too
knowNow _ [] = []
knowNow itsCode (line:lines)
| all (==' ') line = line:dunnoNow lines
| otherwise = (if itsCode then '>':line else line):knowNow itsCode lines
loadso fn = fmap (unlines.dunnoNow.lines) (readFile $ fn++".so") -- convert each line
>>= writeFile (fn++"_so.lhs") -- write to a new file
>> return (":def! rso (\\_ -> return \":so "++ fn ++"\")\n:load "++fn++"_so.lhs")
:}
:def so loadso
Usage
Now I can save this entire post in LiterateSo.so and do lovely things in ghci like
*Prelude> :so StackOverflow
[1 of 1] Compiling StackOverflow ( StackOverflow_so.lhs, interpreted )
Ok, modules loaded: StackOverflow.
*StackOverflow> :rso
[1 of 1] Compiling StackOverflow ( StackOverflow_so.lhs, interpreted )
Ok, modules loaded: StackOverflow.
*StackOverflow>
Hooray!
What I would like:
I would prefer to enable ghci to support this more directly. It would be nice to get rid of the intermediate .lhs file.
Also, it seems ghci does filename completion starting at the shortest substring of :load that determines
you're actually doing load, so using :lso instead of :so doesn't fool it.
(I would not like to rewrite my code in C. I also would not like to recompile ghci from source.)
TLDR Question reminder:
Can I get ghci to add filename completion to the :so command I defined in my ghci.conf?
Could I somehow define a ghci command that returns code for compilation instead of returning a ghci command, or
does ghci instead have a better way for me to plug in Haskell code as a
file-extension-specific pre-processor, so :l would work for .hs and .lhs files as usual, but use my handwritten preprocessor for .so files?
I would try to make a standalone preprocessor that runs SO preprocessing code or the standard literary preprocessor, depending on file extension. Then just use :set -pgmL SO-preprocessor in ghci.conf.
For the standard literary preprocessor, run the unlit program, or use Distribution.Simple.PreProcess.Unlit.
This way, :load and filename completion just work normally.
GHCI passes 4 arguments to the preprocessor, in order: -h, the label, the source file name, and the destination file name. The preprocessor should read the source and write to the destination. The label is used to output #line pragmas. You can ignore it if you don't alter the line count of the source (i.e. replace "comment" lines with -- comments or blank lines).