| Age | Commit message (Collapse) | Author |
|---|
|
The correspondent end-to-end test has been ported. The variable
definition still needs to be checked.
|
|
|
|
|
|
The `Schema` has been overhauled to make `Output` monomorphic.
Traversing the `GraphQL` document is handled implicitly while defining
the `Schema`.
The 4th end-to-end test from `graphql-js` has been ported.
|
|
`Character` is now a synonym of the sum type of `Droid` and `Human`.
For now I don't see the need to implement GraphQL Schema interfaces with
type classes or lens. Plain Haskell ADTs should be good enough.
|
|
The third end-to-end test from graphql-js was implemented.
|
|
The second graphql-js end-to-end test was ported and passed
successfully.
|
|
|
|
This simplifies Attoparsec parsing when executing a GraphQL
query.
|
|
This allows schema definitions with side-effects for any type with a
Monadic/Alternative implementation like IO for example.
|
|
|
|
|
|
The first end-to-end test taken from `graphql-js` passes but this still
needs to be extended to support more general cases.
- `Data.GraphQL.Schema` has been heavily modified to support the
execution model. More drastic changes are expected in this module.
- When defining a `Schema` ordinary functions taking fields as input are
being used instead of maps. This makes the implementation of `execute`
easier, and, arguably, makes `Schema` definitions more *Haskellish*.
- Drop explicit `unordered-containers` dependency. `Aeson.Value`s and
field functions should be good enough for now.
|
|
`execute` still needs to be implemented.
|
|
This includes simplications to the Schema data types.
|
|
|
|
|
|
This also includes the fixes to make it work. Golden tests have been
removed.
|
|
|
|
Fixes #1.
|
|
|
