The following Alloy model:
sig A {}
run {all a : A | some r : A->A | a.r = a} for 3
run {some a : A | all r : A->A | a.r = a} for 3
fails for both Alloy and Alloy*. If I run both commands using ordinary Alloy (specifically, using the latest build from http://alloy.mit.edu/alloy/download.html, version 4.2_2015-02-22, build date 2015-02-22 18:21 EST), then the first command works fine but the second fails to skolemize:
However, if I run both commands using Alloy* (specifically, using hola-0.2.jar from http://alloy.mit.edu/alloy/hola/), then the first command fails to skolemize and the second command works fine:
Perhaps there is some sort of bug here? I thought such problems were supposed not to happen in Alloy*; indeed, the Alloy* paper states that it "allows higher-order quantifiers to appear anywhere".
Version 0.3 should work correctly.
Related
I'm trying to run a .ml script, test.ml, using the command ocaml and use a module, template.ml, that I setup.
Currently, I know that I can run ocaml using the module by doing ocaml -init template.ml and that I can run a script using ocaml test.ml.
I'm trying to run the script, test.ml, and use the module, template.ml.
I have tried using ocaml test.ml with the first line being open Template ;;after compiling template with ocamlopt -c template.ml. Template is undefined in that case.
I have also tried using ocaml -init template.ml test.ml with and without open Template ;; as the first line of code. They don't work or error respectively.
First, the open command is only for controlling the namespace. I.e., it controls the set of visible names. It doesn't have the effect (as is often assumed) of locating and making a module accessible. (In general you should avoid over-using open. It's never necessary; you can always use the full Module.name syntax.)
The ocaml command line takes any number of compiled ocaml modules followed by one ocaml (.ml) file.
So you can do what you want by compiling the template.ml file before you start:
$ ocamlc -c template.ml
$ ocaml template.cmo test.ml
Here is a fully worked example with minimal contents of the files:
$ cat template.ml
let f x = x + 5
$ cat test.ml
let main () = Printf.printf "%d\n" (Template.f 14)
let () = main ()
$ ocamlc -c template.ml
$ ocaml template.cmo test.ml
19
For what it's worth I think of OCaml as a compiled language rather than a scripting language. So I usually compile all the files and then run them. Using the same files as above, it looks like this:
$ ocamlc -o test template.ml test.ml
$ ./test
19
I only use the ocaml command when I want a to interact with an interpreter (which OCaml folks have traditionally called the "toplevel").
$ ocaml
OCaml version 4.10.0
# let f x = x + 5;;
val f : int -> int = <fun>
# f 14;;
- : int = 19
#
I'm fairly new to NixOS, and am trying to invoke emacs from a Haskell program using the following function:
ediff :: String -> String -> String -> IO ()
ediff testName a b = do
a' <- writeSystemTempFile (testName ++ ".expected") a
b' <- writeSystemTempFile (testName ++ ".received") b
let quote s = "\"" ++ s ++ "\""
callCommand $ "emacs --eval \'(ediff-files " ++ quote a' ++ quote b' ++ ")\'"
When I run the program that invokes this command using stack test, I get the following result (interspersed with unit test results):
/bin/sh: emacs: command not found
Exception: callCommand: emacs --eval '(ediff-files "/run/user/1000/ast1780695788709393584.expected" "/run/user/1000/ast4917054031918502651.received")'
When I run the command that failed to run above from my shell, it works flawlessly. How can I run processes from Haskell in NixOS, as though I had invoked them directly, so that they can access the same commands and configurations as my user?
Both your shell and callCommand use the PATH environment variable, so it seems like stack is changing that. It turns out that stack uses a pure nix shell by default, but you also want to access your user environment, which is 'impure'.
To quote the stack documenation
By default, stack will run the build in a pure Nix build environment (or shell), which means the build should fail if you haven't specified all the dependencies in the packages: section of the stack.yaml file, even if these dependencies are installed elsewhere on your system. This behaviour enforces a complete description of the build environment to facilitate reproducibility. To override this behaviour, add pure: false to your stack.yaml or pass the --no-nix-pure option to the command line.
Another solution is to add Emacs to nix.dependencies in stack.yaml (thanks #chepner). It has the benefit that some version of Emacs will always be available when a developer runs the tests, but that Emacs may not be the Emacs they want to use. You may be able to work around that using something like ~/.config/nixpkgs/config.nix, unless they have configured their Emacs elsewhere, like the system configuration or perhaps a home manager. I'd prefer the simple but impure $PATH solution.
Previously I used ghc version < 8 on Linux and when I had a script in a file, say file.hs, like
let x = "hello"
putStrLn x
double x=2*x
print $ double 2
double 3
then it was possible to run it and get the outputs in a terminal by doing
ghc -e ':script file.hs'
Now I'm using ghc 8.0.1 on Windows and this does not work anymore. Is there another way ?
I can get the outputs if I open GHCi and type :script file.hs. But I want these outputs in the terminal.
I don't know whether this is due to the upgrade of ghc or to the OS.
This works with double quotes:
ghc -e ":script file.hs"
This question already has an answer here:
Can I get warnings about overly-restrictive type signatures?
(1 answer)
Closed 9 years ago.
Is there some automated tool that will find type signatures in my code that are too specific? For a contrived example let's say I write
add3 :: Int -> Int
add3 = (+ 3)
Is there some program I could run (say, "checkSingatures foo.hs") that would tell me that I could have written
add3 :: Num a => a -> a
add3 = (+ 3)
I wouldn't think this would be too hard--strip out the type signatures and see what GHCi infers.
While I am not directly aware of such a tool, it would be maybe something interesting to have (and maybe you could suggest this to the hlint maintainer as an addition). But to your question I can at least give you a "starting point", actually a shell script, that could help you a bit.
#!/bin/sh
sourceFile=$1
tempFile="`mktemp`.hs"
originalTypes=`mktemp`
inferedTypes=`mktemp`
ghc -fno-code -fforce-recomp -ddump-types $sourceFile 2>&1 | sed -n '/^TYPE/,/^TYPE/{/^TYPE/!p}' > $originalTypes
cat $sourceFile | grep -P -v "\s+.*?\s+::" > $tempFile
ghc -fno-code -fforce-recomp -ddump-types $tempFile 2>&1 | sed -n '/^TYPE/,/^TYPE/{/^TYPE/!p}' > $inferedTypes
diff $originalTypes $inferedTypes
Of course it doesn't handle well multiline definitions (and maybe many other cases), but it shows you that you can get in a scriptable fashion the inferred types via the -ddump-types directive.
The cmdArgs package for Haskell provide command option parsing.
based on this page from the docs http://hackage.haskell.org/packages/archive/cmdargs/0.10.3/doc/html/System-Console-CmdArgs-Explicit.html#g:4 and its source http://hackage.haskell.org/packages/archive/cmdargs/0.10.3/doc/html/src/System-Console-CmdArgs-Explicit-Complete.html#Complete
It seem able to support bash completion, but I was not able to made it work with the Implicit version of the parser. http://hackage.haskell.org/packages/archive/cmdargs/0.10.3/doc/html/System-Console-CmdArgs-Implicit.html
Does any one have any example of doing this?
Edit added a better example
if I have the program
{-# LANGUAGE DeriveDataTypeable #-}
import System.Console.CmdArgs
data Sample = Sample {hello :: String}
deriving (Show, Data, Typeable)
sample = Sample{hello = def}
main = print =<< cmdArgs sample
with parses the following options
The sample program
sample [OPTIONS]
Common flags:
-h --hello=ITEM
-? --help Display help message
-V --version Print version information
how do use the bash completion feature of cmdArgs?
To use the bash completion, compile the above program as sample, place sample on your $PATH then run:
sample --help=bash > sample.comp
source sample.comp
You can now type in sample --ver, press tab, and it will complete to sample --version.
There are a couple of infelicities in the completion, in particular the program must be on your $PATH and if you are on Windows you need to run sample.comp through dos2unix. It is also entirely undocumented, which sHould be fixed by the package author.