SRFI 214: Flexvectors Arthur A. Gleckler (07 Oct 2020 17:10 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 09:41 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 09:59 UTC)
Re: SRFI 214: Flexvectors Adam Nelson (08 Oct 2020 12:10 UTC)
Nomenclature Lassi Kortela (08 Oct 2020 12:19 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 12:19 UTC)
Nomenclature Lassi Kortela (08 Oct 2020 12:26 UTC)
Re: Nomenclature Marc Nieper-Wißkirchen (08 Oct 2020 12:31 UTC)
Re: Nomenclature Lassi Kortela (08 Oct 2020 12:50 UTC)
Re: Nomenclature Marc Nieper-Wißkirchen (08 Oct 2020 13:01 UTC)
Flexvectors vs subtyping Per Bothner (08 Oct 2020 17:23 UTC)
Re: Flexvectors vs subtyping Arthur A. Gleckler (08 Oct 2020 17:29 UTC)
Re: Flexvectors vs subtyping Adam Nelson (08 Oct 2020 17:32 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 17:46 UTC)
Re: Flexvectors vs subtyping Adam Nelson (08 Oct 2020 17:56 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 19:21 UTC)
Re: Flexvectors vs subtyping Lassi Kortela (08 Oct 2020 20:09 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 20:51 UTC)
Re: Flexvectors vs subtyping Lassi Kortela (08 Oct 2020 21:23 UTC)
Re: Flexvectors vs subtyping Arvydas Silanskas (12 Oct 2020 09:58 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 20:35 UTC)
Re: Flexvectors vs subtyping Per Bothner (08 Oct 2020 17:54 UTC)
Re: Flexvectors vs subtyping Lassi Kortela (08 Oct 2020 20:39 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 17:32 UTC)
Re: SRFI 214: Flexvectors Adam Nelson (08 Oct 2020 17:35 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 18:05 UTC)
Re: SRFI 214: Flexvectors Adam Nelson (08 Oct 2020 18:34 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 18:57 UTC)
Flexvector computational complexity Adam Nelson (08 Oct 2020 17:47 UTC)
Re: Flexvector computational complexity Marc Nieper-Wißkirchen (08 Oct 2020 19:04 UTC)
Re: Flexvector computational complexity John Cowan (08 Oct 2020 19:18 UTC)
Re: Flexvector computational complexity Adam Nelson (08 Oct 2020 19:40 UTC)

Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen 08 Oct 2020 09:40 UTC

Adam,

thank you very much for this great SRFI. It is indeed filling a void
in the landscape of Scheme data types.

I would like to comment on three things:

(1) Thank you for detailing your choice of the word "flexvector". I
cannot, however, agree with your conclusion because three points speak
against the term.

First of all, it doesn't fit the existing vector types in Scheme.
These are prefixed by the type of element (e.g. byte or u16) and all
have a fixed length. On the other hand, a "flexvector" is not a vector
that stores flexes, nor it is a vector, for which the length is an
invariant. It makes a lot of sense to have, at some point, dynamic (or
"flexible") bytevectors as well. You would get a double prefix:
"byteflexvector" ...

The second reason why I don't think that "flexvector" is a good choice
is that the term "flexible" has already been taken by the C language,
which has flexible array members in a struct. These, however, are more
like records with a Scheme vector as their last element.

Finally, apart from the algorithmic complexity (which is not
guaranteed, by the way, see (2)), the "flexvectors" behave much more
like lists and not like vectors, so "flexvector" is a bit of a
misnomer. (Especially when we think of where the term "vector"
originally comes from.) While not shorter, "arraylist" looks better
than "flexvector" in this regard.

It would be nice if we could find a new term as sexy as "list",
"array", and "vector". What about "(dynamic) field", for example?

(2) Scheme does not guarantee O(1) access for vector elements. You can
hardly promise more, I guess. So it is probably safer to write that
flexvectors have an access time comparable to vectors.

(3) I would drop the reference to SRFI 10 and won't use its notation
"#,". Since the R4RS (from 1991), the reader syntax "#," has been used
as an abbreviation for "unsyntax" as much as "," is an abbreviation
for "quote". This not only makes SRFI 10 (from 2000) untenable but can
also confuse readers of your SRFI. Like other SRFI authors, I would
use pseudo-lexical syntax like

#<flexvector 1 2 3>

to denote flexvectors in the output of examples.

Marc

Am Mi., 7. Okt. 2020 um 19:11 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> Scheme Request for Implementation 214,
> "Flexvectors,"
> by Adam Nelson,
> is now available for discussion.
>
> Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-214/.
>
> You can join the discussion of the draft by filling out the subscription form on that page.
>
> You can contribute a message to the discussion by sending it to xxxxxx@srfi.schemers.org.
>
> Here's the abstract:
>
> A flexvector, also known as a dynamic array or an arraylist, is a mutable vector-like data structure with an adjustable size. Flexvectors allow O(1) random access, O(1) insertion/removal at the end, and O(n) insertion/removal elsewhere. This SRFI defines a suite of operations on flexvectors, modeled after SRFI 133's vector operations.
>
> Regards,
>
>
> SRFI Editor