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 Radey Shouman 19 Nov 2001 23:26 UTC

Jussi Piitulainen <xxxxxx@ling.helsinki.fi> writes:

> Radey Shouman writes:

> > 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).

That is not the situation that I had in mind.  In SCM, for example,
all vectors are arrays, but some arrays are not vectors, in
particular, of course, multidimensional arrays are not vectors.  So
the two disjoint types are (R5RS) vectors, and, say, general-arrays.
In this case, no change need be made to VECTOR-REF? or VECTOR, but
ARRAY? must return true for vectors, and ARRAY-REF must behave as
VECTOR-REF for vector arguments.  Some calls to array-constructing
functions return vectors, but array handling code can be written
without knowing or caring whether an array happens to be a vector or
not.  I think this sort of flexibility is useful for implementors.
The only cost is that disjointness cannot be guaranteed between
arrays and vectors -- and I'm not sure why it is even particularly
desireable.

> 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.

Certainly ARRAY-REF and SHARE-ARRAY must do the right thing iff their
array argument is an array in the sense of ARRAY? .  I suggest only
that there is no need to require that (vector? x) return false for all
x such that (array? x) returns true, not that you require any
particular behavior when any vector or string is passed to an array
procedure.

> 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?

On the other hand, until R4RS there was no formal requirement that, for
example, lists and vectors were disjoint.  You seem to be arguing against
a generic sequence type, which I do not propose.