Top-level custom printing for GADTs: interface change in 4.02.2

[vicuna]

Original bug ID: 6908
Reporter: @yallop
Status: closed (set by @damiendoligez on 2015-07-20T13:15:02Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.2
Target version: 4.02.3+dev
Fixed in version: 4.02.3+dev
Category: ~DO NOT USE (was: OCaml general)
Related to: #5958
Monitored by: @gasche @diml @hcarty

Bug description

PR5958 changed the behaviour of #install_printer to make it possible to install printers for parameterised types. Unfortunately the change has broken some existing code for printing GADTs.

For example, if I have the following GADT definition

type (_, _) eql = Refl : ('a, 'a) eql

then the following printer works with #install_printer in 4.02.1, but is rejected in 4.02.2:

let format_eql : 'a 'b. Format.formatter -> ('a, 'b) eql -> unit =
fun fmt _ -> Format.pp_print_string fmt "reflexivity"

and the following printer works with #install_printer in 4.02.2 but is rejected in 4.02.1:

let format_eql : 'a 'b.
(Format.formatter -> 'a -> unit) ->
(Format.formatter -> 'b -> unit) ->
Format.formatter -> ('a, 'b) eql -> unit =
fun _ _ fmt _ -> Format.pp_print_string fmt "reflexivity";;

This is a problem in practice. For example, top-level printing no longer works in ctypes, which installs a number of printers of the first form:

https://github.com/ocamllabs/ocaml-ctypes/blob/cfb72eeb/src/ctypes-top/ctypes_printers.mli#L10

File attachments

• patch

[vicuna]

Comment author: @gasche

I see no better solution than making the directive code more clever to detect types that (1) have type parameters but (2) do not expect printers for those parameters, and use the old behavior on those.

Maybe we could generalize this to accept that only a subset of the parameters expect printers (synthesizing printers does not make sense for phantom or even contravariant parameters). But a first goal should be to have a safe patch that solve ctypes immediate problem.

[vicuna]

Comment author: hnrgrgr

Attached is a simple patch that should restore the compatibility.

[vicuna]

Comment author: @gasche

Would it be possible to have tests for the expected behavior(s) in the testsuite, for example a new file tests/tool-toplevel/install_printer.ml?

[vicuna]

Comment author: @yallop

Thanks for the quick response! The patch works for me.

[vicuna]

Comment author: @yallop

Another data point: the interface change is also incompatible with the code-printing function in MetaOCaml, which has the following type:

val print_code : Format.formatter -> 'a code -> unit

[vicuna]

Comment author: @damiendoligez

I have a question about the patch: it looks like the comment is not true any more? If this is the case, it should be removed.

[vicuna]

Comment author: @damiendoligez

I have removed the comment and applied the patch to 4.02 (rev. 16221).