[hackers] Limited collections and type-for-copy

[Hugh Greene]

without-lurking

On Monday 28 Apr 2008 01:40, agentmail at gmail.com wrote:
> Looking over the unit tests for Gwydion Dylan, I see that none of map,
> etc, work with limited collections. This is probably because type-for-
> copy returns limited collection types and those functions don't know
> how to instantiate limited collection types properly.

I haven't looked at the code, so the following is guesswork and hand-waving 
(and maybe not useful -- it is kinda late here :-)

> limited() returns a <limited-collection>. A <limited-collection> isn't
> actually a collection -- none of its superclasses is <collection>.
> Instead, it is basically a limited collection specifier. make on
> <limited-collection> calls make-limited-collection to instantiate the
> actual collection.
>
> The actual collection (which inherits from <limited-collection-mixin>)
> has an additional init-keyword, collection-type:, beyond what the base
> collection class (<simple-vector> or whatever) has.
>
> type-for-copy doesn't treat <limited-collection-mixin> collections any
> differently from other collections, so calling type-for-copy returns
> the subclass of <limited-collection-mixin>. But when map tries to
> instantiate that type, it fails, because that type has the extra init-
> keyword parameter.

Well, going by the spec, map (and other methods which are defined to delegate 
to type-for-copy) should only be expected to work for those limited 
collection types which are instantiable (the concrete 
<http://www.opendylan.org/books/drm/Limited_Collection_Types#IX-1071> vs. the 
abstract 
<http://www.opendylan.org/books/drm/Limited_Collection_Types#IX-1069>).

I would naively imagine that a given limited type becomes instantiable by 
someone defining make and/or initialize on that type.  In the implementation 
you describe, presumably the make method on the type-for-copy of, say, 
limited(<simple-vector>, of: <integer>, size: 10) could pass the extra 
keyword arguments "collection-type: <simple-vector>" to its next-method.  
Then map could instantiate it correctly.  Ideally this could be done 
automagically for all limited collection types based on concrete collection 
classes, rather than just those specified in the DRM.  (I'm not sure how you 
implement map for collections which are non-stretchy and non-mutable, but 
that's another story.)


> Now, I see two solutions. First, make map, etc. aware of limited
> collection types and how to instantiate them. Second, make type-for-
> copy on <limited-collection-mixin> return <limited-collection> instead
> of the type of an actual collection.

According to the spec, map should not need to be aware of these types, 
although the caller should not expect it to work for uninstantiable limited 
types.  Indeed, it should already work -- or is that what you were pointing 
out in the first place?


> The problem with solution number two is that the DRM specifies that
> type-for-copy on a limited type must return a subtype of the base
> collection class, and <limited-collection> isn't a subtype of any
> collection class. I suppose we could implement instance? and subtype?
> to treat <limited-collection> as if it were a subtype of its base
> collection class (since that will presumably satisfy whatever
> necessity led the DRM to include that stipulation), but I don't know
> if that will screw up the runtime's own bookkeeping.

Well, yep, the implementation should be doing that already, somehow or other, 
as per <http://www.opendylan.org/books/drm/Limited_Collection_Types#IX-1065>:

------------------------------------------------------------------------
The limited collection type limited(C, of: T, size: S) is a subtype of C. The 
limited collection type limited(C, of: T, dimensions: D) is a subtype of C.
------------------------------------------------------------------------

> Opinions? Brilliant solutions?

Just fix it so it implements the spec? ;-)  <ducks>


end without-lurking Hugh;