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