Add `safe` function to convert partial functions on empty lists to total functions?

[Gabriella439]

The idea is to add this function to Data.List:

safe :: ([a] -> b) -> [a] -> Maybe b
safe f [] = Nothing
safe f xs = Just (f xs)

… which you can use like this:

safe head :: [a] -> Maybe a

safe last :: [a] -> Maybe a

safe tail :: [a] -> Maybe [a]

safe maximum :: Ord a => [a] -> Maybe a

… and so on. Another possible variation on this proposal is to define safe to work on Foldables instead of monomorphic lists:

safe :: Foldable f => (f a -> b) -> f a -> Maybe b
safe f xs
    | null xs   = Nothing
    | otherwise = Just (f xs)

… in which case it would probably go in Data.Foldable instead of Data.List.

[Bodigrim]

I think it's a bit misleading: safe (tail . tail) is not safe at all.

[Gabriella439]

Somebody asked me on Twitter if the generated code for something like safe head would optimize away the error, and the answer is that it appears to do so, at least when the relevant functions are defined within the same module

module Example where

safe :: Foldable f => (f a -> b) -> f a -> Maybe b
safe f xs
    | null xs   = Nothing
    | otherwise = Just (f xs)

safeHead :: [a] -> Maybe a
safeHead = safe head

$ ghc -O2 -ddump-simpl -dsuppress-all Example.hs
…
safeHead
  = \ @ a_a1wg xs_ary ->
      case xs_ary of {
        [] -> Nothing;
        : ds1_a2oE ds2_a2oF -> Just ds1_a2oE
      }

[Gabriella439]

@Bodigrim: The reason I call this function safe is because basically every non-partial base / Prelude alternative calls these functions safeHead, safeTail, etc. I'm following existing widespread naming conventions in the ecosystem

[jneira]

I think it's a bit misleading: safe (tail . tail) is not safe at all.

yep the name should be changed, not sure what could be the alternative

[thielema]

On Sun, 29 May 2022, Gabriella Gonzalez wrote: The idea is to add this function to Data.List: safe :: ([a] -> b) -> [a] -> Maybe b safe f [] = Nothing safe f xs = Just (f xs)

It has nothing to do with safety in the sense of unsafePerformIO or SafeHaskell. It's about total and partial functions. I think it is enough to have a function that checks and converts to Maybe (NonEmpty a) and then apply your NonEmpty functions with 'fmap'.

[Gabriella439]

@Bodigrim @jneira: Another alternative could be to call the function "safer", to indicate that there is still the possibility that the result is partial, but it is less partial than before

[Gabriella439]

@thielema: The goal is to provide something that is ergonomic. What you are proposing is significantly less ergonomic

For example, compare this:

safe head [ 1, 2 ]

… versus your proposal, which would be:

-- Assuming that you were proposing:
-- safe :: [a] -> Maybe (NonEmpty a)
fmap NonEmpty.head (safe [ 1, 2 ])

[JakobBruenker]

-- Assuming that you were proposing:
-- safe :: [a] -> Maybe (NonEmpty a)

FWIW, that function already exists, Data.List.NonEmpty.nonEmpty

[thielema]

On Sun, 29 May 2022, Gabriella Gonzalez wrote: @thielema: The goal is to provide something that is ergonomic. What you are proposing is significantly less ergonomic

My proposal is total, yours is not.

-- Assuming that you were proposing: -- safe :: [a] -> Maybe (NonEmpty a) fmap NonEmpty.head (safe [ 1, 2 ])

NonEmpty.head <$> nonEmpty [1,2] I think it is better to flag common partial functions with HLint than pretending that you can make them "safe".

[tomjaguarpaw]

This doesn't make sense to me. I can't imagine a situation where it would be better to use safe than just to use a full solution, for example Data.List.NonEmpty, instead.

[Gabriella439]

@thielema @tomjaguarpaw: The problem I'm trying to solve is that right now the path of least resistance is to use the partial functions on lists because:

• These partial functions on lists are included in the Prelude by default (unlike their NonEmpty alternatives)
• The corresponding total NonEmpty functions collide with the partial functions from the Prelude, so they have to be imported qualified or the partial functions have to be hidden
• These partial functions work on ordinary lists which (for better or worse) get special syntactic treatment within the language

So I'm not approaching this problem from the standpoint of "there needs to exist a way to compute a safe head". I already know how to do that and it can be done with enough code/imports.

Rather, I'm approaching this from the standpoint of "there needs to be a way to compute a safe head that is as ergonomic as the partial head so that the safe version is now the path of least resistance"

[tomjaguarpaw]

I think that exporting safe versions of all crashing functions in Prelude is better than "safe", which seems to be far too clever for its own good.

[Gabriella439]

@tomjaguarpaw: That was my original idea, but a prior proposal of mine was rejected due to the Fairbairn threshold so this was an attempt to create a proposal that was "Fairbairn threshold"-clean.

Specifically, if you have a safe function then there's no reason to define a safeHead function because of the Fairbairn threshold:

safeHead = safe head

… because (quoting the Wiki page):

In particular any method whose definition isn't much longer than its name (e.g. fooBar = foo . bar) falls below the threshold.

[JakobBruenker]

I would argue that the Fairbairn threshold isn't the only thing that matters here - it seems like a good idea to have a solution that doesn't rely on partial functions, such that you can eliminate them from your code base.

[Gabriella439]

@JakobBruenker: See my comment here: #69 (comment)

The goal here is not to propose that safe head is the blessed way to compute a safe head.

Rather the goal here is to provide an ergonomic total alternative to partial functions to stem the bleeding where people use the partial versions out of convenience.