Home My Page Projects Code Snippets Project Openings SML/NJ Bugs
Summary Activity Tracker Lists

[#91] Type inference for records

Date:
2012-02-05 16:55
Priority:
3
State:
Open
Submitted by:
Bug Submitter (webuser)
Assigned to:
David MacQueen (dbm)
Machine Architecture:
None
Operating System:
Generic Unix
Component:
Compiler
Resolution:
None
Severity:
Major
OS Version:
Mac OS X
SML/NJ Version:
110.73
Keywords:
types
URL:
Transcript (of reproduction):
- stdIn:2.6-2.26 Error: unresolved flex record (can't tell what fields there are besides #x)
Source (for reproduction):
fun f (r as {x : int, y : int}) : int = let fun g {x, ...} = 2*x; in g r * y end;
Summary:
Type inference for records

Detailed description
The standard says is that \\\\\\\For each occurrence of a record pattern
containing a wild card, ..., the program context must determine
the domain ... of the row type.\\\\\\\ However, in many cases where
the context does determine the type, Standard ML of New Jersey
rejects the record pattern:

Additional comments:
The standard is pretty vague, but other compilers accept this code.

Submitted via web form by Rob Arthan rda@lemma-one.com

Comments:

Message  ↓
Date: 2015-09-24 22:14
Sender: David MacQueen

I am inclined to "fix" this issue by revising/clarifying the Definition so that only the context known at the point of definition of the variable (e.g. "g" in this example) is used to resolve the "..." (i.e. the implicit row-unification type variable that the ellipsis represents). To allow the later uses of the variable in the scope of the definition to contribute to the type checking context complicates the process excessively for little practical gain.

Date: 2012-02-05 18:04
Sender: David MacQueen

DBM: This is a tricky issue. In several places, the Definition mentions using "context" to resolve types, without making clear exactly what or how much context is to be analyzed. In this case the problem is that we need to generalize the type of g for use in its scope, but the unresolved record pattern makes the (ungeneralized) type inexact, so we don't know exactly what unification variables might be implied by the "..." wildcard pattern. This small example looks plausible, but much more convoluted examples can be constructed.

For overloading resolution, we do use the scope of a definition as part of the context used, but that is a simpler case because the special unification variables associated with the undetermined types of overloaded operators are not generalizable.

I'll think about this to see if there is a clean and reasonably "canonical" way to deal with this, but I am not inclined to take extreme measures to "fix" this issue. I'll also try to see how the other compilers type checkers work for this example.

Attached Files:

Changes

Field Old Value Date By
detailsThe standard says is that \\\\\\\For each occurrence of a record pattern containing a wild card, ..., the program context must determine the domain ... of the row type.\\\\\\\ However, in many cases where the context does determine the type, Standard ML of New Jersey rejects the record pattern: Additional comments: The standard is pretty vague, but other compilers accept this code. Submitted via web form by Rob Arthan rda@lemma-one.com 2015-09-24 22:14dbm
assigned_tonone2012-02-05 17:05jhr