lib.lists.{hasPrefix,removePrefix}: init

[infinisil]

Description of changes

Adds two new functions:

• lib.lists.hasPrefix :: [ a ] -> [ a ] -> bool: Whether the first list is a prefix of the second list:

  lib.lists.hasPrefix [ 1 2 ] [ 1 2 3 4 ]
  -> true

• lib.lists.removePrefix :: [ a ] -> [ a ] -> [ a ]: Remove the first list as a prefix from the second list, erroring if it's not a prefix:

  lib.lists.removePrefix [ 1 2 ] [ 1 2 3 4 ]
  -> [ 3 4 ]
  lib.lists.removePrefix [ 1 2 ] [ 3 4 ]
  -> <error>

This is distantly part of the path library effort, in order to be able to work with lists of path components.

This work is sponsored by Antithesis ✨

Things done

• Docs
• Tests

[figsoda]

this behavior could be surprising if the user is already familiar with lib.strings.removePrefix

[infinisil]

Oh that's a good point, though I'd argue that this here is the more correct behavior, at least given the name of this function. A version that doesn't fail should maybe be called tryRemovePrefix instead.

[roberth]

ghci> :m + Data.List
ghci> stripPrefix "hi" "bar"
Nothing

Was hoping for resolution, but null would be the third option.

[roberth]

Or avoid completely and use continuation passing.

handlePrefix :: { prefix :: [a], onSuffix :: [a] -> r, onMismatch :: r } -> [a] -> r

[infinisil]

Continuations would be a bit unusual for lib. I like the null option more, Rust also does the same

[infinisil]

And then arguably hasPrefix is barely necessary anymore, because you can just do removePrefix list != null, which would then also be more efficient.

However, the path version of these functions already exist now with the throw semantics: #237610 and #238013

[infinisil]

Yeah I think I'm happy with this design, I think this can be merged.