... | ... | @@ -3,10 +3,6 @@ |
|
|
|
|
|
This is a plan to implement overloaded record fields, along the lines of SPJ's [Simple Overloaded Record Fields](records/overloaded-record-fields) proposal, as a Google Summer of Code project. (See the [ GSoC project details](http://www.google-melange.com/gsoc/project/google/gsoc2013/adamgundry/23001), for reference.) The page on [Records](records) gives the motivation and many options. In particular, the proposal for [Declared Overloaded Record Fields](records/declared-overloaded-record-fields) is closely related but makes some different design decisions.
|
|
|
|
|
|
## Design
|
|
|
|
|
|
**SLPJ** this section should be a careful design specfication.
|
|
|
|
|
|
### Motivation
|
|
|
|
|
|
|
... | ... | @@ -18,7 +14,7 @@ data Address = Address { personId :: Int, address :: String } |
|
|
```
|
|
|
|
|
|
|
|
|
are declared in the same module, there is no way to determine which type an occurrence of the personId record selector refers to. A common workaround is to use a unique prefix for each record type, but this leads to less clear code and obfuscates relationships between fields of different records. Qualified names can be used to distinguish record selectors from different modules, but using one module per record is often impractical.
|
|
|
are declared in the same module, there is no way to determine which type an occurrence of the `personId` record selector refers to. A common workaround is to use a unique prefix for each record type, but this leads to less clear code and obfuscates relationships between fields of different records. Qualified names can be used to distinguish record selectors from different modules, but using one module per record is often impractical.
|
|
|
|
|
|
|
|
|
Instead, we want to be able to write postfix polymorphic record projections, so that `e.personId` resolves the ambiguity using the type of `e`. In general, this requires a new form of constraint `r { x :: t }` stating that type `r` has a field `x` of type `t`. For example, the following declaration should be accepted:
|
... | ... | @@ -28,58 +24,57 @@ getPersonId :: r { personId :: Int } => r -> Int |
|
|
getPersonId e = e.personId
|
|
|
```
|
|
|
|
|
|
### Record field constraints
|
|
|
|
|
|
**AMG** the following needs updating.
|
|
|
A constraint `R { x :: t }` is solved if `R` is a datatype that has a field `x` of type `t` in scope. An error is generated if `R` has no field called `x`, it has the wrong type, or the field is not in scope.
|
|
|
|
|
|
## Design
|
|
|
|
|
|
If the flag `-XOverloadedRecordFields` is enabled, a new form of 'record field' constraints `r { x :: t } :: Constraint` are available where `r` and `t` are types, while `x` is a literal string. These are not typeclass constraints and do not have instances as such (though see the discussion below about virtual record fields). They can appear in contexts in the usual way (that is, they are a new primitive, like equality constraints or implicit parameter constraints). Multiple fields may be written comma-separated in a single constraint as in `r { x :: t, y :: u }`.
|
|
|
|
|
|
**SLPJ note**. I think it's more helpful to introduce it as a type-class constraint that happens to have convenient concrete syntax:
|
|
|
In the sequel, we will describe the `-XOverloadedRecordFields` extension, which permits multiple field declarations with the same label, introduces new record field constraints and a new syntax for record projection.
|
|
|
|
|
|
```wiki
|
|
|
class Has (r::*) (s::Symbol) (t::*) where
|
|
|
getFld :: r -> t
|
|
|
|
|
|
-- data T a = MkT { x :: [a] }
|
|
|
instance (b ~ [a]) => Has (T a) "r" b where
|
|
|
getFld (MkT { x = x }) = x
|
|
|
```
|
|
|
### Record field constraints
|
|
|
|
|
|
|
|
|
The `(b ~ [a])` in the instance is important, so that we get an instance match from the first two fields only.
|
|
|
Record field constraints `r { x :: t }` are syntactic sugar for typeclass constraints `Has r "x" t`, where
|
|
|
|
|
|
```wiki
|
|
|
class Has (r :: *) (x :: Symbol) (t :: *) where
|
|
|
getFld :: r -> t
|
|
|
```
|
|
|
|
|
|
Then we have convenient syntax for `(Has r "x" t)`, namely `r { x::t }`. Moreover, we get convenient syntax for conjunctions: `(Has r "x" tx, Has r "y" ty)` has shorthand `r { x::tx, y:: ty }`.
|
|
|
|
|
|
Recall that `Symbol` is the kind of type-level strings. The notation extends to conjunctions: `r {x :: tx, y :: ty}` means `(Has r "x" tx, Has r "y" ty)`. Note also that `r` and `t` might be arbitrary types, not just type variables or type constructors. For example, `T (Maybe v) { x :: [Maybe v] }` means `(Has (T (Maybe b)) "x" [Maybe v])`.
|
|
|
|
|
|
Don't forget that the `r` might be an arbitrary type not just a type variable or type constructor. For example, `(Has (T (Maybe b)) "x" [Maybe v])` is a perfectly fine (and soluble) constraint. I suppose that its shorthand looks like `T (Maybe v) { x :: [Maybe v] }`**End of SLPJ**
|
|
|
|
|
|
### Record field projections
|
|
|
Instances for the `Has` typeclass are implicitly generated, corresponding to fields in datatype definitions. For example, the data type
|
|
|
|
|
|
```wiki
|
|
|
data T a = MkT { x :: [a] }
|
|
|
```
|
|
|
|
|
|
Record field constraints are introduced by projections, which are written using a new left-associative infix operator `(.>)`. That is, if `e :: r` then `e.>x :: r { x :: t } => t`. This operator must always be applied to (at least) its second argument, so `(.>)` is invalid but `(.>x) :: forall a b . a { x :: b } => a -> b`.
|
|
|
|
|
|
has the corresponding instance
|
|
|
|
|
|
A constraint `R { x :: t }` is solved if `R` is a datatype that has a field `x` of type `t` in scope. (More precisely, if `R` contains `x :: s` then `t` must be an instance of `s`.) An error is generated if `R` has no field called `x`, it has the wrong type, or the field is not in scope. Otherwise, the new constraints are handled by the solver just like other types of constraint.
|
|
|
```wiki
|
|
|
instance (b ~ [a]) => Has (T a) "x" b where
|
|
|
getFld (MkT { x = x }) = x
|
|
|
```
|
|
|
|
|
|
|
|
|
If multiple constructors for a single datatype use the same field name, all occurrences must have exactly the same type, as at present.
|
|
|
The `(b ~ [a])` in the instance is important, so that we get an instance match from the first two fields only. For example, if the constraint `Has (T c) "x" d` is encountered during type inference, the instance will match and generate the constraints `(a ~ c, b ~ d, b ~ [a])`.
|
|
|
|
|
|
### Record selectors
|
|
|
### Projections: the dot operator
|
|
|
|
|
|
|
|
|
Optionally, we could [add a flag \`-XNoMonoRecordFields\`](records/declared-overloaded-record-fields/no-mono-record-fields) to disable the generation of the usual monomorphic record field selector functions. This is not essential, but would free up the namespace for other record systems (e.g. **data-lens**). Note that `-XOverloadedRecordFields` will generate monomorphic selectors by default for backwards compatibility reasons, but they will not be usable if multiple selectors with the same name are in scope.
|
|
|
Record field constraints are introduced by projections, which are written using the dot operator with no space following it. That is, if `e :: r` then `e.x :: r { x :: t } => t`. The right section `(.x) :: a { x :: b } => a -> b` is available but the left section `(e.)` is not (what would its type be?).
|
|
|
|
|
|
|
|
|
When either flag is enabled, the same field label may be declared repeatedly in a single module (or a label may be declared when a function of that name is already in scope).
|
|
|
The composition operator must be written with spaces on both sides, for consistency. This will break old code, but only when the `-XOverloadedRecordFields` extension is enabled. There is no ambiguity, and dot notation is already space-aware: `M.x` is a qualified name whereas `M . x` is the composition of a data constructor `M` with a function `x`. Similarly `e.x` can mean record projection, distinct from `e . x`. Note that dot (for qualified names or record projection) binds more tightly than function application, so `f e.x` means the same as `f (e.x)`. Parentheses can be used to write `(f e).x`.
|
|
|
|
|
|
### Representation hiding
|
|
|
|
|
|
|
|
|
Since the new constraints are **not** typeclass constraints, it is reasonable for the constraint solver to consult the fields in scope when deciding whether a solution is valid.
|
|
|
|
|
|
**SLPJ** As above, I'd like to say that they are just type-class constraints with special syntax. However, maybe their instances (unlike most type-class instances) can be limited in scope; the instance is in scope iff the record field selector function is. (Um; this sentence doesn't make so much sense if we suppress the record field selectors.) **End of SLPJ**
|
|
|
At present, a datatype in one module can declare a field, but if the selector function is not exported, then the field is hidden from clients of the module. It is important to support this. Typeclasses in general have no controls over their scope, but for implicitly generated `Has` instances, the instance is in scope iff the record field selector function is.
|
|
|
|
|
|
|
|
|
This enables representation hiding: exporting the field selector is a proxy for permitting access to the field. For example, consider the following module:
|
... | ... | @@ -92,7 +87,7 @@ data S = S { x :: Bool } |
|
|
```
|
|
|
|
|
|
|
|
|
Any module that imports `M` will have access to the `x` field from `R` but not from `S`. Thus `R { x :: Int }` will be solved but `S { x :: Bool }` will not.
|
|
|
Any module that imports `M` will have access to the `x` field from `R` but not from `S`, because the instance `Has R "x" Int` will be in scope but the instance `Has S "x" Bool` will not be. Thus `R { x :: Int }` will be solved but `S { x :: Bool }` will not.
|
|
|
|
|
|
### Record update
|
|
|
|
... | ... | @@ -104,67 +99,97 @@ Supporting polymorphic record update is rather more complex than polymorphic loo |
|
|
- records may include higher-rank components.
|
|
|
|
|
|
|
|
|
These problems have already been [described in some detail](records/overloaded-record-fields#record-updates). In the interests of doing something, even if imperfect, we plan to add a new syntax for monomorphic record update. This allows overloaded fields to be updated, though it requires the data constructor to be specified and cannot be abstracted over. For example,
|
|
|
These problems have already been [described in some detail](records/overloaded-record-fields#record-updates). In the interests of doing something, even if imperfect, we plan to support only monomorphic record update. For overloaded fields to be updated, a type signature may be required in order to specify the type being updated. For example,
|
|
|
|
|
|
```wiki
|
|
|
R { e | x = t }
|
|
|
e { x = t }
|
|
|
```
|
|
|
|
|
|
|
|
|
means the same as `e { x = t }` except that the type is determined from the data constructor `R`, rather than the field name `x`. Thus it can be used where the latter is ambiguous.
|
|
|
|
|
|
**SLPJ. Not the *data* constructor, for sure. Possibly the type constructor. But in any case, this is mean to be a disambiguation of
|
|
|
**
|
|
|
currently relies on the name `x` to determine the datatype of the record. If this is ambiguous, a type signature can be given either to `e` or to the whole expression. Thus either
|
|
|
|
|
|
```wiki
|
|
|
e { x = t }
|
|
|
e :: T Int { x = t }
|
|
|
```
|
|
|
|
|
|
|
|
|
so surely it should look like
|
|
|
or
|
|
|
|
|
|
```wiki
|
|
|
e {T| x = t }
|
|
|
e { x = t } :: T Int
|
|
|
```
|
|
|
|
|
|
|
|
|
where `T` is the type constructor.
|
|
|
will be accepted. (Really only the type constructor is needed, whereas this approach requires the whole type to be specified, but it seems simpler than inventing a whole new syntax.)
|
|
|
|
|
|
## Design choices
|
|
|
|
|
|
### Record update: avoiding redundant annotations
|
|
|
|
|
|
|
|
|
And there's a design choice here too. Rather than special syntax we could resolve the ambiguity if you put a type signature in one of these two places:
|
|
|
If `e` is a variable, whose type is given explicitly in the context, we could look it up rather than requiring it to be given again. Thus
|
|
|
|
|
|
```wiki
|
|
|
e :: T Int { x = t }
|
|
|
or
|
|
|
e { x = t } :: T Int
|
|
|
f :: T Int -> T Int
|
|
|
f v = v { x = 5 }
|
|
|
```
|
|
|
|
|
|
|
|
|
That's less invasive syntactially, and still does the job.
|
|
|
**End of SLPJ**
|
|
|
would not require an extra annotation. On the other hand, we would need an annotation on the update in
|
|
|
|
|
|
## Design choices
|
|
|
```wiki
|
|
|
\v -> (v { x = 4 }, [v, w :: T Int])
|
|
|
```
|
|
|
|
|
|
### The projection operator
|
|
|
|
|
|
because the type of `v` is only determined later, by constraint solving.
|
|
|
|
|
|
As currently drafted, this proposal advocates using a new operator `.>` rather than changing the meaning of the dot operator, for reasons of backward compatibility and avoidance of a whole host of tricky parsing issues. This could change, if it is felt that the benefits of mimicking other languages outweigh the drawbacks of breaking backwards compatibility.
|
|
|
|
|
|
**SLPJ**. I don't agree here. Dot-notation is so convenient and so universal that I think we should use it. And there isn't any ambiguity. Dot notation is already space-aware: `M.x` is a qualified name whereas `M . x` is the composition of a data constructor `M` with a function `x`. Similarly `r.x` can mean record selection, distinct from `r . x`.
|
|
|
**End of SLPJ**.
|
|
|
Annoyingly, nested updates will require some annotations. In the following example, the outer update need not be annotated (since `v` is a variable that is explicitly given a type by the context) but the inner update must be (since `v.x` is not a variable):
|
|
|
|
|
|
```wiki
|
|
|
f :: T Int -> T Int
|
|
|
f v = v { x = v.x { y = 6 } }
|
|
|
```
|
|
|
|
|
|
### Virtual record fields
|
|
|
|
|
|
|
|
|
The design presented above does not include virtual record fields, but it is easy to add them, by permitting typeclass-like instances:
|
|
|
It is easy to support virtual record fields, by permitting explicit `Has` instances:
|
|
|
|
|
|
```wiki
|
|
|
instance ctx => r { x :: t } where
|
|
|
get = blah :: r -> t
|
|
|
instance ctx => Has r "x" t where
|
|
|
getFld = blah :: r -> t
|
|
|
```
|
|
|
|
|
|
|
|
|
The constraint solver can be extended to consider such virtual fields. Note that if `r` is a datatype with a field `x`, the virtual field will overlap. The usual rules about overlap checking apply.
|
|
|
Note that if `r` is a datatype with a field `x`, the virtual field will overlap, and the usual rules about overlap checking apply. Explicit instances follow the usual instance scope rules, so a virtual record field instance is always exported and imported.
|
|
|
|
|
|
`Has` constraints are slightly more general than the syntactic sugar suggests: one could imagine building constraints of the form `Has r l t` where `l` is non-canonical, for example a variable or type family. It's hard to imagine uses for such constraints, though. One idea is giving virtual fields of all possible names to a type:
|
|
|
|
|
|
```wiki
|
|
|
instance Has T l () where
|
|
|
getFld _ = ()
|
|
|
```
|
|
|
|
|
|
### Record selectors
|
|
|
|
|
|
|
|
|
Even with `-XOverloadedRecordFields` enabled, monomorphic record selector functions will be generated by default for backwards compatibility reasons, and for use when there is no ambiguity. They will not be usable if multiple selectors with the same name are in scope.
|
|
|
|
|
|
|
|
|
Optionally, we could [add a flag \`-XNoMonoRecordFields\`](records/declared-overloaded-record-fields/no-mono-record-fields) to disable the generation of the usual monomorphic record field selector functions. This is not essential, but would free up the namespace for other record systems (e.g. **lens**). Even if the selector functions are suppressed, we still need to be able to mention the fields in import and export lists, to control access to them (as discussed in the [representation hiding](records/overloaded-record-fields/plan#representation-hiding) section).
|
|
|
|
|
|
|
|
|
We could also add a flag `-XPolyRecordFields` to generate polymorphic selector functions. This implies `-XNoMonoRecordFields`. For example, if a record with field `x` is declared then the function
|
|
|
|
|
|
```wiki
|
|
|
x :: Has r "x" t => r -> t
|
|
|
x e = e.x
|
|
|
```
|
|
|
|
|
|
|
|
|
would be generated. However, these have slightly odd behaviour: if two independent imported modules declare fields with the same label, they will both generate identical polymorphic selectors, so only one of them should be brought into scope.
|
|
|
|
|
|
### Monomorphism restriction and defaulting
|
|
|
|
... | ... | @@ -172,35 +197,57 @@ The constraint solver can be extended to consider such virtual fields. Note tha |
|
|
The monomorphism restriction may cause annoyance, since
|
|
|
|
|
|
```wiki
|
|
|
foo = \ e -> e.>x
|
|
|
foo = \ e -> e.x
|
|
|
```
|
|
|
|
|
|
|
|
|
would naturally be assigned a polymorphic type. If there is only one `x` in scope, perhaps the constraint solver should pick that one (analogously to the other defaulting rules). However, this would mean that bringing a new `x` into scope (e.g. adding an import) could break code. Of course, it is already the case that bringing new identifiers into scope can create ambiguity!
|
|
|
|
|
|
## Implementation details
|
|
|
|
|
|
For example, suppose the following definitions are in scope:
|
|
|
|
|
|
```wiki
|
|
|
data T = MkT { x :: Int, y :: Int }
|
|
|
data S = MkS { y :: Bool }
|
|
|
```
|
|
|
|
|
|
|
|
|
Inferring the type of `foo = \ e -> e.x` results in `alpha -> beta` subject to the constraint `alpha { x :: beta }`. However, the monomorphism restriction prevents this constraint from being generalised. There is only one `x` field in scope, so defaulting specialises the type to `T -> Int`. If the `y` field was used, it would instead give rise to an ambiguity error.
|
|
|
|
|
|
We add a new family of constraints
|
|
|
### Higher-rank fields
|
|
|
|
|
|
|
|
|
If a field has a rank-1 type, the `Has` encoding works fine: for example,
|
|
|
|
|
|
```wiki
|
|
|
data T = MkT { x :: forall a . a -> a }
|
|
|
```
|
|
|
|
|
|
|
|
|
gives rise to the instance
|
|
|
|
|
|
```wiki
|
|
|
Has :: * -> Symbol -> * -> Constraint
|
|
|
instance (b ~ a -> a) => Has T "x" b
|
|
|
```
|
|
|
|
|
|
|
|
|
where `r { x :: t }` is syntactic sugar for `Has r "x" t`, and `Symbol` is the kind of type-level strings. Evidence for `Has r l t` is just a projection function of type `r -> t`. Thus it is exactly the same as if `Has` were defined via a typeclass
|
|
|
However, if a field has a rank-2 type or higher (so the selector function has rank at least 3), things are looking dangerously impredicative:
|
|
|
|
|
|
```wiki
|
|
|
class Has r (l :: Symbol) t where
|
|
|
get :: r -> t
|
|
|
data T b = MkT { x :: (forall a . a -> a) -> b }
|
|
|
```
|
|
|
|
|
|
|
|
|
However, evidence is supplied by the constraint solver, taking into account the fields (or virtual field instances) that are in scope. These are not just typeclass constraints.
|
|
|
would give
|
|
|
|
|
|
```wiki
|
|
|
instance (c ~ ((forall a . a -> a) -> b)) => Has (T b) "x" c
|
|
|
```
|
|
|
|
|
|
|
|
|
### Example of constraint solving
|
|
|
but this is currently forbidden by GHC, even with `-XImpredicativeTypes` enabled. Indeed, it would not be much use if it were possible, because bidirectional type inference relies on being able to immediately infer the type of neutral terms like `e.x`, but overloaded record fields prevent this. Traditional monomorphic selector functions are likely to be needed in this case.
|
|
|
|
|
|
**SLPJ** Making the first example rely on the monomorphism restriction is not a good plan!
|
|
|
## Example of constraint solving
|
|
|
|
|
|
|
|
|
Consider the example
|
... | ... | @@ -215,9 +262,7 @@ module M ( R(R, x), S(S, y), T(T, x) ) where |
|
|
module N where
|
|
|
import M
|
|
|
|
|
|
foo e = e.>x
|
|
|
|
|
|
qux = (.>y)
|
|
|
foo e = e.x
|
|
|
|
|
|
bar :: Bool
|
|
|
bar = foo T
|
... | ... | @@ -226,23 +271,10 @@ module N where |
|
|
```
|
|
|
|
|
|
|
|
|
When checking `foo`, `e` is a variable of unknown type `alpha`, and the projection generates the constraint `alpha { x :: beta }` where `beta` is fresh.
|
|
|
This constraint cannot be solved immediately, so generalisation yields the type `a { x :: b } => a -> b`.
|
|
|
|
|
|
|
|
|
When checking `qux`, the projection has type `alpha -> beta` and generates the constraint `alpha { y :: beta }`. However, the monomorphism restriction prevents this constraint from being generalised. There is only one `y` field in scope, so defaulting specialises the type to `S -> Bool`. If the `x` field was used, it would instead give rise to an ambiguity error.
|
|
|
When checking `foo`, `e` is a variable of unknown type `alpha`, and the projection generates the constraint `alpha { x :: beta }` where `beta` is fresh. This constraint cannot be solved immediately, so generalisation yields the type `a { x :: b } => a -> b`.
|
|
|
|
|
|
|
|
|
When checking `bar`, the application of `foo` gives rise to the constraint `T { x :: Bool }`, which is solved since `Bool` is an instance of `forall a . a` (the type `T` gives to `x`).
|
|
|
|
|
|
|
|
|
When checking `baz`, the constraint `S { x :: gamma }` is generated and rejected, since the `x` from `S` is not in scope. |
|
|
|
|
|
### Remark
|
|
|
|
|
|
`Has` constraints are slightly more general than the syntactic sugar suggests: one could imagine building constraints of the form `Has r l t` where `l` is non-canonical, for example a variable or type family. It's hard to imagine uses for such constraints, though. One idea is giving virtual fields of all possible names to a type:
|
|
|
|
|
|
```wiki
|
|
|
instance Has T l () where
|
|
|
get _ = ()
|
|
|
``` |
|
|
\ No newline at end of file |