... | ... | @@ -38,8 +38,16 @@ By **constant shape** we mean that the field names of a record are given literal |
|
|
|
|
|
An important difference between the various proposals is what constitutes a valid record, and similarly a valid record type. The key points are:
|
|
|
|
|
|
- Permutativity:: Are `{x :: Int, y :: Int}` and `{y :: Int, x :: Int}` the same type? The **Poor Man's Records** system distinguishes these two, which makes implementation much simpler, but means that any function which accepts permuted records must be polymorphic.
|
|
|
- Repeated Fields:: Is `{x :: Int, x :: Int}` a valid record type? Both **Poor Man's Records** and **Scoped Labels** allow this type, but other systems consider this an error.
|
|
|
- Permutativity:: Are `{X :: Int, Y :: Int}` and `{Y :: Int, X :: Int}` the same type? The **Poor Man's Records** system distinguishes these two, which makes implementation much simpler, but means that any function which accepts permuted records must be polymorphic.
|
|
|
- Repeated Fields:: Is `{X :: Int, X :: Int}` a valid record type? Both **Poor Man's Records** and **Scoped Labels** allow this type, but other systems consider this an error.
|
|
|
|
|
|
# Label Namespace
|
|
|
|
|
|
|
|
|
The proposals which are implemented as libraries put labels in conid (at the value level) and tycon (at the type level). In other words they must begin with capital letters, not clash with any other constructor or type, and be declared before use. If we want to support labels as first-class objects, this is essential so that we can distinguish them from other objects.
|
|
|
|
|
|
|
|
|
The other proposals allow labels to be arbitrary strings, and distinguish them by context.
|
|
|
|
|
|
# Type Systems
|
|
|
|
... | ... | |