[hackers] Limited collections and type-for-copy

[Dustin Voss]

On Apr 28, 2008, at 3:34 PM, Hugh Greene wrote:

>> 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.)

make on <limited-collection> calls make-limited-collection on the  
requested base collection class and the requested element type. make- 
limited-collection calls make on an instantiable limited collection  
class (say, <simple-integer-vector>), passing the <limited-collection>  
in the collection-type: init keyword.

We could arrange for make on <simple-integer-vector> to partially  
guess what the <limited-collection> would have been (e.g. base class  
<simple-vector>, element type <integer>), but we wouldn't be able to  
guess the size constraint, and, for a limited collection of arbitrary  
type (e.g. limited(<deque>, of: type-union(<character>, <string>)) we  
wouldn't be able to guess the element type either.

Looking at the DRM again, though, there's good news. type-for-copy  
that returns a limited collection type is defined to not have a size  
constraint, meaning, for predefined limited collections like <simple- 
integer-vector>, we can have make do the right thing.

Unfortunately, that won't work for limited collections of arbitrary  
type, but I'll go ahead and fix the others.

>> 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.
>>

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


Oh. Well, I suppose we could do that, too. :-)

I just thought of a third solution that might be perfect for limited  
collections of arbitrary type. If Gwydion Dylan supports making  
classes at run-time, we can create a new limited collection class for  
each base class and element type restriction.

Sometimes, I amaze even myself. :-)  Anybody see any problems with  
this idea?