On Wed, Aug 24, 2016 at 5:40 PM, Bradley Lucier <xxxxxx@math.purdue.edu> wrote:

5) It should be explicitly stated that arrays, specialized arrays, and
intervals are disjoint types.

I'm not going to argue against this, but let me ask "why?" Translations and permutations are not disjoint types. And a specialized-array is an array, so in what way are these types disjoint?

Yes, I meant that arrays and intervals are disjoint with each other and with the standard Scheme types. Mentioning specialized-arrays was pointless.

I introduced two procedures, specialized-array-default-safe? and specialized-array-default-safe?-set!

If specialized-array-default-safe? accepts an optional argument and sets the internal variable based on it, that is the SRFI 39 pattern, which should be familiar.

So, do you think I still need to explain something?

I still think you should say it is an error, but if you don't want to, okay.

I don't know what you mean. The (heavily-macrofied) C code generated by Gambit [...]

The three arguments are stored in registers R1, R2, and R3, the return address is stored in R0, and there's a direct jump to the label for the code for getter, which has been put into ___STK(-5). I don't see any lists.

Gambit is an optimizing compiler, but most Schemes aren't: they take literally the statement in R5RS/R7RS section 4.1.4: "The value stored in the binding of the last variable will be a newly allocated list of the actual arguments left over after all the other actual arguments have been matched up against the other formal arguments." Since the callee may mutate this list, it has to be reconstructed at every call.

Furthermore, what happens in Gambit if there are more dimensions than registers? Also, what happens in case of separate compilation, which will be usual when this SRFI's implementation is in use?

Array-ref and array-set! convenience methods for getting and setting
without explicitly retrieving the getter/setter.

I'm trying to offer alternatives to word-at-a-time array processing in this SRFI.

Absolutely, but they should be there as a fallback. A specific case for such

processing is a system that receives tuples of integers and counts the number

of times each tuple appears using array-ref (to get the previous count) and

array-set! (to increment it).

Whole-array functions: array-fold (fold in lexicographic order),
array-reduce, array-scan (APL), array-count, array-index. All of these
are basically equivalent to converting the array to a list and operating
on the list, but much more space and time efficient.

I don't know what these do: array-scan, array-count, array-index.

I meant to write array-cumulate rather than array-scan.

(array-cumulate proc array dim)

Returns a newly allocated array whose domain is the same as the domain of array. Each element along dimension dim is constructed by reducing (as if by array-reduce) successive prefixes of the elements of array along that axis. (APL scan.)

array-count returns the number of array elements that satisfy a predicate, and index returns the first such element in lexicographic order.

I have array-reduce; how does it differ from array-fold?

Given a sequence of length N, reduce calls its procedure N - 1 times and returns the identity if N = 1. Fold starts with a seed and calls its procedure N times, passing the seed and the element and getting a new seed. Each is useful in different contexts.

John Cowan http://www.ccil.org/~cowan xxxxxx@ccil.org

Dream projects long deferred usually bite the wax tadpole.

--James Lileks