Vote on data structure name Adam Nelson (12 Oct 2020 16:51 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (12 Oct 2020 17:43 UTC)
Re: Vote on data structure name Adam Nelson (13 Oct 2020 13:23 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (13 Oct 2020 13:42 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (13 Oct 2020 13:54 UTC)
Re: Vote on data structure name John Cowan (13 Oct 2020 17:26 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (13 Oct 2020 17:44 UTC)
Re: Vote on data structure name Arthur A. Gleckler (13 Oct 2020 19:45 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (13 Oct 2020 20:00 UTC)
Re: Vote on data structure name John Cowan (13 Oct 2020 20:43 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (14 Oct 2020 06:24 UTC)
Re: Vote on data structure name Arthur A. Gleckler (13 Oct 2020 21:35 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (14 Oct 2020 05:46 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (14 Oct 2020 06:09 UTC)
Re: Vote on data structure name Wolfgang Corcoran-Mathe (13 Oct 2020 17:39 UTC)
Re: Vote on data structure name Jens Axel Søgaard (14 Oct 2020 09:17 UTC)
Re: Vote on data structure name Adam Nelson (19 Oct 2020 17:37 UTC)
Re: Vote on data structure name Arthur A. Gleckler (19 Oct 2020 17:39 UTC)
Re: Vote on data structure name Marc Nieper-Wißkirchen (19 Oct 2020 18:27 UTC)

Re: Vote on data structure name Marc Nieper-Wißkirchen 13 Oct 2020 17:44 UTC

Am Di., 13. Okt. 2020 um 19:27 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> To begin with: In the Germanic languages including English, a compound of two nouns means that the first one modifies the second.  Thus a dog house is a kind of house, whereas a house dog is a kind of dog.  Since the data structure of this SRFI is a kind of vector, I reject "vectorlist" and "arraylist".  The fact that it can implement the list API is neither here nor there.  One could use plain vectors and still implement the list API (excluding mutations) by defining vector-car as (cut vector-ref <> 0) and (cut vector-copy <> 1).

This is exactly the reason why I say that flexvector is wrong. A
flexvector is not a flexible vector because it is not a vector. Of
course, you can work things out so that Scheme vectors can back up the
Scheme list API and vice versa (after all, a pair could be emulated
through a 2-element vector, etc.), but this would be far from natural.
That flexvector-unfold doesn't have to take a length, etc., so the
list (or deque) API comes more natural.

Speaking of linguistics, the word vector comes from Latin, meaning
carrier in the sense what it needs to have something carried from
point A to B. This is still very much the meaning in the natural
sciences. An ordinary Scheme vector fits this picture very well (as it
can be considered as a coordinate vector in some generalized
coordinate system). In the original sense, a vector is *not* a
sequence per se. It can be used to model sequences, of course, as much
as list can be used to model coordinates, but that does not change the
intrinsic meaning of the word.

[...]

> Marc argues for using "buffer" on the grounds that this SRFI describes a kind of gap buffer.  However, the term "gap buffer" does not fit the paradigm explained above, but belongs to a different style of compounds.  A redhead is not a kind of head, but a person with red hair on their head; a farm hand is not a kind of hand, but someone who works on a farm, historically with their hands.  Likewise, a gap buffer is a concrete data structure that serves the function of a buffer (a passive component that both connects and isolates two active components), but may also serve different functions.

I don't understand this point. As Adam explained, he envisions more or
less a concrete type (due to the constraints on the algorithmic
complexities).

[...]

> We are stuck with "bytevector" thanks to R6RS, but R7RS-large was able to restore "hash-table" (as SRFI 125 says, "hashtable" looks like the suffix "-able" applied to the unknown verb "hasht").  I would therefore favor "flex-vector" (and associated types like "u8-flex-vector") slightly over "flexvector", but "flexvector" is also entirely suitable.

I would prefer the hyphened word as well.