Email list hosting service & mailing list manager


Make structure of specialized-arrays more opaque? Bradley Lucier 16 Oct 2015 18:55 UTC

The procedures

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Procedure: specialized-array domain: domain storage-class: storage-class
[ body: body ] [ indexer: indexer ] [ initializer-value:
initializer-value ] [ safe?: safe? ]

Procedure: array-body array

Procedure: array-indexer array

Procedure: array-safe? array

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

were inserted partially to expose the internals of specialized-arrays,
either to specify non-standard body, indexer, initializer-value, or to
access those parts of a specialized array.

I never use them.  I use

array->specialized-array
specialized-array-share

to make specialized arrays, and were I to use specialized-array directly
I probably wouldn't specify a body or indexer; I may specify a
non-standard (for the storage-class) initializer value.

So, should I remove the procedures that construct specialized arrays
except the two routines:

array->specialized-array
specialized-array-share

Then one can make a simple specialized-array by

(array->specialized-array (array domain (lambda args initial-value))
storage-class)

which will build a full body with the default indexer, etc., and the
current default safety.

Not many people have jumped into this discussion.  Adding features that
people *might* use, but which I haven't used yet, may not be a good idea
if other people aren't jumping in and saying "I like that".

But I do need immutable arrays as the default because that is what
array-map, array-curry, etc., will return.  That's the least they need
to return, and for many applications it's also the most they need to return.

Brad