List extensions: allow arbitrary objects as list "indices"

[fingolfin]

The changes in this pull request make it possible to implement methods for [], []:=, etc. which take arbitrary objects as "index", not just positive integers. At the same time, it unifies some code and fixes a few places which should have only accepted positive integers, but actually accepted arbitrary integers.

The original motivation for this patch was to make it possible to implement matrix methods which take a pair of integers, like so:

   a[[i,j]] := 2;

to se the entry in row i, column j of the matrix a to 2.
Internally, this would invokes the []:= method with the parameters "a" and "[i,j]", and the method can then set the matrix entry. E.g. for IsMatrixObj objects, it could invoke SetMatElm.

There are other applications, however, e.g. for nicer interfaces to dictionaries:

  dict["key"]  := value;
  if IsBound(dict["key"]) then
    ...

The biggest missing thing in this PR is a documentation update, and some review by somebody other than Steve and me. If the changes look sane, we could merge them now, and coument the changes later.

BTW, for the matrix application, it would be even nicer if we had a language extensions that would allow directly writing

   a[i,j] := 2;

i.e. without the double brackets. But this is apparently harder to achieve (?), and could still be done later, and I think the changes presented here are useful for other applications (such as dictionaries / maps).

[ChrisJefferson]

There is the obvious complaint -- no new tests of this new indexing method!

[ChrisJefferson]

But, I don't have any other comments -- this all looks correct. Also having recently been in the parser, I think supporting x[1,2] won't be that hard (but let's get this in first).

[olexandr-konovalov]

👍 so let's just add some tests and merge this!

[olexandr-konovalov]

@fingolfin this PR can't be merged automatically, and I think PR #83 by @stevelinton depends on your PR. Will you be able to merge it manually, please? I suggest to add tests later to test new syntax in all related PRs.

[fingolfin]

I rebased the series so that it should merge cleanly again. I am now working on some tests. Regarding documentation: I'll need to look at the manual to figure out how difficult that would be.

Oh, and of course the release news would then also have to reflect this, I guess.. ?

[olexandr-konovalov]

Thanks, @fingolfin. Test passed - may be merged now?

Regarding release news - I will create a stab for the "Changes" manual chapter on GAP 4.8, then we may put an overview of all major changes there. Release announcement may be based on that chapter.

[fingolfin]

No, I do not think we should merge syntax extensions before they are documented and tested!

There are already far too many things littered throughout the GAP codebase which somebody added, probably with the plan to document them later, but this then never happened, and they clutter up things.

[olexandr-konovalov]

How this is related to PR #192? Should we close #28 as it is superseded by #192 ?

[stevelinton]

Superceded by #192