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