... | @@ -9,7 +9,7 @@ It is a specific realisation of the ideas in [DistributedHaskell](distributed-ha |
... | @@ -9,7 +9,7 @@ It is a specific realisation of the ideas in [DistributedHaskell](distributed-ha |
|
|
|
|
|
Just as in [DistributedHaskell](distributed-haskell), we provide 4 APIs
|
|
Just as in [DistributedHaskell](distributed-haskell), we provide 4 APIs
|
|
|
|
|
|
- `Data.Typeable`: type-indexed type representation. This replaces the existing `Data.Typeable`, and the kind of `TypeRep` changes.
|
|
- `Data.Typeable`: type-indexed type representation. This replaces the existing `Typeable` class, and the kind of `TypeRep` changes to `TypeRep :: k -> *`.
|
|
|
|
|
|
- `Data.Dynamic`: dynamically-typed values; replaces the existing `Data.Dynamic`. The API is almost unchanged.
|
|
- `Data.Dynamic`: dynamically-typed values; replaces the existing `Data.Dynamic`. The API is almost unchanged.
|
|
|
|
|
... | @@ -68,8 +68,13 @@ gcastR::TypeRep(a :: k)->TypeRep(b :: k)-> c a ->Maybe(c b)gcast::(Typeable(a :: |
... | @@ -68,8 +68,13 @@ gcastR::TypeRep(a :: k)->TypeRep(b :: k)-> c a ->Maybe(c b)gcast::(Typeable(a :: |
|
|
|
|
|
Notes:
|
|
Notes:
|
|
|
|
|
|
- Many of these functions come in two variants: one which takes an explicit `TypeRep` argument, and one that take an implicit `TypeRep` argument via a `Typeable a` constraint.
|
|
- Many of these functions come in two variants:
|
|
We use a consistent naming scheme: put an `R` suffix on variants that take an explicit `TypeRep` parameter, no suffix for `Typeable` constraint versions.
|
|
|
|
|
|
- one which takes an explicit `TypeRep` argument, and
|
|
|
|
- one that take an implicit `TypeRep` argument via a `Typeable a` constraint.
|
|
|
|
|
|
|
|
>
|
|
|
|
> We use a consistent naming scheme: put an `R` suffix on variants that take an explicit `TypeRep` parameter, no suffix for `Typeable` constraint versions.
|
|
|
|
|
|
- Note that the type `(:~:)` comes from `Data.Type.Equality`.
|
|
- Note that the type `(:~:)` comes from `Data.Type.Equality`.
|
|
|
|
|
... | @@ -85,6 +90,8 @@ Notes: |
... | @@ -85,6 +90,8 @@ Notes: |
|
|
|
|
|
- Functions for constructing and destructing `TypeRep`s differ, in particular destructing needs a GADT return type to deal with existentially hidden `TypeRep` indices.
|
|
- Functions for constructing and destructing `TypeRep`s differ, in particular destructing needs a GADT return type to deal with existentially hidden `TypeRep` indices.
|
|
|
|
|
|
|
|
- The new API does not expose `TyCon`, and is therefore a much smaller API; see questions below.
|
|
|
|
|
|
### With kind equalities
|
|
### With kind equalities
|
|
|
|
|
|
|
|
|
... | @@ -110,11 +117,21 @@ In the kind-heterogeneous case, `getR1` and `getR2` come out of the TCB. |
... | @@ -110,11 +117,21 @@ In the kind-heterogeneous case, `getR1` and `getR2` come out of the TCB. |
|
### Questions
|
|
### Questions
|
|
|
|
|
|
- How many `getR1`, `getR2` etc should we provide?
|
|
- How many `getR1`, `getR2` etc should we provide?
|
|
|
|
|
|
- Do we want explicit names for some type representations?
|
|
- Do we want explicit names for some type representations?
|
|
Perhaps `typeRepTBool` etc., and just for Prelude defined types.
|
|
Perhaps `typeRepBool` etc., and just for Prelude defined types.
|
|
(It is nice to avoid writing `typeRep :: TypeRep Bool`)
|
|
(It is nice to avoid writing `typeRep :: TypeRep Bool`)
|
|
- `TyCon` is now entirely hidden from the user.
|
|
|
|
Is there a use-case where this is not desirable?
|
|
- `TyCon` is used internally but is now entirely hidden from the user.
|
|
|
|
Is there a use-case where this is not desirable? By way of background, the internal representatation looks like this
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
data TypeRep (a :: k) where
|
|
|
|
TRCon :: TyCon a -> TypeRep a
|
|
|
|
TRApp :: TypeRep a -> TypeRep b -> TypeRep (a b)
|
|
|
|
```
|
|
|
|
|
|
|
|
where the `TyCon a` is a now-internal data type describing a type constructor.
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
... | @@ -157,8 +174,8 @@ Notes |
... | @@ -157,8 +174,8 @@ Notes |
|
We statically know some "Shape" information, but not all info about type.
|
|
We statically know some "Shape" information, but not all info about type.
|
|
e.g., `SDynamic Maybe` contains a value that is definitely a `Maybe ty` for some type `ty`, but the type `ty` can vary between values of type `SDynamic Maybe`.
|
|
e.g., `SDynamic Maybe` contains a value that is definitely a `Maybe ty` for some type `ty`, but the type `ty` can vary between values of type `SDynamic Maybe`.
|
|
|
|
|
|
> >
|
|
>
|
|
> > One use-case is in the implementation of `StaticPtr`.
|
|
> One use-case is in the implementation of `StaticPtr`.
|
|
|
|
|
|
### Questions
|
|
### Questions
|
|
|
|
|
... | | ... | |