Make stream be a subtype of object

[jclark]

Another approach would be to define stream<T,E> as a predeclared, built-in name for an object type declared in lang.object using a variant of @typeParam. With this approach, new would be used to construct streams as normal with objects.

type Foo object {
    public function next() returns record {| xml value; |}|error? {
      ...
    }
}; 

function main() {
    Foo foo = new();
        var x = new stream<xml,error>(foo);
    // or
    stream<xml,error> x = new(foo);
}

lang.object would then include something along the lines of:

# Like @typeParam but scope is object type definition rather than function definition
# default for scope is "function"
@typeParam { scope: "object" }
type ErrorType error;

@typeParam { scope: "object" }
type ItemType any|error;

// This is for map and is method-scoped
@typeParam
type Type1 any|error;

type EmptyIterator object {
  public function next() returns () {
     return ();
  };
};

// This should probably not be public, i.e. users should stream<T,E>
// The binding from stream<T,E> to object:Stream is in the spec
type Stream object {
    private abstract object {
       public function next() returns record {| ItemType value; |}|ErrorType?;
    } impl;
    public function __init(abstract object { public function next() returns record {| ItemType value; |}|ErrorType?; } impl
                           = new EmptyIterator) {
       self.impl = impl;
    }
    public function __iterator() returns abstract object { public function next() returns record {| ItemType value; |}|ErrorType?; } {
       final var impl = self.impl;
       return new (object {
         public function next() returns record {| ItemType value; |}|ErrorType? {
	    return impl.next();
	 }
       });
    }
    public function next() returns record {| ItemType value; |}|ErrorType? {
      return self.impl.next();
    }
    public function 'map(function(ItemType val) returns Type1 func) returns stream<Type1,ErrorType> = external;
};

Phew!

Originally posted by @jclark in #406 (comment)

[sameerajayasoma]

Can we also bind from stream<T> to object:Stream?

// This is the parameter type of the object:Stream object’s __init method. 
type StreamInitFuncParamType abstract object { 
                           public function next() returns record {| ItemType value; |}|ErrorType?; 
                     } | 
                     abstract object { 
                           public function next() returns record {| ItemType value; |}|ErrorType?; 
                           public function close() ErrorType?;
                    }
;  

[jclark]

stream<T> is the same as stream<T,never>. @sameerajayasoma Does that answer your question?

[jclark]

Note that #457 also extends @typeparam

[jclark]

Also relates to #557.

[jclark]

The @typeParam extension would benefit from #447.

[jclark]

We need something like @typeParam { scope: "object" } also for #615.

[hasithaa]

The typeParam support will not work with the map method in the proposal, Because we can't statically calculate the map method signature using stream<ItemType ,ErrorType>. This requires generic support.  This affects methods like map, filter, reduce, etc. 

One possible solution is to move such methods to a lang lib module; lang.object or lang.stream.Then we can support the same use case using typeParam support. I prefer to use lang.steam for this because streams objects have special semantics as a type. That also means the stream has to be a distinct object as well.  

[jclark]

I haven't thought this through yet, but I wonder whether it will be simpler to keep stream as its own basic type, i.e. we postpone this change until we have generics.

[jclark]

With the original proposal in this issue, it is still the case that stream has special language support: the language knows to map stream<T,E> onto the generic type defined in lang.object using the extended @typeparam.

So I think it's a viable approach to introduce a lang.stream module to contain this definition (instead of lang.object) and also to contain definitions of functions on streams such as map and reduce. This would require extending the semantics of method call to look up the method in lang.stream when the value is a stream object, and this makes more sense if stream is a distinct object type.

This approach will also scale if we want to introduce other types like stream e.g. for event streams #440.

But it's still not clear to me whether this is better than keeping stream as its own basic type as now.

[jclark]

Conclusion was not to do this for Swan Lake and wait till we have generics.