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.