A few remarks

[theobat]

So first of all thanks for putting this together.

The main problem I see with merging what I did is this: you added a notion of "type variable" in wrapper definitions whereas I only allowed for type aliases on existing wrappers (List or NonNull).
Another problem I see is that you used the notion of haskell tuples, without giving a definitive meaning for it (in graphql I mean):

wrapper Entry<a> = (ID!, a)

Except for the Entry type the type variable is useless in the examples you provide and I think it's be clearer to state:

wrapper Set = List
# versus
wrapper Set<a> = [a]

On the other hand I don't really know how to define a tuple without adding the notion of type variables in wrapper type definitions, but that's drastically extending the type system I guess...

Overall, I think It'd be better to separate the proposal into 2 parts:

• A proposal for wrapper aliases (enabling lists, vectors etc)
• A proposal for "multi type wrapper" definitions (like tuples) ? Or for type variables in general ? At the very least a definition for what (ID!, a) means in graphql terms is required

let me know what you think

[nalchevanidze]

@theobat thank you for your review

1

Another problem I see is that you used the notion of haskell tuples, without giving a definitive meaning for it (in graphql I mean):

what do you mean? i wrote down, that they are list with fixed size.

2

Except for the Entry type the type variable is useless in the examples you provide and I think it's be clearer to state:

we could use this notation

wrapper W1 = []
wrapper W2 = []

wrapper Entry1 = (W2 W1 ID! , W1  *)
wrapper Entry = (ID! ,  *)
wrapper Map = [Entry]

where

• * is wrapper type variable.
• W2 W1 ID! is same as W2<W1<ID!>>. as long they can have only one argument there is no place for ambiguity.

3

but that's drastically extending the type system I guess...

wrappers already have typeVariable.

• List: [a] <=> List<a>
• NonNull: a! <=> NonNull<a>

that why we have nested ofType: __Type. like in this example.

{
  "kind": "LIST",
  "name": null,
  "ofType": {
    "kind": "NonNull",
    "name": null,
    "ofType": <some type>
  }
}

we don't drastically extend type system we are just using them.

that why cutom wrappers are only allowed to have 1 type Variable!

[theobat]

All right, I missed:

(a1,...,an) is a list with fixed size n.

somehow, or I thought it was specifying the number of type variables on the left-hand side of the equality.

Given your points 1 and 3 I suppose point 2 is irrelevant then, except for a tiny shortcut.
Besides, your definitions give the ability to create named concrete wrappers such as (for instance):

wrapper mywrapper<a> = [Int] #valid

I'm not sure about this syntax btw, maybe it's better to explicitly signal the absence of a variable ?

# example:
wrapper mywrapper<> = [Int] #valid

Still, I think the (a1,..., an) definition is somewhat unrelated to the idea of custom wrappers ? I feel it's more like a dedicated wrapper in and off itself, that is, the very idea of tuple being currently absent of graphql, their addition as a "native" wrapper like List and NonNull could be a proposal itself.

I'm going to create a PR to assemble my stuff with yours and we'll see what we can do about tuples.

[nalchevanidze]

no i am not intending that. this should be invalid.

• that why i say that last parameter of vector must be the typeVariable.
• one additional restriction can be that typeVariable must be used. and only once.

wrapper mywrapper<> = [Int] #invalid

tuple:

definition will be like:

is a list with fixed size n.

maybe you are right it shoud be native Wrapper. like List and NonNull. we can handle it in different proposal.