Allow inline creation of complex/nested custom types

[inoas]

I can write:

pub type PrimaryColour {
  Red
  Green
  Blue
}

pub type CatEyeShape {
  Oval
  Round
}

pub type CatEye {
  CatEye(
    shape: CatEyeShape,
    colour: PrimaryColour
  )
}

pub type Cat {
  Cat(
    left_eye: CatEye,
    name: String,
    cuteness: Int
  )
}

I wish I could write:

pub type Cat {
  Cat(
    left_eye: CatEye {
      shape: CatEyeShape {
        Oval
        Round
      },
      colour: PrimaryColour
    },
    name: String,
    cuteness: Int
  )
}

Pros:

• I think this makes it a lot easier to implement custom types for complex and deeply nested JSON/XML structures.
• I ran into this issue when reading and transforming deeply nested JSON in Typescript and had tons of hard to name and unrelated types at the top level of the hierarchy in the file.

Cons: AFAIK all the nested types would require to be public and I'd assume that would be the standard behavior. Do you think this is a problem? There is only one pub type key-phrase here.

If pub was omitted all types defined would be private

Further: Could we have anonymous types(?) for anything that is just a container, e.g. only the leaves would require type declaration because the rest is just nesting?

pub type Cat {
  Cat(
    left_eye: {
      shape: {
        Oval
        Round
      },
      colour: {
        Red
        Green
        Blue
    },
    name: String,
    cuteness: Int
  )
}

[inoas]

More questions in that direction?

How would such a notation interplay with Lists and Tuples (and possibly a Map syntax in future if given)

[lucasavila00]

This would be useful in code generation. https://www.graphql-code-generator.com/ would generate a very long name for types in queries, for instance. This proposal would the generated code simpler.

[lpil]

I think we'd still need the names to be as long to avoid clashes, no?

[lucasavila00]

I imagined no.

Say I have a userBasicInfoQuery and a userDetailsQuery, both on the same schema but varying what's selected.

We'd then have:

type UserBasicInfoQuery {
  UserBasicInfoQuery(user: User{ name: String })
} 

type UserDetailsQuery {
  UserDetailsQuery(user: User {name: String, age: Int })
} 

// also a new way to write single-constructor types - for orthogonality, parser checks if first letter is Upper or Lower to decide which
type A { field: Int }


// we can also have, for orthogonality
type B {
  B(c: C { D E } )
}

To construct it:

// :: syntax to make it clear User is not in regular scope
UserBasicInfoQuery(user: ::User(name: "abc"))
UserDetailsQuery(user: ::User(name: "abc", age: Int))

To de-construct it:

UserBasicInfoQuery(::User(name)) = it

// or 
UserBasicInfoQuery(u) = it

UserBasicInfoQuery::User(name) = u

[lpil]

It would be ambiguous in the first case as a lone User could be either, we cannot infer which it should be.

Qualified constructors as in the final example could resolve this but I think it is too late to make a large change to the language and make all constructors qualified, and I wouldn't want to have different rules for constructors depending on which syntax was used to construct them.

[lucasavila00]

It would be ambiguous in the first case as a lone User could be either, we cannot infer which it should be.

If it's a "User {" than it's a new type. If it's "User (" than it's a pre-defined type.
What would be the ambiguity?

[lpil]

In that case it would be ambiguous when using it as to which constructor you want to use, but also we can't use a X { ... } syntax as this would be ambiguous in the parser with blocks unless we added semicolons or significant whitespace to Gleam