... | ... | @@ -38,8 +38,8 @@ 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. *(i don't see why this is an issue? you can either list the fields you want as separate constraints, or you can have a single constraint requiring your record's type to be a permutation of the interface you want, or you can give a specific interface type and permute any record to that interface's field ordering, without ever requiring a global ordering on field types, as most other proposals do)*
|
|
|
- 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. *(again, this is not really an issue: if you start from non-scoped records and only apply non-scoped record operations, your records will remain unscoped. you can also easily define a type predicate that guarantees your record to be unscoped. i accept, however, that a non-scoped-only style should be better supported, so i've added such a predicate for the next version of the library, and i'd like to add a type tag that turns this predicate into an invariant.)*
|
|
|
|
|
|
# Label Namespace
|
|
|
|
... | ... | @@ -118,7 +118,7 @@ As it seems possible to implement most of the functionality in a library, there |
|
|
- type sharing: not specific to records, but crucial for record programming practice. If multiple modules introduce the "same" labels, means are needed to specify the equivalence of these types (cf [ Haskell prime ticket 92](http://hackage.haskell.org/trac/haskell-prime/ticket/92)).
|
|
|
- partial evaluation of type class programs: to achieve constant time record field access. Again, this feature is not specific to records, but crucial for record programming practice.
|
|
|
- portability: it would be nice if extensible records libraries were portable over multiple Haskell implementations. That not only means that these implementations need to support the same features, but that they need to interpret these features in the same way (this is currently not the case for the interaction of functional dependencies and type class overlap resolution in GHC and Hugs).
|
|
|
- permutativity: The easiest way to implement permutativity of field labels is to sort them by some total ordering. Although this can be implemented using functional dependencies, it's complex and inefficient. Compiler support for a global order on tycons (based on fully qualified name, perhaps) would be very helpful. I have submitted a feature request [\#1894](https://gitlab.haskell.org//ghc/ghc/issues/1894). Does this conflict with type sharing?
|
|
|
- permutativity: The easiest way to implement permutativity of field labels is to sort them by some total ordering. Although this can be implemented using functional dependencies, it's complex and inefficient. Compiler support for a global order on tycons (based on fully qualified name, perhaps) would be very helpful. I have submitted a feature request [\#1894](https://gitlab.haskell.org//ghc/ghc/issues/1894)*(could you please expand on why you consider sorting necessary? the proposal in [\#1894](https://gitlab.haskell.org//ghc/ghc/issues/1894) would have some rather unfortunate consequences, and it does seem that we can make do without implicit sorting)*. Does this conflict with type sharing?
|
|
|
|
|
|
# Examples
|
|
|
|
... | ... | |