Protocols

Motivation

Clay current allows protocols (or concepts or type classes, if you prefer) to be defined in an ad-hoc way, using CallDefined?:

   ForwardCoordinate?(T) = CallDefined?(dereference, T) and CallDefined?(inc, T);

While this works, it leaves the compiler with very little semantic information for error reporting or debugging—it can only report that the pattern match failed, not why. The CallDefined? syntax is also abstracted from actual expression syntax. First-class language support for protocols and function definition syntax for protocol-following types would allow for improvements in compiler error reporting and code readability, and would reduce boilerplate in common function definition cases.

Proposed implementation

An example specification of the iterator, sequence, and coordinate protocols:

  protocol Iterator?('I) {
      // required operations
      next(i: 'I) 'E;
      hasNext?(i: 'I) Bool;

      // derived definitions
      IteratorTargetType(static 'I) = 'E;
  }
  
  protocol Sequence?('S)
      | Iterator?('I) // constraints on related types
  {
      // required operations
      iterator(x: 'S) 'I;
      
      // derived definitions
      SequenceIteratorType('S) = 'I;
      SequenceElementType('S) = IteratorTargetType('I);
  }

  protocol Coordinate?('C) {
      dereference(c: 'C) 'E;
      inc(c: 'C) Void;
      dec(c: 'C) Void;
  
      CoordinateTargetType('C) = 'E;
  }
  
  protocol CoordinateSequence?('S)
      | Sequence?('S) // derive from base protocol
        and Coordinate?('C)
        and CoordinateTargetType('C) == SequenceElementType('S)
  {
      begin(s: 'S) 'C;
      end(s: 'S) 'C;

      SequenceCoordinateType('S) = 'C;
  }

Discussion

Please add comments here.