1/Thank you for your clear opinion about the features of JS Base/Core. Polymorphism is/was a real source of unpredictable issues (just have to see the message of the compiler when it fails!)
As @perry mentioned, the documentation web site for Core is awful, and it would be appreciated to be in phase with the ambition of JS team and their impressive work to improve OCaml “coding safety”.
/
2/ Regarding the simple case with List.mem, I used exactly your code and (within Emacs) got the same Error “Unbound module Core_kernel” (or already described type error).
I used the shell to compile with dune and it failed:
$ dune build test.exe
File “test.ml”, line 8, characters 5-16:
Error: Unbound module Core_kernel
Obviously, I forgot to mention core_kernel in packages. I admit here that mistake assuming it can help other people being aware of dune (formerly jbuilder) requirements.
I could compile correctly from the shell without any error or warning after fixing dune file as follows:
$ cat dune
(executable
(name test)
(libraries core_kernel))
So:
good source file (edited with nano, gedit or Emacs…) and good dune file => good compilation
BTW, it raises the subject of the process for safely editing OCaml code:
We must first define all required dependencies (on paper or in our mind), then we must realize that by editing the dune file AND use open directives in the source file. This is redundant and error-prone (things are changing and it’s possible to forget something).
How can we setup dune so it generate packages dependencies in dune file from open directives in source file (as unique specification of package dependencies)?
BTW2 regarding dune and merlin
When we are incited to edit .merlin file to tell it where to look for its prediction, in fact this .merlin file is now generated by dune as soon as we use it to compile source code (so any manual .merlin configuration file is erased and replaced by dune generated text).
Now coming back to Emacs, it’s hell again:
Emacs displays an exclamation mark besides open Core_kernel (or open Core).
When doing Tuareg/Evaluate Buffer, now it displays the correct answer with or without the open Core directive (even with new Ocaml
Tuareg/Evaluate Buffer:
Tuareg/Evaluate Phrase:
let m = List.mem [1; 2] 1 ~equal:Int.equal;; val m : bool = true
Formely it told the type error I’ve already described in my first post.
I even tried to use dune to modify .merlin to see if it has an influence. It hasn’t.
So the issue seems in fact to be Setting up a consistent and efficient OCaml dev environment (with Emacs) .
Because we are not all old/expert OCaml programmers used to Emacs-vi-tuareg-merlin-etc. in the dark!
What is your ~/.emacs file and emacs configuration (auto-complete, etc.) so you can edit Ocaml code, see it’s type, check if it’s compile, send it to the interpreter; compile it, debug it?
What are your other settings out of Emacs in addition to the dune file? (in ~/.ocamlinit or in other files)
PS1 :
I tried with Int.equal instead of (=). It works in this case with integers. This monomorphic vs. polymorphic discussion is not the issue.
PS2 :
Having a look at topfind messages (with RWO recommended ~/.ocamlinit), I saw just one error message regarding ocamltoplevel.cma:
/home/lm/.opam/4.06.1/lib/ocaml/compiler-libs/ocamltoplevel.cma: loaded
Exception:
Invalid_argument
“The ocamltoplevel.cma library from compiler-libs cannot be loaded inside the OCaml toplevel”.
Could that somehow explain the present issue?
How to fix that load issue?
Pls. notice that ocaml-top clearly display this Exception after the bunch of “load & added to search path” when ocaml toplevel doesn’t (within Emacs or not). It helped me to see it.
Thanks