[Prev][Next][Index][Thread]
Re: Initial filling of collections
On Tue, 27 Feb 2001, P T Withington wrote:
> Seems like a reasonable idea to me. It parallels init-value: and
> init-function: for slots, and the elements of a key-collection are really
> just repeated slots.
>
> Gabor Greif ggreif@lucent.com on 2001-02-27 07:00 wrote:
>
> > Hi all,
> >
> > we all use and love the fill: keyword when making collections as in
> >
> > make(<vector>, size: 42, fill: #"foo");
> >
> > If this keyword is not provided, the default is #f, which seems
> > inappropriate for limited collections over a different element type
> > than type-union(#f.singleton, XXX).
> > ...
> > I am wondering how this could be combined into a single pass and whether
> > fill-function: can be provided that accepts a key and returns an
> > initial value for make? ...
Yes, that's a good idea, IMHO.
At one point someone in Harlequin suggested "fill-value:" but it was
rejected because of object-retention fears in the face of
<stretchy-collection>s. With these, you might need the fill-value at some
point after you've created the collection, when you grow it. So, unless
you provide some way to alter the fill-value of a collection later, you
can't ever GC it, which might be a problem with objects which hold onto
system resources (memory, directly, or OS resources, indirectly, for
example).
We could have invented such a "collection-fill-value-setter" but I think
the feeling was that it was a sufficiently obscure case that users might
forget to use it. However, it was just that, a feeling -- no empirical
studies that I know of. Really, though, object retention is just
something you have to learn to watch out for, like memory leaks in C/C++,
so perhaps we should have let users do this. We didn't think too hard or
long about this specific issue at the time, I don't think.
Having a "fill-function:" potentially makes resource usage a bit less of a
problem, as you can avoid allocating resources until you need them; but
you still don't know when to free them.
Actually, how about an "empty-function:", to be called whenever a
<stretchy-collection> (or just <stretchy-sequence>?) is set to zero size?
Then you could co-ordinate with the fill-function to release any resources
:-)
> > ... (Of course this is for <sequence>s,
> > for <explicit-key-collection>s the signature would be "method() => (key,
> > value)")
Not that I've checked the DRM but IIRC, you can't add a key to an <e-k-c>
without also specifying the value, so "fill-value:" isn't needed here.
> > What I envision is something like this:
> >
> > make(limited(<vector>, of: <integer>), size: 42, fill-function: identity);
Don't you mean
as(limited(<vector>, of: <integer>), range(from: 0, to: 42));
;-?
> > Would such an extension make sense or even have a chance to make it into a
> > future DRM?
Assuming there is a future DRM some day, this should certainly be
considered for inclusion. (Also note that a "fill-function: method (key)
the-fill-value end" could be equivalent to a "fill-value: the-fill-value",
All IMHO,
Hugh
Follow-Ups:
References: