Re: RFC: Add HasCallStack constraint to partial Data.List functions.
David Feuer <[email protected]>
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Message-ID | <CAMgWh9vVCqxaJ1Ka1TGFBZi0a+TtTwtCLqJHi8tJ3k0caY6O5g@mail.gmail.com> |
On Tue, Jun 8, 2021, 1:39 PM Richard Eisenberg <[email protected]> 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. > _______________________________________________ Libraries mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries