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

[David Feuer]

On Tue, Jun 8, 2021, 1:39 PM Richard Eisenberg <lists at richarde.dev> wrote:

> I've been very much of two minds in this debate: On the one hand, having
> these constraints is very practically useful. On the other, what we're
> doing here is very un-Haskellish, in that we're letting operational
> concerns leak into a declarative property (a function's type).
>

Yes, this is quite awkward. We have here a tension:

1. The *operational* type, indicating the calling convention. This includes
HasCallStack.

2. The "denotational" type (for want of a better term), indicating what
users (generally) have to know about the function. This does not include
HasCallStack.

HasCallStack is already partially magical (and the rest is library
internals). Maybe we should take that further, and remove HasCallStack from
type signatures. Pardon my fake syntax:

error :: forall {rep} (a :: TYPE rep). String -> a
error @(_ :: class HasCallStack) msg = ...

head :: [a] -> a
head @(_ :: class HasCallStack) [] = error ...

This has two downsides I see:

1. It's no longer so easy to tell whether a function takes a call stack.
But that's kind of the point; we usually don't want to think about that.
2. It's no longer so obvious that undefined is a function. But ... we very
rarely care that it is.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210608/3890243f/attachment.html>