# Deriving Core\_kernel.Hashtbl **URL:** \ **Category:** Learning\ **Created:** [April 16, 2019, 9:37am UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667 "2019-04-16T09:37:11Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Leandros](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/leandros/32/1452_2.png) [@Leandros](https://discuss.ocaml.org/u/Leandros)\ **Post date:** [April 16, 2019, 9:37am UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/1 "2019-04-16T09:37:11Z")
I’d like to put a hashtable inside a struct which is comparable (via `[@@deriving eq]`), in v2 of Real World OCaml I found that I can use the `.M` functor to create a new module which I can derive: ```auto type string_int_map = int Map.M(String).t ``` which is more or less equivalent to the more common ```auto type string_int_map = (string, int) Map.t ``` However, if I try the same with a `Hashtbl`: ```auto type string_int_table = int Hashtbl.M(String).t [@@deriving eq] ``` I get the following error: ```auto File "_none_", line 1: Error: broken invariant in parsetree: Functor application not allowed here. ``` Removing the `[@@deriving eq]` fixes is, and I get the expected error: ```auto File "_none_", line 1: Error: Unbound value equal_string_int_table ``` So, my question is, how can I convince ppx\_deriving to correctly derive the module? ---
**Author:** ![emillon](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/emillon/32/1206_2.png) [@emillon](https://discuss.ocaml.org/u/emillon)\ **Post date:** [April 16, 2019, 2:04pm UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/3 "2019-04-16T14:04:53Z")
This looks like a bug in `ppx_deriving.eq`. It generates the following piece of code: ```ocaml let rec equal : t -> t -> Ppx_deriving_runtime.bool = let __0 () = Hashtbl.Make(M).equal in ... ``` and this is not valid OCaml. More precisely, it’s building an AST that does not correspond to an actual program. `ppx_deriving` could detect that and give a better error message. As for your program, it might help to give a name to the module: ```ocaml module StringHashtbl = Hashtbl.M(String) type string_int_table = int StringHashtbl.t [@@deriving eq] ``` That should work if there’s an `equal` function in the output of this functor. ---
**Author:** ![ivg](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/ivg/32/103_2.png) [@ivg](https://discuss.ocaml.org/u/ivg)\ **Post date:** [April 16, 2019, 3:15pm UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/4 "2019-04-16T15:15:34Z")
First of all, it [should be](https://github.com/janestreet/ppx_compare) `equal` not `eq`. Second, it all depends on a version of the JS suite that you’re using, as well as whether you’re using `Base`, or `Core_kernel`, or `Core`. For example, for the v0.11 version, the following works ```ocaml type t = int Base.Map.M(Int).t [@@deriving compare] ``` The `[@@deriving equal]` variant will not work, as it was added rather recently. Not sure when, they do not not update their changelogs. Note, that the following ```auto open Core_kernel type t = int Map.M(Int).t [@@deriving compare] ``` will work only after v0.12. Concerning the hash tables, for v0.11 the following doesn’t work: ```ocaml type t = int Base.Hashtbl.M(Int).t [@@deriving compare] Error: Unbound value Base.Hashtbl.compare_m__t ``` Not sure, whether it is already fixed in v0.12. To summarize, currently the functorial interfaces, albeit being a really nice idea, do no work with ppx\_derivers, but the support is slowly coming. ---
**Author:** ![bcc32](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bcc32/32/203_2.png) [@bcc32](https://discuss.ocaml.org/u/bcc32)\ **Post date:** [April 16, 2019, 3:40pm UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/5 "2019-04-16T15:40:13Z")
`ppx_compare` support for maps is available since v0.12, with `ppx_bin_prot` coming soon. `ppx_compare` for hash tables, and in fact `Hashtbl.compare`/`Int.Table.compare` do not exist, and probably won’t be added. If you’re using a hash table as a key for some data structure, you’re probably making a mistake 🙂 ---
**Author:** ![Leandros](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/leandros/32/1452_2.png) [@Leandros](https://discuss.ocaml.org/u/Leandros)\ **Post date:** [April 16, 2019, 3:56pm UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/6 "2019-04-16T15:56:07Z")
You’re thinking about ppx\_compare. This was using ppx\_deriving, which is clearly showing `eq`, not `equal`: [https://github.com/ocaml-ppx/ppx\_deriving#plugins-eq-and-ord](https://github.com/ocaml-ppx/ppx_deriving#plugins-eq-and-ord). ---
**Author:** ![Leandros](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/leandros/32/1452_2.png) [@Leandros](https://discuss.ocaml.org/u/Leandros)\ **Post date:** [April 16, 2019, 3:57pm UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/7 "2019-04-16T15:57:53Z")
Ahh, that’s it. This does in fact work (with the only problem, that the functor does not include an `equal` function). My solution was to implement the derived function myself, which was reasonably simple: ```auto let equal_string_int_table a b = Hashtbl.equal a b Int.(=) ``` ---
**Author:** ![ivg](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/ivg/32/103_2.png) [@ivg](https://discuss.ocaml.org/u/ivg)\ **Post date:** [April 16, 2019, 4:01pm UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/8 "2019-04-16T16:01:23Z")
> [@Leandros](#): > > You’re thinking about ppx\_compare. This was using ppx\_deriving, which is clearly showing `eq` , not `equal` Yep, that’s what I was saying, maybe in a slightly contracted form. You shall use `equal` because you need to use `ppx_compare` from the ppx\_jane suite, not ppx\_deriving, which will be triggered by using the `eq` deriver. The support of `X.M(T).t` doesn’t come automatically, it is a special convention in the Janestreet suite of libraries. So, for it to work, you need to use the derivers that are aware of such convention. ---
**Author:** ![Yaron\_Minsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/yaron_minsky/32/11_2.png) [@Yaron\_Minsky](https://discuss.ocaml.org/u/Yaron_Minsky)\ **Post date:** [April 16, 2019, 9:56pm UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/9 "2019-04-16T21:56:18Z")
> [@ivg](#): > > The `[@@deriving equal]` variant will not work, as it was added rather recently. Not sure when, they do not not update their changelogs. This is a fair criticism, but we are working on it. We’re now incrementally creating public-facing changelogs as we go, so the quality of changelogs for the next stable release should be a lot better. We did publish a changelog on discuss, which does include mention of `[@@deriving equal]`: > [@\[ANN\] v0.12 release of Jane Street packages](https://discuss.ocaml.org/t/ann-v0-12-release-of-jane-street-packages/3499): > > Dear OCaml developers, We are happy to announce the v0.12 release of Jane Street packages! This release comes with a lot of changes, as we ship 19 new packages, and have enhanced and refactored a number of existing ones. The documentation for this release is available on our website: [https://ocaml.janestreet.com/ocaml-core/v0.12/doc/](https://ocaml.janestreet.com/ocaml-core/v0.12/doc/) The remainder of this mail highlights the main changes since the v0.11 release; we hope it will be useful to developers in the process of migrating to the … ---
**Author:** ![Leandros](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/leandros/32/1452_2.png) [@Leandros](https://discuss.ocaml.org/u/Leandros)\ **Post date:** [April 17, 2019, 8:08am UTC](https://discuss.ocaml.org/t/deriving-core-kernel-hashtbl/3667/10 "2019-04-17T08:08:29Z")
Alright, now I’ve understood it. Thank you!