0005347: Make tuple expression type errors more specific

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0005347

OCaml

OCaml general

public

2011-08-24 23:18

2012-06-01 09:10

Reporter

bartjacobs

Assigned To

garrigue

Priority

normal

Severity

feature

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

3.12.1

Target Version

Fixed in Version

3.13.0+dev

Summary

0005347: Make tuple expression type errors more specific

Description

Currently, the error message generated by OCaml in case of an ill-typed tuple expression is less specific than the error message generated in case of an analogous ill-typed variant expression. For example:

# let x: int * int = 1, "Hello";;
Characters 19-29:
  let x: int * int = 1, "Hello";;
                     ^^^^^^^^^^
Error: This expression has type int * string
       but an expression was expected of type int * int
# type ('a, 'b) pair = Pair of 'a * 'b;;
type ('a, 'b) pair = Pair of 'a * 'b
# let x: (int, int) pair = Pair (1, "Hello");;
Characters 34-41:
  let x: (int, int) pair = Pair (1, "Hello");;
                                    ^^^^^^^
Error: This expression has type string but an expression was expected of type int

Notice that the error message for the tuple does not indicate which element is ill-typed, whereas the error message for the variant does.

Since I use lots of long tuples in my code, it would be very useful if OCaml gave more specific error messages in case of ill-typed tuple expressions.

Tags

No tags attached.

Attached Files

Relationships

Notes
(0006117) xleroy (administrator) 2011-09-06 16:35	Thanks for the suggestion. I guess we could have a special "propagate expected type" mode for tuple expressions, just like we have one for constructors, functions, etc. But I'll let our typechecker experts decide.

(0007493) garrigue (manager) 2012-06-01 09:10	The use of type_expect has been generalized for type inference, and as a result one now gets the behavior you expected.

Issue History
Date Modified	Username	Field	Change
2011-08-24 23:18	bartjacobs	New Issue
2011-09-06 16:35	xleroy	Note Added: 0006117
2011-09-06 16:35	xleroy	Status	new => acknowledged
2012-06-01 09:10	garrigue	Note Added: 0007493
2012-06-01 09:10	garrigue	Status	acknowledged => closed
2012-06-01 09:10	garrigue	Assigned To	=> garrigue
2012-06-01 09:10	garrigue	Resolution	open => fixed
2012-06-01 09:10	garrigue	Fixed in Version	=> 3.13.0+dev