use of vector-map is not srfi-43 compatible?
Linas Vepstas
(08 Aug 2020 17:44 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Wolfgang Corcoran-Mathe
(08 Aug 2020 17:53 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Linas Vepstas
(08 Aug 2020 18:26 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Marc Nieper-Wißkirchen
(08 Aug 2020 18:34 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Linas Vepstas
(08 Aug 2020 19:05 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Shiro Kawai
(08 Aug 2020 19:23 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Wolfgang Corcoran-Mathe
(08 Aug 2020 19:21 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Marc Nieper-Wißkirchen
(08 Aug 2020 19:40 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Shiro Kawai
(08 Aug 2020 20:09 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
John Cowan
(09 Aug 2020 00:27 UTC)
|
Re: use of vector-map is not srfi-43 compatible? Marc Nieper-Wißkirchen (09 Aug 2020 09:08 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Alex Shinn
(11 Aug 2020 01:14 UTC)
|
We could coin the term "fmap" for "finite map" when we view vectors as such maps. Am So., 9. Aug. 2020 um 02:27 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > Indeed, a SRFI for Scheme-vectors-as-maps (as opposed to SRFI 133's vectors-as-sequences) would be an excellent thing to have, and I would definitely put it on a ballot for R7RS-large. I'd wait a bit before starting it so I can modify the Dictionary type class design, however. I haven't yet gained an understanding of the abstraction of an ordered dictionary that is fixed in its keys but mutable in its values. > > As for the term *array*, that is standardly used for a map from a sequence of indices to a value; Scheme vectors-as-maps are a degenerate case of this. Unfortunately we have two array SRFIs, neither of which will be part of R7RS-large until the next ballot. > > > > On Sat, Aug 8, 2020 at 4:09 PM Shiro Kawai <xxxxxx@gmail.com> wrote: >> >> That dual (sequence of value vs map from index to value) doesn't necessarily specific to be of vectors; basically any ordered collection can have such dual, though the access speed order may differ. >> >> So we could provide iterators for both vies orthogonally---the one iterates over values, and the one iterates over indexes and values. It doesn't need to switch views depending on the concrete type (e.g list is former, vector is latter). >> >> >> >> On Sat, Aug 8, 2020 at 9:40 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: >>> >>> Am Sa., 8. Aug. 2020 um 21:21 Uhr schrieb Wolfgang Corcoran-Mathe >>> <xxxxxx@sigwinch.xyz>: >>> >>> > > The SRFI 43 procedure is certainly much more useful than the R7RS/SRFI >>> > > 133 procedure. On the other hand, the R7RS/SRFI 133 procedure does >>> > > seem to follow the general shape of the XXX-map procedures where XXX >>> > > is some type of collection (object). >>> > >>> > Indeed, SRFI 43 vector-map, with its two-argument mapped procedure, is >>> > indeed an odd case among the many "map" functions of Scheme. While >>> > having access to the index is useful, the R7/SRFI 133 versions are >>> > more consistent. >>> >>> On a second thought, the change from SRFI 43 to R7RS wasn't that >>> necessary for consistency: It really depends on how we view a (Scheme) >>> vector. We can either think of a vector as a list of values (which has >>> a random access O(1) getter and setter), or we can think of a vector >>> as a finite map, which maps an interval of natural numbers to Scheme >>> values. >>> >>> SRFI 43's vector-map has adopted the second view, and it is likely the >>> better view. And with this view in mind, the "vector-map" of SRFI 43 >>> is completely regular. See SRFI 125's hash-table-map for another >>> higher-order mapping procedure that is defined for another type of >>> finite map. >>> >>> Ergo, we should have filed a ticket for R7RS.