Preserve class when subsetting a list

[d-torrance]

Closes: #3812

Before

i1 : [a,b,c,d]_{1,3}

o1 = {b, d}

o1 : List

After

i1 : [a,b,c,d]_{1,3}

o1 = [b, d]

o1 : Array

[d-torrance]

It's so weird that the cmake-ubuntu builds keep failing fetching the PPA information but the autotools-ubuntu ones are fine...

The only reason we need the PPA for the builds is msolve -- its version in Ubuntu 24.04 is too old. The next LTS, Ubuntu 26.04, was just released a few days ago and I imagine GitHub will add runners soon. Then we can drop the PPA from the builds.

[mahrud]

Why not this?

Suggested change

	VisibleList _ List := VisibleList => (x,y) -> (
	L := class x;
	new L from apply(splice y, i -> x#i))
	VisibleList _ List := VisibleList => (L, inds) -> new class L from apply(splice inds, i -> L#i)

[mahrud]

Also, often I've wished L_(1..3) would also work, so I don't have to do L_(toList seq). I don't think this conflicts with any other notation ....
It might even be useful if X_Y produced an object with the type of Y instead.

[d-torrance]

I split it up over a few lines so it wouldn't be too wide.

Defining it as VisibleList_VisibleList would make sense so we can use sequences. I feel like it should have the same class as the first argument.

[mahrud]

Even with splitting, new class L from apply(splice inds, i -> L#i)) is short, but I'm being too nitpicky :) (part of why I mentioned is I don't like just using "x" or "y" as variables.

[mahrud]

Very unrelated to this PR, but would be nice to have toArray also. new Array from blah is too long XD

[mahrud]

Since the builds failed again and needs fixing still, I'll point out that I think I prefer limiting to just List and Sequence for indices, not arbitrary visible lists. e.g. perhaps L_[...] or L_<|...|> could have other uses in the future.

[d-torrance]

Discussed with Mike and Anton. Will remove the == change but keep the subsetting change.

Later: == w/ different types on each side should be an error, even w/ two d-level List objects of different classes (or something else - open to discussion)

[mahrud]

Oh I thought you were just fixing the error to be more sensible. You should still do this I think, no?

[d-torrance]

Yeah, definitely. Right now we have:

i1 : {1, 2, 3} == (1, 2, 3)
stdio:1:10:(3):[1]: error: expected argument 2 to be a visible list

i2 : {1, 2, 3} == [1, 2, 3]

o2 = false

Either they should both be errors or both false. The current state of this PR is for them to be both false, but after discussion both errors would be better. But that will be a future PR

[pzinn]

why should we have VisibleList_Sequence? it's not obvious to me that this is a sensible syntax, and we may want to reserve it for a different purpose in the future.

[d-torrance]

This was a request from @mahrud (#4242 (comment))

[pzinn]

I don't think this makes sense -- in the example, L_{1..3} works just fine and is not longer than L_(1..3) (in particular, doesn't require toList). Overall I think this is a mistake and should be removed.

[d-torrance]

Ah, yeah -- it calls splice on the list, so nested sequences get flattened out. Neat.

Since you're opposed, I'll go ahead and remove it for now and maybe we can debate the merits of subsetting with sequences at some point in M2internals or something

[mahrud]

I explained why it's useful above, namely avoiding the need to do X_(toList Y). @pzinn do you have a particular purpose in mind?

[mahrud]

Oh you're saying L_{seq} also works. Fair enough.