IMO packrat parsing, while a powerful tool, should not be used to replace recursive descent, as it inherently has more overhead. It should be saved for situations where a lot of lookahead is required and the non-packrat version (an Earley parser, say) would be n^3.
- The GraphQL client is already working for basic tasks. Probably some
advanced features need to be added later. Query variables need to be
added ASAP.
- I have started writing a parser for GraphQL documents. (A document can
contain both schema and operation (query/mutation/subscription)
definitions, as well as any supporting stuff like fragments and
directives, so this is the whole GraphQL grammar.)
- The current fledgling parser is a hand-rolled recursive-descent
parser. This approach is doable but a bit unwieldy. There's a Scheme
"packrat" parsing library by Tony Garnock-Jones with ports for Chicken,
Racket and R6RS. I'll learn it and finish the parser using it. A packrat
parser is an optimized version of a Parsing Expression Grammar (PEG)
that runs in linear time at the cost of using more memory than a PEG.
PEGs are the default framework for writing most parsers these days.
- I have no idea how to best design the "engine" part of the GraphQL
server (I just took on the job because nobody else was doing it). Mark
and David have a lot of combined expertise in it, so they should direct
the effort.
- I've been designing a S-expression skin for GraphQL and have asked
John Cowan for comments now and then. The GraphQL grammar is not very
big so we can finish this soon. I'll post a semi-formal Schema ASAP. All
comments and suggestions are welcome.