Re: [lmi] Why have all relational operators for containers?

[Greg Chicares]

On 3/24/21 2:27 PM, Vadim Zeitlin wrote:
> On Wed, 24 Mar 2021 12:20:41 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> For what reason would the standard provide containers with relational
> GC> operators other than '==' and '!='? So that we can sort a vector of
> GC> vectors? Is there a stronger rationale that I don't see?
> 
>  Sorting a vector of vectors is not a bad rationale, but you also wouldn't
> be able to have a set of vectors without operator<(), which would seem
> strange, wouldn't it?

Okay, thanks, that makes sense.

> C++ just doesn't provide vector operations.

That almost makes me long for 'extern "FORTRAN"'.

> What you really want is
> Raku (née Perl 6)

Well, okay, 'extern "Raku"'.

[...snip examples...]
>  Raku operator composability is really very aesthetically pleasant, if
> nothing else.

It's much more. With a rich set of operators that are composable,
we can write code in a terse way the precludes all sorts of errors.
For instance, there aren't many ways for
  $x0 max $x1
to go wrong: there are only three three-character "words", so at
worst we might misspell one of them--but it's so readable that such
errors would stand out:
  $x0 maz $x1

Compare:
  f0r(int i == 0; j <= limit; ++i}
    r = std::max(x0[i], y1[i];)
No one would make that many spelling errors in two lines of C or C++,
but it takes a minute and some concentration to count the exact number
of errors there. Maybe they can't be counted exactly, because the true
intention is not clear. The Raku example says what to do, but in C++,
we have to spell out how to do it.

>  On a more constructive note, I start wonder if you really shouldn't define
> your own lmi::Vec type containing a and forwarding to std::vector. This
> would allow defining vector operations exactly as you want them to be and
> would also, of course, allow not defining comparison operations for this
> type. There should be no overhead in using this type if you can move the
> existing vectors to/from it, so maybe it's something to consider?

I've thought of it. We probably should do so. But right now I've
cleared the decks so I can work on your CI patch.