I have problem with n+k pattern.
I want to enable it, but i don't know how.
I have added {-# LANGUAGE NPlusKPatterns #-} at the beggining of my .hs file, but it didn't work.
Also I try typping in my ghci console -NPlusKPatterns but is just gives me errors.
You need to type
:set -XNPlusKPatterns
in ghci to enable them.
For completeness I'll point out that if you load ghci from the command prompt instead of running winghci, you can load it with ghci -XNPlusKPatterns instead of interactively doing :set -XNPlusKPatterns.
You can check whether it's working by defining an n+k pattern interactively. Here's an example session:
Prelude> let fact 0 = 1; fact (n+1) = (n+1)*fact n in fact 5
<interactive>:8:23: Parse error in pattern: n + 1
Prelude> :set -XNPlusKPatterns
Prelude> let fact 0 = 1; fact (n+1) = (n+1)*fact n in fact 5
120
Related
My goal is to pipe some steps for ghci to run from a bash script and then exit cleanly. The commentary online says to use runhaskell for this.
This is the command I'm trying to run:
ghci> import System.Random
ghci> random (mkStdGen 100) :: (Int, StdGen)
With expected result similar to:
(-3633736515773289454,693699796 2103410263)
When I drop this into a file randomtest.hs and execute it with runhaskell I get the following error:.
randomtest.hs:3:1: error:
Invalid type signature: random (mkStdGen 100) :: ...
Should be of form <variable> :: <type>
I need a hint to go in the right direction.
My question is: Why does ghci behave differently to runHaskell?
ghci is a REPL (Read, Eval, Print Loop). However, runhaskell is nearly the same as compiling a program into an executable, and then running it. GHCI lets us run individual functions and arbitrary expressions, wheras runhaskell just calls the main function and interprets the file, instead of compiling it, and running that.
As #AJFarmar points out, GHCI is best used to debug and test a program you're building, whilst runhaskell is a nice way to run a whole program without having to compile.
So, to fix your issue, we just need to give the program a main function. ghci calls print on the result of every expression which is typed into the interpreter and not bound to a variable.
So, our main function can just be:
main = print (random (mkStdGen 100) :: (Int, StdGen))
We still need to import System.Random, so the whole file becomes:
import System.Random
main = print (random (mkStdGen 100) :: (Int, StdGen))
Then, we can run as expected:
[~]λ runhaskell randomtest.hs
(-3633736515773289454,693699796 2103410263)
If we want to multiple commands from runhaskell we can just add more to a do block in main:
import System.Random
main = do
print (random (mkStdGen 100) :: (Int, StdGen))
let x = 5 * 5
print x
putStrLn "Hello world!"
I'm writing a language interpreter in Haskell, and for the most part it works (hooray!). But some of the tests fail in an odd way that depends on whether stdout is sent to the terminal or a pipe...
I'm using tasty-golden to test the REPL. There are text files with pasted REPL sessions like this:
Welcome to the ShortCut interpreter!
Type :help for a list of the available commands.
shortcut >> v1 = "one"
shortcut >> v2 = "two"
shortcut >> v3 = [v1, v2]
shortcut >> :show
v1 = "one"
v2 = "two"
v3 = [v1, v2]
shortcut >> :rdepends v1
v3 = [v1, v2]
shortcut >> :quit
Bye for now!
I have a function that reads those files and splits them into user input (anything after shortcut >>) and what the program should print to stdout. It passes the input lines to the REPL, captures stdout using the silently package, intercalates them, and checks that the combined output is the same as that file.
Everything works, but only if I pipe the overall program output through less! When printing directly to the terminal, certain lines slip through and are actually printed, then the tests fail because they aren't part of the captured output.
I think it might be a bug in the interaction between Tasty and Silently, which both do fancy things with terminal output, but have no idea how to debug it or write a reproducible example.
Here's the complete output run in three different ways:
Copied directly from the terminal
Piped through less and copied from the terminal
Piped through tee and copied from the resulting file
As you can see:
Each FAIL is preceded by printing part of the REPL output to the terminal instead of capturing it
less somehow gets around that and the tests pass
tee misses the printed bits (they end up in terminal but not the file)
Any ideas about what could be going on? I can post any parts of the code you think might be relevant, but didn't want to muddy the question with hundreds and hundreds of mostly-unrelated lines.
Update: tried replacing Silently's hCapture_ with this function from another question:
catchOutput :: IO () -> IO String
catchOutput action = do
tmpd <- getTemporaryDirectory
(tmpf, tmph) <- openTempFile tmpd "haskell_stdout"
stdout_dup <- hDuplicate stdout
hDuplicateTo tmph stdout
hClose tmph
action
hDuplicateTo stdout_dup stdout
str <- readFile tmpf
removeFile tmpf
return str
Unfortunately it does the same thing.
Update 2:
Well, figured it out. Sorry for everyone who tried to puzzle through it, as I don't think I gave enough information! The bug was in my REPL monad, which was defined like this:
type ReplM a = StateT CutState (MaybeT (InputT IO)) a
runReplM :: ReplM a -> CutState -> IO (Maybe CutState)
runReplM r s = runInputT defaultSettings $ runMaybeT $ execStateT r s
prompt :: String -> ReplM (Maybe String)
prompt = lift . lift . getInputLine
print :: String -> ReplM ()
print = lift . lift . outputStrLn
I noticed that all the erroneous prints came from functions that use print, whereas a couple cases where I used liftIO . putStrLn instead worked as expected. So I just redefined print as that:
print :: String -> ReplM ()
print = liftIO . putStrLn
I still don't really get why the other version didn't work though, so I'll give the answer to whoever can explain it. outputStrLn is defined in Haskeline.hs.
See Tcl 8.4 code below and shell output below: (I need meta- coding):
% set k a
% set m k
% puts [set $m ]
a
% puts [subst $$m]
a
So, it appear that set $m and subst $$m have the same functionality. However, the runtime (in the simple testcase) is rather different (see continuation of shell results below:
% time { set $m } 1000000
0.256435 microseconds per iteration
% time { subst $$m } 1000000
0.627714 microseconds per iteration
As can be seen, set is ~2.5 faster than subst. 2 questions are: to be asked:
1. Why?
2. I have seen that it is ~3.6 faster in Tcl 8.5. Can we expect that this will remain the case, in future releases?
Thanks
You can expect things to remain exactly the same. When you use:
puts [set $m]
Tcl will compile that once to a read of the m variable (storing the result on the internal operation stack) a read of the variable whose name is on the operation stack, and then a call of puts with the result.
When you do:
puts [subst $$m]
Tcl compiles that to a concatenation of $ and the results of reading m, a call to the substitution engine (which in turn will parse and bytecode compile that fragment) and only then a puts of the result. Which is entirely more complicated.
You'd see the difference if you did:
set m {k[exit]}
The first would just tell you that you were trying to read from a (strangely-named) variable that didn't exist. The second would quit the process.
I am new to Clojure and want to debug a Clojure file abc.clj that will take user arguments. To run the file, i will do
lein run [arg1 arg2 ..]
I have tried emacs-cider and lighttable, but haven't found a way to input user argument from the beginning.
Maybe you can try the Debux library, and use your REPL to observe results. Seems to me that Clojure is really about the REPL and interactive development.
If I understand what you're trying to do, you should be able to sprinkle debug macros (dbg) throughout your code, then run your code with whatever changes to your args. The various results from the dbg macros will show in your REPL. I'm not sure if you can do this straight from lein, however.
From the README page:
Basic usage
This is a simple example. The macro dbg prints an original form and
pretty-prints the evaluated value on the REPL window. Then it returns
the value without interfering with the code execution.
If you wrap the code with dbg like this,
(* 2 (dbg (+ 10 20))) ; => 60
the following will be printed in the REPL window.
REPL output:
dbg: (+ 10 20) => 30
This user guide:
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-debugger.html
advertises:
Execution can be single-stepped: the evaluator will suspend execution
approximately after every reduction, allowing local variables to be
inspected. This is equivalent to setting a breakpoint at every point
in the program.
Yet, I can find nothing in the document that tells me how to do that. Under the heading:
2.5.2. Single-stepping
It describes how to step from breakpoint to breakpoint. But I don't want to have to set a breakpoint on every line. Was the advertisement false or is there a way to step through a program line by line?
Thanks.
After having set and reached a breakpoint, you can call :step from the debugger.
There are other single-step possibilities. Typing :help once at a breakpoint would tell you more about what you can do.
Okay, I figured it out:
ghci> :step function_name arg1 arg2
...
...
ghci> :step
...
...
ghci> :step
If you forget the function arguments, then you will get the cryptic error message:
<interactive>:138:1:
No instance for (Show (String -> Double))
arising from a use of `print'
Possible fix:
add an instance declaration for (Show (String -> Double))
In a stmt of an interactive GHCi command: print it
...which might lead you to tear your hair out. And if you want to skip to the end:
ghci> :continue