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