Re: various comments Jussi Piitulainen (17 Nov 2001 14:03 UTC)
Re: various comments Radey Shouman (17 Nov 2001 18:27 UTC)
Re: various comments Jussi Piitulainen (18 Nov 2001 14:50 UTC)
Re: various comments Per Bothner (19 Nov 2001 19:52 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 08:14 UTC)
Re: various comments Per Bothner (20 Nov 2001 18:35 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 19:20 UTC)
Re: various comments Per Bothner (20 Nov 2001 19:33 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 20:14 UTC)
Re: various comments Radey Shouman (21 Nov 2001 03:31 UTC)
Re: various comments Radey Shouman (19 Nov 2001 23:26 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 08:43 UTC)
Re: various comments Per Bothner (20 Nov 2001 19:20 UTC)
Re: various comments Jussi Piitulainen (20 Nov 2001 20:02 UTC)
Re: various comments Per Bothner (20 Nov 2001 21:08 UTC)
Re: various comments Radey Shouman (21 Nov 2001 03:58 UTC)
Re: various comments Jussi Piitulainen (21 Nov 2001 16:52 UTC)
Re: various comments Radey Shouman (21 Nov 2001 03:47 UTC)
Vectors as arrays Re: various comments Jussi Piitulainen (20 Nov 2001 18:03 UTC)
Re: Vectors as arrays Re: various comments Radey Shouman (21 Nov 2001 04:09 UTC)

Re: various comments Jussi Piitulainen 18 Nov 2001 14:50 UTC

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.

Thanks,
--
Jussi