Providing features through the storage class John Cowan (30 Jul 2015 01:48 UTC)
Re: Providing features through the storage class Bradley Lucier (31 Jul 2015 21:39 UTC)
Re: Providing features through the storage class John Cowan (01 Aug 2015 03:31 UTC)
Re: Providing features through the storage class Bradley Lucier (19 Sep 2015 21:53 UTC)
Re: Providing features through the storage class John Cowan (19 Sep 2015 22:38 UTC)

Re: Providing features through the storage class John Cowan 01 Aug 2015 03:31 UTC

Bradley Lucier scripsit:

> In this SRFI, basic arrays don't have a "storage class" in your sense.

Right.  The idea was that the storage class would hold the mutability
of strict arrays, whereas for generalized arrays, it's a matter of whether
you pass the setter directly to the array constructor or not.

> A "safe" fixed-array checks the correctness of indices as well as values.

I didn't notice that; I was thinking primarily of index correctness rather
than value correctness, and assumed that the checker procedure was about
the former rather than the latter.  I see now that that doesn't make sense.
I'll have to rethink this idea in light of that insight.

> > In addition, a standardized sparse-storage-class would be a Good Thing.
> > This would use a hash table or similar object as its backing store.
>
> I'll think about how to do this.

The getter would be hash-table-get, the setter would be hash-table-set!,
the checker would be (lambda (x) #t), the maker would be (lambda (x)
(make-hash-table)), and length would return the max fixnum or something
like that.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Objective consideration of contemporary phenomena compel the conclusion
that optimum or inadequate performance in the trend of competitive
activities exhibits no tendency to be commensurate with innate capacity,
but that a considerable element of the unpredictable must invariably be
taken into account. --Ecclesiastes 9:11, Orwell/Brown version