[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: various comments

This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 contain all messages, not just those from before July 7th, 2015.

Radey Shouman writes:

> I still prefer array-rank, not believing that many will confound it
> with matrix rank. "Rank" is used to specify the number of dimensions
> of a tensor, without any confusion.

I will change it back to array-rank. That's what I inherited from
Bawden; that seems in wide if not universal use; that's my own
preference, too; the argument against it is not too strong, just as
you say; and no alternative is quite succesful.

> "Shape" is a very generic sort of word, likely to be used in other
> contexts -- did you consider "array-shape" ?

Well, array-shape is already in use. It would have to be shape-array
or it could be my own cute contraction of that, shay... (Yes, I've
thought of it, and I hope to have some usably short name accepted.)

> Nevertheless, using the array functions with vector arguments can be
> very convenient, could disjointness from vectors (and even strings)
> be left unspecified?

Disjointness means that the implementation types do not leak through.

If both (vector? arr) and (array? arr) yield #t, then (vector-ref arr
k) must do what (array-ref arr k) does, and so on. To implement that,
one should first have disjoint types, (r5rs-vector? o) and (array? o),
and then make (vector? o) be their sum (or (r5rs-vector? o) (array?
o)), and (vector-ref o k) would dispatch to one of (r5rs-vector-ref o
k) or (array-ref o k).

On the other hand, (array? vec) might yield #f and (array-ref vec k)
could still do the right thing. Cough. Even (share-array vec proc)
could do the right thing. Oho. But strings seem harder - almost a
parallel implementation. And there would be runtime dispatch on
argument types all over the place.

Ok, it seems workable if you like that sort of thing. Scheme has not
taken this route. There is no vector-append (I think). Perhaps there
could be another abstraction layer on top of strings, vectors and
arrays, one that would just pay for the dispatching?

I see no reason to prohibit such things. Perhaps I can avoid too
strong language about it not being allowed.