Subject: Re: Typing collect
From: Vassily Litvinov (vass@cs.washington.edu)
Date: Mon Jan 17 2000 - 20:23:07 PST
On Mon, 17 Jan 2000, Jonathan Aldrich wrote:
...
>
> ----------------------------------
>
> -- for each MyCollection <= Collection define:
> method copy_empty[`R <= WhatMyCollectionCanHold](c@:MyCollection[S])
> : MyCollection[R] {
> new_my_collection[R]();
> }
>
> method map(c@:`T <= Collection[`S], cl@:&(S):`R):CR
> where signature copy_empty[`R](T):`CR {
> {
> let result := copy_empty[R]();
> c.do(&(e:S) {
> result.add(cl.eval(e));
> });
> result;
> }
>
> ----------------------------------
>
> Can the existing typechecker handle this kind of thing? The `CR in the
I don't see anything that the typechecker wouldn't be able to handle. But
it is really easy to try - just put this code in the file and run
typechecker on it! For copy_empty[`R], you could just write a couple of
sample implementations, e.g. for collections and vectors or whatever.
> result of the where-clause signature is pretty "out there." The
> WhatMyCollectionCanHold restriction is another interesting typechecker
> twister.
I think we use these things quite widely in other situations. Most of our
collections do not limit the element type, except for sets (I think).
> Also, I don't think you can define copy_empty[R] very easily
> with multiple signatures and a single method (I'm open to being proved
> wrong with a code snippet).
I think without "factories" or a similar thing, you really can't implement
copy_empty with just a single method. With factories, you can in fact
have a single signature, as well as a single implementation - by pushing
the signature constraint to the appropriate factory message.
> This workaround might be acceptable for a small library. But it really
> does seem silly to have to put the method in for every subclass of
> Collection, and would probably be too painful in a large extensible
> library with many functions like map.
Putting copy_empty in each subclass seems no more silly than creating a
new_FOO method for each class. Moreover, this is only one method that you
need to put in each subclass, and then you can write single signatures and
implementations for "map" and any other function like map you need.
(Or, I didn't understand your argument about pain in case of a large
library with many map-like functions. Seems that your "map" only has a
single signature and implementation, independent of the number of classes,
right?)
Oh, and you don't have to create copy_empty for *each* subclass - even a
single implementation would give you a first approximation (like, take any
kind of collection and return an array).
> I think my original solution was a
> bit more natural, and cleaner (though of course it wasn't legal Cecil).
Yes, it is "cleaner" (for some definition of "cleaner"). The problem with
it is that it wouldn't work, at least with our library where some
collections are immutable. E.g. if you get an i_vector for an input and
create its empty clone, you won't be able to add elements to it. I think
that's a big reason why we content to having "copy_empty" in each class -
it has some "intelligence" and returns a mutable collection if the
argument is immutable.
> ...
>
> It seems eminently clear that we need at least enough object model support
> to allow immutable (or "assign-once") fields to be initialized in a
> constructor method, rather than in an "object isa" statement. Look at
> bitset.cecil for the perfect example of why this is needed: to inherit
> from a bit set, you need to initialize the "members" and "cached_length"
> fields in the new method of the descendant--thus all descendants of
> bit-set have to muck with ugly implementation details. This object model
> fix could even let you add objects one-at-a-time into immutable
> collections (in the constructor, of course!)
Yes, that's a big problem. Solutions are very welcome!
BTW Craig, I remember you wrote a big proposal for adding special
"constructor" methods to the language. Is it still under consideration?
> Some kind of factory system would also be very nice; a built-in sugar
> would encourage people to use it.
Or insistence of the leader, in place of the sugar :)
> A good factory system would mitigate
> the other problem you mentioned, that you can't say "object isa T" where T
> is a type.
I don't see why. Even the best factory system can't give dynamic meaning
to types.
I hope this highlights the major problems with the current Cecil design
(or, at least, what I think they are). Let's try to solve them!
Vass
This archive was generated by hypermail 2b25 : Tue Oct 03 2000 - 15:21:20 PDT