Matt Mahoney

Definitely worth discussing! I *believe* this could be solved more generally with generic types, i.e. you should be able to create your own custom `type Set { values: [T] }`....

> this schema will be invalid, since output type can't be used as input value. Heh we'd need an `InputSet` and `OutputSet` (personally I think we messed up, for instance,...

This hits on a potentially deeper topic, which is that you sometimes want to *merge* schema definitions and schema extensions only give us a *subset* of that merging property (for...

For a single server schema, I'm not yet convinced this adds a lot of value: you still need to actually implement each field on each concrete type (unless you're using...

> why are we so scared of these recursive definitions? things like that happen in real progr languages, no trouble. Why all this word soup to prohibit smth like that...

Is there an existing paragraph we should be rewording such that new readers of the spec come to the understanding that we're trying to get to? Basically: what existing text...

As a note: GraphQL the language is purposefully not Turing Complete: you must not be able to create an operation which, when executed with known-to-halt resolvers, does not halt. Basically,...

> This would split GraphQL syntax between client and server. Is that correct? Yes, but that's already true for clients like Relay today. This spec proposal would have the actual...

I actually think the executor implementation is not that difficult: https://github.com/graphql/graphql-js/pull/3152. I'll iterate on the spec changes required once we have some form of consensus that this experimental implementation is...

@ivome: I agree that making fragments truly modular and composable is desirable. There's a lot that can be done, but what you've proposed won't by itself solve the issue. If...