Re: vectors of homogeneous elements vs strings?

[Dima Pasechnik <d.pasechnik@xxxxxxxxxxxxxx>]

Marc Feeley writes:
 > > It seems to me that the proposal as it is does not go far enough.
 > > 
 > > Would it be more natural to have a "vector of homogeneous elements
 > > tagged with the common type" (something one would maybe call an "array")
 > > 
 > > and consider the types f32, f64, u*, s* mentioned in the proposal as
 > > elements
 > > of the corresponding vectors to be an extesnion of the Scheme numerical
 > > types?
 > > 
 > > In fact, Scheme has one such "array" type, namely "string".
 > 
 > I'm not sure which of the following you are suggesting:
 > 
 > 1) that the proposal be generalized to cover multidimensional vectors,
 >    such as #f32((1.0 2.0) (3.0 4.0) (5.0 6.0)).
 > 
 > 2) that the proposal be generalized to choose the type of element (array
 >    of characters, array of booleans, array of strings, etc).
 > 
 > 3) that the arithmetic functions be generalized to accept multidimensional
 >    vector of numbers (with the zero dimension case being a normal number),
 >    so that (* 2 '#f32(1.0 2.0 3.0)) => #f32(2.0 4.0 6.0).
 > 
 > Which (combination) of these do you mean?

Specifically, I meant 2nd. The arrays of elements, each of known 
fixed length. That is, f32, f46, u8, u16, etc, strings (= arrays of 
7-bit characters), unicode strings, whatever. 

Something that can be seamlessly passed to an external (C-)procedure as
a pointer. 
Certainly, for this purpose u<x>, for x being the wordlength used
by the processor, would suffice, in principle.
But this would introduce a logical inconsistency, as well as
lead to eventual overheads, like moving bytes within words, etc etc.

 > 
 > I'm not sure such features would be good, but even if you convince me
 > that they are good I think it would be a mistake to lump all of this
 > in a single SRFI.  
Well, it seems it would be logical is to have an Array SRFI, and another
SRFI(S) dealing with numbers, and things that can be arranged into
arrays, in general.

The SRFI-4 as it is now look a bit like pieces of two of such SRFIs
artificially put together.


 > I prefer SRFI-4 to be something that many
 > implementors are willing to implement in their system, and some other
 > SRFI can build on top of SRFI-4 to provide more functionality.

Sure. I guess arrays are internally in many Schemes (in most of them
?) 

Best wishes,
Dmitrii