|
|
CONVERSION ERROR
|
|
|
|
|
|
Error: HttpError (HttpExceptionRequest Request {
|
|
|
host = "ghc.haskell.org"
|
|
|
port = 443
|
|
|
secure = True
|
|
|
requestHeaders = []
|
|
|
path = "TypeFunctionsSyntax"
|
|
|
queryString = "?version=8"
|
|
|
method = "GET"
|
|
|
proxy = Nothing
|
|
|
rawBody = False
|
|
|
redirectCount = 10
|
|
|
responseTimeout = ResponseTimeoutDefault
|
|
|
requestVersion = HTTP/1.1
|
|
|
}
|
|
|
(StatusCodeException (Response {responseStatus = Status {statusCode = 403, statusMessage = "Forbidden"}, responseVersion = HTTP/1.1, responseHeaders = [("Date","Sun, 10 Mar 2019 07:04:02 GMT"),("Server","Apache/2.2.22 (Debian)"),("Strict-Transport-Security","max-age=63072000; includeSubDomains"),("Vary","Accept-Encoding"),("Content-Encoding","gzip"),("Content-Length","258"),("Content-Type","text/html; charset=iso-8859-1")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>403 Forbidden</title>\n</head><body>\n<h1>Forbidden</h1>\n<p>You don't have permission to access TypeFunctionsSyntax\non this server.</p>\n<hr>\n<address>Apache/2.2.22 (Debian) Server at ghc.haskell.org Port 443</address>\n</body></html>\n"))
|
|
|
|
|
|
Original source:
|
|
|
|
|
|
```trac
|
|
|
= Type Functions: Syntax and Representation =
|
|
|
|
|
|
== Syntax of family and family instance declarations ==
|
|
|
|
|
|
A toplevel family declaration consists of a type declaration head using `family` as a special following the declaration keyword. It is optionally followed by a `::` and a kind (which is by default `*` if not specified). In an associated family declaration, the `family` special is dropped. Toplevel family instance declarations, use the `instance` keyword after the main declaration keyword; associated instances don't use `instance`. We require for every instance declaration of a type family that a matching family declaration is in scope.
|
|
|
|
|
|
== Representation of indexed types ==
|
|
|
|
|
|
=== Family declarations ===
|
|
|
|
|
|
`HsDecls.TyClDecl` has a new variant `TyFamily` to represent family declarations of both flavours (i.e., `type family` and `data family`). The new variant comprises the declaration's flavour, name, type parameters, and optionally a result kind signature. The type parameters can have kind signatures as usual. The predicate `HsDecls.isFamilyDecl` recognises family declarations.
|
|
|
|
|
|
=== Family instances ===
|
|
|
|
|
|
We represent insatances of type families and data/newtype families by generalising the AST for type synonym declarations (`TySynonym`) and data/newtype declarations (`TyData`), respectively. In both cases, the novelty is to admit type index patterns instead of just type variables as parameters. These index pattern go into the field `tcdTyPats` of type `Maybe [LHsType name]`, used as follows:
|
|
|
* If it is `Nothing`, we have a ''vanilla'' data type declaration or type synonym declaration and `tcdVars` contains the type parameters of the type constructor.
|
|
|
* If it is `Just pats`, we have the definition of an a indexed type (toplevel or nested in an instance declarations). Then, `pats` are type patterns for the type-indexes of the type constructor and `tcdVars` are the variables in those patterns. Hence, the arity of the type constructor is `length tcdPats` and ''not'' `length tcdVars`.
|
|
|
In both cases (and as before we had indexed types), `tcdVars` collects all variables we need to quantify over.
|
|
|
|
|
|
=== Parsing and AST construction ===
|
|
|
|
|
|
The LALR parser allows arbitrary types as left-hand sides in '''data''', '''newtype''', and '''type''' declarations. The parsed type is, then, passed to {{{RdHsSyn.checkTyClHdr}}} for closer analysis (possibly via `RdHsSyn.checkSynHdr`). It decomposes the type and, among other things, yields the type arguments in their original form plus all type variables they contain. Subsequently, {{{RdrHsSyn.checkTyVars}}} is used to either enforce that all type arguments are variables (second argument is `False`) or to simply check whether the type arguments are variables (second argument `True`). If in enforcing mode, `checkTyVars` will raise an error if it encounters a non-variable (e.g., required for class declarations). If in checking mode, it yields the value placed in the `tcdPats` field described above; i.e., returns `Nothing` instead of the type arguments if these arguments are all only variables.
|
|
|
|
|
|
== Representation of associated types ==
|
|
|
|
|
|
We add type declarations to class declarations and instance declarations by a new field, of type `[LTyClDecl]`, to both `TyClDecl.ClassDecl` (known by the field name `tcdATs`) and `TyClDecl.InstDecl`. For classes, this new field contains values constructed from `TyFamily` and `TySynonym` (for synonym defaults), whereas for instances, we have `TyData` and `TySynonym`.
|
|
|
|
|
|
== Representation of equational constraints ==
|
|
|
|
|
|
Equational constraints are parsed into a new variant of `HsPred`, called `HsEqualP`.
|
|
|
|
|
|
== Type tags ==
|
|
|
|
|
|
To enable the listing of associated types in the sub-binder list of import/export items for classes, we extend the parser with a production that allows a constructor name (upper case or approppriate infix operator in parenthesis) to be prefixed by the keyword `type`.
|
|
|
|
|
|
NB: There is a cavet at the moment, in error messages the type prefix is not printed, as the `ppr` instance on `HsImpExp.IE` is polymorphic in the name (and hence, we cannot get at the name space in which a name is).
|
|
|
|
|
|
``` |
|
|
# Type Functions: Syntax and Representation
|
|
|
|
|
|
|
|
|
## Syntax of family and family instance declarations
|
|
|
|
|
|
|
|
|
|
|
|
A toplevel family declaration consists of a type declaration head using `family` as a special following the declaration keyword. It is optionally followed by a `::` and a kind (which is by default `*` if not specified). In an associated family declaration, the `family` special is dropped. Toplevel family instance declarations, use the `instance` keyword after the main declaration keyword; associated instances don't use `instance`. We require for every instance declaration of a type family that a matching family declaration is in scope.
|
|
|
|
|
|
|
|
|
## Representation of indexed types
|
|
|
|
|
|
|
|
|
### Family declarations
|
|
|
|
|
|
|
|
|
|
|
|
`HsDecls.TyClDecl` has a new variant `TyFamily` to represent family declarations of both flavours (i.e., `type family` and `data family`). The new variant comprises the declaration's flavour, name, type parameters, and optionally a result kind signature. The type parameters can have kind signatures as usual. The predicate `HsDecls.isFamilyDecl` recognises family declarations.
|
|
|
|
|
|
|
|
|
### Family instances
|
|
|
|
|
|
|
|
|
|
|
|
We represent insatances of type families and data/newtype families by generalising the AST for type synonym declarations (`TySynonym`) and data/newtype declarations (`TyData`), respectively. In both cases, the novelty is to admit type index patterns instead of just type variables as parameters. These index pattern go into the field `tcdTyPats` of type `Maybe [LHsType name]`, used as follows:
|
|
|
|
|
|
|
|
|
- If it is `Nothing`, we have a *vanilla* data type declaration or type synonym declaration and `tcdVars` contains the type parameters of the type constructor.
|
|
|
- If it is `Just pats`, we have the definition of an a indexed type (toplevel or nested in an instance declarations). Then, `pats` are type patterns for the type-indexes of the type constructor and `tcdVars` are the variables in those patterns. Hence, the arity of the type constructor is `length tcdPats` and *not* `length tcdVars`.
|
|
|
|
|
|
|
|
|
In both cases (and as before we had indexed types), `tcdVars` collects all variables we need to quantify over.
|
|
|
|
|
|
|
|
|
### Parsing and AST construction
|
|
|
|
|
|
|
|
|
|
|
|
The LALR parser allows arbitrary types as left-hand sides in **data**, **newtype**, and **type** declarations. The parsed type is, then, passed to `RdHsSyn.checkTyClHdr` for closer analysis (possibly via `RdHsSyn.checkSynHdr`). It decomposes the type and, among other things, yields the type arguments in their original form plus all type variables they contain. Subsequently, `RdrHsSyn.checkTyVars` is used to either enforce that all type arguments are variables (second argument is `False`) or to simply check whether the type arguments are variables (second argument `True`). If in enforcing mode, `checkTyVars` will raise an error if it encounters a non-variable (e.g., required for class declarations). If in checking mode, it yields the value placed in the `tcdPats` field described above; i.e., returns `Nothing` instead of the type arguments if these arguments are all only variables.
|
|
|
|
|
|
|
|
|
## Representation of associated types
|
|
|
|
|
|
|
|
|
|
|
|
We add type declarations to class declarations and instance declarations by a new field, of type `[LTyClDecl]`, to both `TyClDecl.ClassDecl` (known by the field name `tcdATs`) and `TyClDecl.InstDecl`. For classes, this new field contains values constructed from `TyFamily` and `TySynonym` (for synonym defaults), whereas for instances, we have `TyData` and `TySynonym`.
|
|
|
|
|
|
|
|
|
## Representation of equational constraints
|
|
|
|
|
|
|
|
|
|
|
|
Equational constraints are parsed into a new variant of `HsPred`, called `HsEqualP`.
|
|
|
|
|
|
|
|
|
## Type tags
|
|
|
|
|
|
|
|
|
|
|
|
To enable the listing of associated types in the sub-binder list of import/export items for classes, we extend the parser with a production that allows a constructor name (upper case or approppriate infix operator in parenthesis) to be prefixed by the keyword `type`.
|
|
|
|
|
|
|
|
|
|
|
|
NB: There is a cavet at the moment, in error messages the type prefix is not printed, as the `ppr` instance on `HsImpExp.IE` is polymorphic in the name (and hence, we cannot get at the name space in which a name is).
|
|
|
|
|
|
|