BlistList (and UniteBlistList and perhaps more) docs claim it supports arbitrary list inputs, but it doesn't

[fingolfin]

This comes from issue #3148, but is a separate (bigger) problem, as @ThomasBreuer pointed out on PR #3149: The documentation for BlistList says:

returns a new boolean list that describes the list sub as a sublist of the dense list list

This suggest that any dense list may be passed in as first argument. But this is not true in practice:

gap> vec:=ImmutableVector(GF(2),[Z(2),Z(2)]);;
gap> BlistList(vec, [Z(2)]);
Error, Panic: cannot convert <list> (is a object (data)) to a plain list
not in any function at *stdin*:8

The underlying problem is that internally, BlistList(list, sub) (resp. BLIST_LIST) calls UniteBlistList(list, new_all_false_blist, sub) (resp. UNITE_BLIST_LIST), which ultimately ends up calling PLAIN_LIST( list ) in one way or another -- but that fails (which is a good thing).

To me, the real culprit here is PLAIN_LIST( list ), which is "neat" to simplify a lot of kernel code (which now only has to implement a plist version), but the silent conversions it performs lead to all kinds of unexpected nasty surprises (and are a big no-no for HPC-GAP, too). So, my ideal fix for this issue would be to get rid of all uses of PLAIN_LIST in the kernel, and thus of PLAIN_LIST itself. Alas, that may not be feasible, as some code may implicitly rely on the implicit conversions?

Another fix would be to explicitly reject non-internal lists in BlistList and friends (and adjust the documentation to say that), but of course that'd be sad.

In this particular case, a minor optimization would help, in where we detect that the final argument is an empty list, and then don't bother to do anything... But that of course only fixes on minor variant of the real problem.

[ThomasBreuer]

@fingolfin Yes, converting a given list into a plain list is a bad idea.

A natural alternative to PLAIN_LIST would be a function that takes a list
and returns a plain list with its entries and its holes at the same positions as in the given list.
In all situations where the list to work with needs not be identical with the given one
(as in the BlistList case), we would get the abovementioned simplifications
but the code would be safe.

Of course is may be inefficient to create a new plain list in situations as for BlistList;
here one solution could be to turn BlistList into an operation,
then a good method can be provided, depending on the types of the arguments.

[fingolfin]

Actually, often there is no strong need for having a plist at all -- one just has to use ELM0_LIST instead of ELM_PLIST etc. and it all works, with a slight performance for plists. If one is concerned about that (I'd suggest some benchmarking to find out -- I suspect that it most practical cases, it won't matter, but then I don't know all ways people use these Blist functions...), one could duplicate the code -- or perhaps use C++ templates to minimize the code duplication.

[fingolfin]

This was resolved by #3688 and #3871