Structural types vs traits about ponyc HOT 3 CLOSED

class Foo
  var x: U32

  fun ref foo(y: U32, z: U32): U32 => x + y + z

  fun ref test(): U32 =>
    var f = this!foo(2)
    f(3)

    // rewrites to:
    var f = {
      var this' = this
      var y: U32 = 2
      fun ref apply(z: U32): U32 => this'.foo(y, z)
      }

    f.apply(3)

Doing this with just traits would be problematic. What would be the type of f?

from ponyc.

The example I gave in issue #10 seems to require structural types. I'm pasting the example here, for convenience.

In pony, types with different type parameters don't have a subtype relationship. So, given:

trait Animal

class Wombat is Animal

Array[Animal] and Array[Wombat] are not related types. This makes them type safe, unlike Java, but since we don't have per-type parameter variance annotation, if we stopped here we would be missing out on some things, such as passing an Array[Wombat] where an Array[Animal] is expected if we know they will be read, but not written (which would be type safe).

However, with contravariant parameters and covariant results, we can. Here, I craft two type aliases for structural types that allow me to read elements from anything that looks like a sequence:

interface SequenceReader[A]
  fun box apply(i: U64): this->A

interface SequenceWriter[A]
  fun ref update(i: U64, v: A)

Now, Array[Wombat] is a subtype of SequenceReader[Animal], without being a subtype of Array[Animal], because fun box apply(i: U64): this->Wombat is a subtype of fun box apply(i: U64): Animal since the parameter types are contravariant (in this case, equal) and the return type is covariant.

Similarly, Array[Animal] is a subtype of SequenceReader[Wombat] without being a subtype of Array[Wombat], because fun box update(i: U64, v: Animal) is a subtype of fun box update(i: U64, v: Wombat) since the parameter types are contravariant and the return type is covariant (in this case, equal).

So trait method parameter contravariance and return type covariance gives us all the power of a subtype relationship between types with different formal parameters without the type safety problem (Java) or complex annotation (Scala: http://blogs.atlassian.com/2013/01/covariance-and-contravariance-in-scala/ ).

from ponyc.

After much discussion and consultation, we determined:

1. Structural types are both necessary and preferred. However, the syntax was wrong, as it wasn't possible to have parameterised structural types. We have got rid of the {...} syntax, and instead we'll use the keyword interface for a structural type, defining them otherwise just like a trait, including being able to provide default method implementations that are picked up only if a type puts the interface in it's "provides" list.
2. Nominal types are still necessary. The particular motivating example is pattern matching on type for types that come from different packages but may be otherwise identically named (such as needing to use two versions of the same library in the same program). There are other useful ways to use nominal types, but this example is impossible with just structural types.

This approach will also eventually allow pattern matching on interfaces (ie structural types) as well as traits (ie nominal types).

from ponyc.