Add safe list indexing operator: !?

[phadej]

MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9511

-- | A total variant of the list index function @('!!')@.
--
-- >>> [2,3,4] !? 1
-- Just 3
-- >>> [2,3,4] !? (-1)
-- Nothing
-- >>> []      !? 0
-- Nothing
--
(!?) :: [a] -> Int -> Maybe a
infixl 9 !?

This operator is reimplemented multiple times on Hackage:

• safe: https://hackage.haskell.org/package/safe/docs/Safe.html#v:atMay
• extra: https://hackage.haskell.org/package/extra/docs/Data-List-Extra.html#v:-33--63-
• relude: https://hackage.haskell.org/package/relude/docs/Relude-List.html#v:-33--33--63-
• Agda: https://hackage.haskell.org/package/Agda/docs/Agda-Utils-List.html#v:-33--33--33-
• Also xmonad-contrib, ShellCheck, tidal, ... https://hoogle.haskell.org/?hoogle=%5Ba%5D+-%3E+Int+-%3E+Maybe+a&scope=set%3Astackage

[treeowl]

I think I learned that operator name from vector, and it's now used in containers as well (did I do that? Memory fuzzy). Yes, I most definitely support this proposal.

[nomeata]

I'd suggest to put it first in the export list and phrase it's doc as if it is the now “normal” indexing operator, while !! is described as a variant of !? for use in situations where you are sure the indexing will succeed.

(But make sure the docs for !! are still useful on their own, e.g. in the haddocks of the Prelude )

[phadej]

@nomeata what you suggest concretely. Please suggest an edit for the exact wording on the MR. I'll let CLC to decide on that.

(Also my English is poor, the less prose I write, the less wrong it is).

[nomeata]

Absolutely right :-)

Since I had to touch parts not in your MR I opened a MR against your branch: https://gitlab.haskell.org/phadej/ghc/-/merge_requests/1

Merge if you like, or just take inspiration, as you like.

[phadej]

@Bodigrim there doesn't seem to be discussion, could you trigger a vote.

[nomeata]

What do think of my suggestions? Did you not want to merge before the committee deliberates on them?
(They are only docs changes, I can also submit them upstream after your change is merged, if that's preferable for some reason)

[phadej]

@nomeata TBH, I don't want to put much work until the whole issue is acknowledged by CLC to start with. Most likely they will comment on MR as well, then I'll come back to it to make final tweaks.

[mixphix]

Wholly in favour, this should have been the "main" operator from the beginning.

As an aside, though it would probably be too much breakage to be worth the hassle now, the fact that (Data.List.!!) has two exclamation points whereas everywhere else (containers, vector, array) the analogue is named (!) has always irked me.

[Bodigrim]

I'm fully in favor of the proposal, but I'd like to see an impact assessment. I imagine some packages may import Data.List unqualified, but define or use (!?) from elsewhere. After all Data.List is a part of Haskell Report, so even additive changes are worth additional scrutiny.

[Bodigrim]

And if we are to do an impact assessment anyway, maybe re-export (!?) from Prelude as well?

[phadej]

I kindly ask others to do impact assessment. I won't do it myself any time soon. (And probably not until haskell/clc-stackage#6 is resolved).

---

@Bodigrim

And if we are to do an impact assessment anyway, maybe re-export (!?) from Prelude as well?

That will definitely break a lot of stuff, e.g. containers and vector to begin with. E.g. https://hackage.haskell.org/package/vector-0.13.0.0/docs/src/Data.Vector.Fusion.Bundle.Monadic.html#%21%3F already hides alot of stuff from Prelude as vector defines name-clashing combinators, but because it's hiding and not importing only what is used, the !? will clash. Similarly containers import Prelude hiding ... in https://hackage.haskell.org/package/containers-0.6.6/docs/src/Data.Sequence.Internal.html#%21%3F

I would suggest these libraries to only import what's used, e.g. like in vec: https://github.com/phadej/vec/blob/0120d4ba43af22824d0bc4ab8c263daac358e5f0/vec/src/Data/Vec/Lazy.hs#L89-L93 to make them less impacted for Prelude additions (and try to avoid Eq (..) imports, as stuff can be added to type-classes), but that's up to their maintainers to do.

[phadej]

FWIW, this addition will break extra: https://hackage.haskell.org/package/extra-1.7.12/docs/src/Data.List.Extra.html
It imports Data.List unqualified (and re-exports it), but has base >=4.9 && <5 bound. So technically is violating PVP, as any addition to Data.List leaks and isn't controlled by extra version. (An example is Data.List.NonEmpty.singleton addition: it leaks through extra's Data.List.NonEmpty.Extra).

To be honest, that really sucks that we have to account for PVP-violating packages. The policy was put in place so the evolution of packages would be easier: addition only changes would break things. But as people don't care, that doesn't work.

It's very sad that in practice any change to base has to be treated as breaking change. That is unmotivating to say the least. I cannot force myself to write patch to the extra package, as it's an issue with how the package is written, not that the change in base is breaking one (per PVP).

I'll leave making this proposal to go through for more motivated people. I hoped it to be a small and quick improvement, but looks like it is not the case.

[emilypi]

To be honest, that really sucks that we have to account for PVP-violating packages.

Agreed. However, Neil is around and can presumably be persuaded to amend their bounds for this kind of quality of life improvement. I'd agree to this proposal.

[phadej]

Agreed. However, Neil is around and can presumably be persuaded to amend their bound

extra is violating PVP as the API depends on the versions of dependencies, so either

• the bounds need to be quite strict, so the API of re-exported modules don't change in the range (this means quite tight lower bound as well as minor upper bounds).
• or better, is to improve the code, so the imports are explicit (qualified or import list), as well as the re-exports.

I hope Neil opinion has changed, but IIRC he was the one of first people to start using base <5 bounds (and no bounds on other stuff, look e.g. at hlint bounds), re https://neilmitchell.blogspot.com/2014/11/upper-bounds-or-not.html

[emilypi]

@ndmitchell? ^