proposal: Go 2: deriving code ala Haskell

[fkuehnel]

It's already discussed in 19412 that sum (discriminated union) types are nothing for GO 1.xx. However, unrelated to this is the fact that I find myself frequently writing boilerplate code for the interface type replacement of a discriminated union:

type Node interface {
   Show() string
   Read(string) bool
}

// here are some Node implementations
type IntNode struct {
   value int64
}

func (n IntNode) Show() string {
   fmt.Sprintf("%d", n.value)
}

func (n IntNode) Read(s string) bool {
   if val, err := strconv.ParseInt(s, 10, 64); err != nil {
      return false
   } else {
     n.value = val
     return true
  }
}

// The boilerplate code becomes worse with const types
type MathConstant uint16
const (
   Pi MathConstant = iota
   Euler
   Catalan
)

type MathNode struct {
  value MathConstant
}

func (n MathNode) Show() string {
  switch n.value {
  case Pi:
     return "Pi"
  case Euler:
     return "Euler"
  case Catalan:
    return "Catalan"
  }

  return "Must never happen"
}

func (n MathNode) Read(s string) bool {
  switch s {
  case "Pi":
    n.value = Pi
  ...
  default:
    return false
  }
  return true
}

And this is just a small example of how it could go.

Now to the Haskell deriving inspired proposal:

The idea here is like in Haskell to have a well-defined way to generate common implementations, i.e. Show, Read for algebraic types. This makes code reviews much easier and helps avoid making errors. Obviously, writing and reading less code is beneficial. Here, one could eliminate most of the boilerplate code with the 'deriving' syntax,
but one could still choose to implement custom versions if needed. This means it would be backward compatible to GO 1.xx versions:

type Node interface deriving (Show, Read)
// This will autogenerate functions with the following signature
// Show() string
// Read(string) bool

type IntNode struct {
  value int64
} deriving (Show, Read)

type MathConstant uint16
const (
   Pi MathConstant = iota
   Euler
   Catalan
)

type MathNode struct {
  value MathConstant
} deriving (Show, Read)

[DeedleFake]

If you're writing a block of code across multiple lines, the top and bottom should have a line with at least three backticks in a row, optionally followed by a language name. For example, this

```go
package main

func main() {
  println("An example.")
}
```

produces this

package main

func main() {
  println("An example.")
}

[atdiar]

You can probably achieve that without a language change.

Just have a type parametered Node and a type switch in the definition of Show and Read for the different implementations?

[fkuehnel]

You can probably achieve that without a language change.

Just have a type parametered Node and a type switch in the definition of Show and Read for the different implementations?

I don't think this is really eliminating the need to write boilerplate code. If I want to use the above code example to write:

type MyToy struct {
  n Node
  ...
}

node := &MyToy{n: &MathNode{Pi}}
fmt.Println(node.n.Show())

[seankhliao]

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

[atdiar]

@fkuehnel

You can use embedding if you want MyToy to expose the same interface as Node (method promotion)

type MyToy struct {
  Node 
  ...
}

[ianlancetaylor]

type Node interface deriving (Show, Read)

I don't understand what that means.

[fkuehnel]

type Node interface deriving (Show, Read)

I don't understand what that means.

This is a language suggestion that stands for

type Node interface {
  Show() string
  Read(string) bool
}

[fkuehnel]

@fkuehnel

You can use embedding if you want MyToy to expose the same interface as Node (method promotion)

type MyToy struct {
  Node 
  ...
}

Sure, but this proposal is to have the compiler autogenerate code for really common-use functions, i.e. Show, Read, or even more (see Haskell deriving capabilities) for algebraic types.

[DeedleFake]

stands for

Where are the full function signatures for Show() and Read() defined?

[fkuehnel]

stands for

Where are the full function signatures for Show() and Read() defined?

I added the signatures to the example above:

type Node interface deriving (Show, Read)

Is equivalent to

type Node interface {
  Show() string
  Read(string) bool
}