Not at all.  You should have a fast path as Olin does, though, for when there is only one vector (avoids calling `apply`).

On Thu, Aug 1, 2019 at 5:17 PM Shiro Kawai <xxxxxx@gmail.com> wrote:

If it's just a matter of reference implementation I can contribute.  Do you mind?

On Thu, Aug 1, 2019 at 10:43 AM John Cowan <xxxxxx@ccil.org> wrote:

Good point.  The -any and -all don't work with multiple @vectors because it adds cost and I'm lazy (unlike Olin, apparently).

On Thu, Aug 1, 2019 at 4:20 PM Shiro Kawai <xxxxxx@gmail.com> wrote:

Ah, I see.

Sure it is more flexible to make it take equality predicate.  Another practical (but not reflective) situation is to compare inexact numbers with approximately-equal test.

Since typing extra = for typical cases isn't too much and is consistent with srfi-133, I'm ok with having element-equality predicate.

Regarding srfi-133 compatibility, is there a reason that @vector-any and alike take only one @vec?

On Thu, Aug 1, 2019 at 4:21 AM John Cowan <xxxxxx@ccil.org> wrote:

I feel conflicted about it, which is why the two are different, probably.

= is the obvious equality predicate, though technically "not =" is also meaningful, though not an equality predicate (it is not reflexive).  On the other hand, there may be some weird applications for other numeric predicates that I haven't thought of, and it's kind of annoying for @vector= to have a different signature from vector=.

What should I do?

On Thu, Aug 1, 2019 at 4:51 AM Shiro Kawai <xxxxxx@gmail.com> wrote:

The spec says

  (@vector= @vec ...)

and the element-wise comparison is done by '='.

The reference implementation has

  (@vector= elt= . vecs)

I assume the spec is correct.