The name conflict is unfortunate, but I prefer the consistency of R7RS.  Mapping with index is certainly useful, and can be provided with different names.  Gauche has 'map-with-index' family.

On Sat, Aug 8, 2020 at 9:05 AM Linas Vepstas <xxxxxx@gmail.com> wrote:
Yes, sorry, I've been on a short fuse lately, and prone to outbursts.

There seem to be three modes of social communication, these days: (a) say nothing, and people assume you're too stupid to express yourself. (b) be agreeable, and come off as vapid and empty-headed. (c) be abrasive, violate terms-of-service and get kicked/banned.  

--linas

On Sat, Aug 8, 2020 at 1:34 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
The root of the problem does not lie in SRFI 133. Already in
R7RS-small, the procedure "vector-map" is incompatible to SRFI 43.

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

In any case, the name "vector" for the Scheme data structure is not a
very good one (but we cannot change this anymore) because it does not
have to have anything to do with vectors in a typical mathematical
vector space. The name "array" would have been a better fit.

Marc

Am Sa., 8. Aug. 2020 um 20:26 Uhr schrieb Linas Vepstas
<xxxxxx@gmail.com>:
>
> Eh!?
>
> So I'm looking at srfi-133 and it appears to be broken in two ways.  First, its not compatible with srfi-43 by using the same name with different signatures, which (to me) is a fundamental design error (yes, of course, in C++ this is an "overloaded function w/ different type signatures", etc. and is indeed useful in certain cases, but still is often a pitfall for novice programmers. This is one reason why C++ gets a bad rap; it's easy to mis-use by novices.) To encounter this in a srfi is 100% unacceptable. This is deeply just-plain wrong, for what I would hope are obvious reasons known to all programmers? Wtf?  How did this pass review?
>
> Issue two is that by omitting the index of the vector in the argument, this assumes that the vectors always live in a space that is symmetric under the special orthogonal group. How often does that occur? Sure, in high-school physics, where you learn that space is Euclidean and you learn about orthogonal transformations and sine and cosine, OK, but if you go to college, you learn about symmetries other than the special orthogonal group, and the index on the vector plays an important role.
>
> For example: in probability, the space is NOT euclidean, it's a simplex, and the symmetry group of probability theory are the Markov matrices, and not the orthogonal group!  Things like dot-products are NOT meaningful for probabilities, you have to use fisher information, instead, (which is "euclidean" projective under the square root, e.g. quantum wave functions, etc.)
>
> My knee-jerk reaction is to throw srfi-133 in the trash-can as fast as possible. It's broken.
>
> --linas
>
>
> On Sat, Aug 8, 2020 at 12:53 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>>
>> On 2020-08-08 12:43 -0500, Linas Vepstas wrote:
>> > Where is this other vector-map coming from? Why is it colliding with the
>> > one defined by srfi-43?
>>
>> It was changed in SRFI 133, which is now part of R7RS-large.
>>
>> https://srfi.schemers.org/srfi-133/srfi-133.html#Iteration
>>
>> --
>> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>>
>> "Quantum mechanics can be understood as the discovery that information
>> in nature is always finite." --Carlo Rovelli
>
>
>
> --
> Verbogeny is one of the pleasurettes of a creatific thinkerizer.
>         --Peter da Silva
>


--
Verbogeny is one of the pleasurettes of a creatific thinkerizer.
        --Peter da Silva