Subject: Re: Typing collect
From: Craig Chambers (chambers@cs.washington.edu)
Date: Wed Jan 19 2000 - 10:21:02 PST
On Mon, 17 Jan 2000 13:17:32 PST, Jonathan Aldrich wrote:
> So here is the "workaround code" that I came up with, using Vass and
> Craig's suggestions:
>
> ----------------------------------
>
> -- 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;
> }
>
> ----------------------------------
Note that this approach only works for collections that you can do add
to, extensible_collections I think. The idea behind collection
factories is to also be able to support construction and
initialization of collections that have different primitives to create
and initialize them.
>
> Can the existing typechecker handle this kind of thing? The `CR in the
> result of the where-clause signature is pretty "out there." The
> WhatMyCollectionCanHold restriction is another interesting typechecker
> twister.
This is all well within the scope of the current typechecker.
Signature constraints were designed explicitly to support things like
CR. Assuming WhatMyCollectionCanHold is a constant type, not some
type variable, then it's simple bounded parameterization.
> 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).
The body of each copy_empty method is different, since it creates a
different kind of collection. So I guess I'm agreeing with you.
> 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. I think my original solution was a
> bit more natural, and cleaner (though of course it wasn't legal
> Cecil).
I'm not sure what is the workaround you're talking about. Are you
claiming that the copy_empty method is the silly method? I don't
think there's a better solution that doesn't hardwire things into the
language that shouldn't be (at least not while retaining the current
spirit of Cecil). Also, note that collection factories are intended
to encapsulate these various creation & initialization methods. But
each kind of collection does still need its own corresponding kind of
collection factory, so that the primitive constructor methods create
the right kind of collection; I can't see how to get rid of that basic
method in the current object model.
> > On the implementation side, the operation "create a new empty object of
> > the same kind as the argument" has long been in the future work categories
> > of "object model" and "object factories." I think that "object model"
> > implies language support where "factories" implies simply some conventions
> > and implementations of the factory methods for each class (which could be
> > just sugars in some cases).
>
> 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!)
This is worthy of a good face-to-face discussion. There are some
things that are planned for the next generation language w.r.t.
inheritable constructors, but I don't know if these plans solve the
problems you see now. I know of array and hash_table constructor
subclassing problems, but I haven't looked at bitset. We should see.
> Some kind of factory system would also be very nice; a built-in sugar
> would encourage people to use it. A good factory system would mitigate
> the other problem you mentioned, that you can't say "object isa T" where T
> is a type.
When you say "can't", you also should say "shouldn't". Since T is a
type, not an implementation, this expression underspecifies which
implementation should be created. If you separate
implementations/objects/classes from types, then you can't treat types
as implementations (either in object creation or in run-time
class/subclass tests).
A different object/type model might avoid this issue, but that's not
Cecil.
-- Craig
This archive was generated by hypermail 2b25 : Tue Oct 03 2000 - 15:21:20 PDT