Spec clarification: recursive coercion of scalar values into lists (Oct2016 section 3.1.7)

[jlouis]

Background

Suppose I have a schema which contains

enum Pet {
   DOG,
   CAT
}

Question

If I have an arg which expect a value of type [Pet] and I supply the value DOG, the spec is clear that the system should coerce this value into [DOG] which is valid in the context.

However, the spec is not clear about what to do with recursive definitions of this. There are two ways we can interpret the coercion:

• We disallow recursion in the coercion
• We allow recursion in the coercion

Furthermore, we can consider the following rules:

• The coerced value MUST be of Scalar type, e.g., Pet.
• The coerced value can be any type T.

Consider a case where my schema has gameOfLife(matrix: [[PET]]). Now, if I supply DOG, there are two interpretations, when we consider the above:

• We first coerce DOG into [DOG] and then recurse, yielding [[DOG]] as the final answer.
• We disallow the recursion and we disallow coercion of non-scalar values (this also needs a treatment of non-null for it to be proper).

Implementation

In my Erlang implementation of GraphQL (https://github.com/shopgun/graphql-erlang) we currently recurse. This seems somewhat easier to handle in a functional language. We just "wrap" one level and then call again with the new structure. In turn, once the correct form is met, we accept the type. In the execution phase, the same thing happens.

Discussion

The coercion is definitely one of convenience for the programmer. A type system is more complex if it has to deal with this, and can't rely on straightforward equality. So from a type theory point of view, this coercion should just be rejected altogether.

For a programmer of a statically typed language, it doesn't seem to me that this is useful. You would probably use a "type provider" system to make sure everything is fitting and thus you would always input something of type [Pet] in the example above. For dynamic languages, this could be more useful.

What I am trying to get at is this: would the recursive nature help a programmer in any way? If not, then rejecting it is probably the better option because it could eliminate some surprise and room for error. OTOH, if there is a legitimate use, then it could prove to be a useful feature. I can only guess that this may also be the reason this coercion happens in the first place.

[leebyron]

Thanks for bringing this up - the original intention was that this applied recursively but I can see from the spec text how this was not as clear as it could be. I'm glad you were able to correctly interpret it for the erlang implementation.

I added an edit which includes some clarity on why single value wrapping in inputs is valuable and examples of this coercion.