Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005888OCamlOCaml typingpublic2013-01-13 18:462013-02-07 04:31
Reporteredwin 
Assigned Togarrigue 
PrioritynormalSeveritytweakReproducibilityhave not tried
StatusacknowledgedResolutionopen 
PlatformLinuxOSDebian GNU/LinuxOS Versionwheezy
Product Version4.00.1 
Target VersionFixed in Version 
Summary0005888: Better type errors for polymorphic variants and module signatures
DescriptionML discussion: https://sympa.inria.fr/sympa/arc/caml-list/2013-01/msg00023.html [^]

I'm fine with how the language works, but the type error generated by the compiler could be improved, currently it only tells me that the values do not match.

Attached is an example patch that implements some improved type error messages.

With polymorphic types it may not be immediately obvious what is wrong, so it'd be good if the compiler would be more explicit about the error.
It already gives helpful hints when polymorphic types lack a tag or the tags' type do not match. Unfortunately when module signatures are checked it doesn't
even give those errors.
Steps To Reproducemodule Bad3 : sig
  val copy: [< `A of a | `B of a ] -> [< `A of a | `C of a] -> unit
end = struct
  let generic (a: [< `A of a | `B of a]) (b: [< `A of a | `C of a]) = ()
  let specific a b = false
  let copy a b = match a, b with
  | `A x, `A y ->
      if not (specific (`A x) (`A y)) then
        generic a b
  | _, _ ->
      generic a b
end

Error: Signature mismatch:
       ...
       Values do not match:
         val copy :
           [< `A of a | `B of a > `A ] -> [< `A of a | `C of a > `A ] -> unit
       is not included in
         val copy : [< `A of a | `B of a ] -> [< `A of a | `C of a ] -> unit
Additional InformationWould be good to have more detailed errors for:
 - module signature vs implementation: inspect arrows,tuples, etc. and report
 exactly what causes the type error (like it is already done when signatures are not invovled)
 - mandatory vs optional tags in polymorphic variants: [< `A] vs [> `A]
 - tuples with different lengths
 - different order of function parameter labels

Would also good to have (I didn't implement it):
 - origin/trace of type inference (i.e. wildcard match case, etc.)
 - remove "impossible" tags (i.e. `A of string&int or `A of <empty-poly-variant-type>) when expanding types in error messages
 - warn when intersection of polymorphic variants is empty, i.e. [< `A of [< `B] & [< `C]) or [< `A of string&int], etc.

I've attached 3 patches, and also a combined diff of the 3 patches. There are probably easier/more elegant ways to implement it, consider them a draft.
Also I've only updated testsuite/tests/typing-misc, some of the others might have to be updated in light of the new error messages.


Also please improve the documentation using the very good explanations/examples by Leo White and Jacques Garrigue, in particular the part about
why [> `A] is inferred for matches with wildcard branches:

http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual006.html#toc36 [^]
http://caml.inria.fr/pub/docs/manual-ocaml-4.00/types.html#polymorphic-variant-type [^]
https://sympa.inria.fr/sympa/arc/caml-list/2013-01/msg00019.html [^]
https://sympa.inria.fr/sympa/arc/caml-list/2013-01/msg00019.html [^]

Note: the manual006.html#toc36 should probably have a link to types.html#polymorphic-variant-type.
TagsNo tags attached.
Attached Filespatch file icon better-type-errors-unified.patch [^] (17,024 bytes) 2013-01-13 18:46 [Show Content]
patch file icon 0001-Propagate-details-about-type-unification-error-for-m.patch [^] (12,001 bytes) 2013-01-13 18:46 [Show Content]
patch file icon 0002-Better-type-error-reporting-for-polymorphic-variants.patch [^] (66,620 bytes) 2013-01-13 18:47 [Show Content]
patch file icon 0003-Improve-type-error-messages-when-dealing-with-labels.patch [^] (5,686 bytes) 2013-01-13 18:47 [Show Content]
patch file icon 0004-Fix-order-of-types-in-message.patch [^] (2,907 bytes) 2013-01-13 18:56 [Show Content]
? file icon temp1.ml [^] (35,866 bytes) 2013-02-07 04:30

- Relationships
related to 0005889new polymorphic variant typing error message not meaningful 

-  Notes
(0008817)
garrigue (manager)
2013-02-04 11:20

These are interestinf improvements.
However, after a few hours trying to merge this properly, I've come to the conclusion that the current trace-based approach is very hard to adapt to different kinds of errors. It is easy to make something that kind of works, but they are just too many different cases to handle.
I'm now seriously thinking about completely changing this in the spirit of what is done for module types, which should allow better error messages for all situations.
(0008822)
hongboz (developer)
2013-02-07 04:31

Hi Jacques, I attached a type got in toplevel (tmp1.ml) which I hope the toplevel can suppress printing such types(default option). The type signature inferred can be simplified by type annotations, but sometimes I hope that if the compiler find a very big type, it can be a little smart that it does not print it to scare users. (There are very good reasons for using polymorphic variants in my project).
Thanks!

- Issue History
Date Modified Username Field Change
2013-01-13 18:46 edwin New Issue
2013-01-13 18:46 edwin File Added: better-type-errors-unified.patch
2013-01-13 18:46 edwin File Added: 0001-Propagate-details-about-type-unification-error-for-m.patch
2013-01-13 18:47 edwin File Added: 0002-Better-type-error-reporting-for-polymorphic-variants.patch
2013-01-13 18:47 edwin File Added: 0003-Improve-type-error-messages-when-dealing-with-labels.patch
2013-01-13 18:56 edwin File Added: 0004-Fix-order-of-types-in-message.patch
2013-01-13 22:41 meyer Relationship added related to 0005889
2013-02-04 11:20 garrigue Note Added: 0008817
2013-02-04 11:20 garrigue Assigned To => garrigue
2013-02-04 11:20 garrigue Status new => acknowledged
2013-02-07 04:30 hongboz File Added: temp1.ml
2013-02-07 04:31 hongboz Note Added: 0008822


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker