RFC: Add HasCallStack constraint to partial Data.List functions.

[Henrik Nilsson]

Hi,

On 06/01/2021 07:50 PM, Andreas Abel wrote:
> A bit off topic (my apologies for the hijacking), but if you my fellow
> Haskellers think you understand when the use of such a partial function
> is safe, I challenge you to look at:
>
> https://gitlab.haskell.org/ghc/ghc/-/issues/19917
>
> I thought that e.g. `last (x : xs)` can never throw the error
> `Prelude.last: empty list` but I had to learn otherwise...

Off topic, yes.

The above statement is a bit disingenuous, though.

As clearly explained when looking into the details, your snippet is
absolutely fine in isolation. But in a context where a program
fragment statically can be proved to fail, an optimizing compiler
can decide that one bottom is as good as any other, and thus it
can fail for a different reason than we might think it should.

I have zero problems with that personally, and would not hesitate
explain that to students either as it makes perfect sense once
we accept that the compiler is not bound to a specific evaluation
order as long as the overall outcome is not changed. And having the
freedom to leave evaluation details, for the most part, to the
compiler is what always attracted me to Haskell and still does,
(three decades or so later, including plenty of "real-world" experience)
And something I try to convey to my students.

But I know that many feel very different about this particular point.

In any case, the problem has very little to do with head, tail,
last as such, so staying away from those specific functions is
certainly not enough to guarantee no surprises.

And besides those, there are other perfectly reasonable functions
like (!!) and foldr1 that I'd definitely would not say never should
be used, just as I would not say that array indexing or integer
divisions must be shunned because they are partial.

Best,

/Henrik




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.