[Grace-core] Typing Collections

[Andrew P. Black]

I started looking at Kim’s version of collections with types, and found something that I don’t know how to express.


In my (untyped) version, I had defined a list object, which was a CollectionFactory with methods with(), withAll(), and empty.

Kim wanted to parameterise this object,making it a list<T>.  Well, we can’t do that, because we can’t parameters defs, only methods.

Kim worked around this problem by adding an extra level of method:

	def list = object {
	    method ofType<T> { 
		object {
		    method withAll(a:Collection<T>) -> ListT<T> {
				…
		    }
		}
	    }
	}

except that he used the dotted class syntax.   Unfortunately, this changes the interface of every factory method.  So when I tried to run a test that constructed

    def oneToFive = list.with(1, 2, 3, 4, 5)

the test failed because list no longer has a with method.

Maybe this is OK; maybe we want to make the typed and untyped interfaces quite different.   But I don’t think so; I thought that the only differences between the typed and the untyped programs was going to be the presence of types.

So, instead, I moved the type parameters to the factory methods:

	def list:CollectionFactory is readable = object {
    inherits collectionFactory.trait

    method withAll<T>(a:Collection<T>) -> ListT<T> {
        object {
            inherits enumerable.trait
            var inner: PArray<T> := PrimitiveArray.new(a.size * 2 + 1)
            var size:Number is readable := 0
            for (a: ListT<T>) do {x: T ->
                inner.at(size)put(x)
                size := size + 1
            }
            method boundsCheck(n: Number) is confidential {
                if ((n < 1) || (n > size)) then {
                    boundsError.raise "index {n} out of bounds 1..{size}" 
                }
            }

So now one can declare

    def oneToFive = list.with<Number>(1, 2, 3, 4, 5)

Previously, I argued for getting rid of type parameters as a special case and just using ordinary method parameters.  In this case, the typed and untyped interfaces will indeed be different — but the language simpler.   If we keep the extra compel city of type parameters, I want a payoff — the payoff being, in this case, that typed and untyped programs differ only in the presence of their types.

Comments?

	Andrew

	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140715/fc13774c/attachment.html>