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

David Feuer david.feuer at gmail.com
Wed Jun 9 13:48:39 UTC 2021

FWIW, partiality annotations seem a bit silly to me when we don't have
termination checking.

On Wed, Jun 9, 2021, 9:45 AM Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk>

>  > I'm not sure I really agree with that.  There is a rich literature on
>  > effect systems, which decorate types with information about what
>  > effects the function has: exceptions, divergence, IO, and the like.
>   > So type like
>  >   head :: Partial => [a] -> a
>  > where 'Partial =>' expresses the fact that calling this function
>  > might lead to a call of 'error' doesn't seem inherently something
>  > that doesn't belong in a type system.
> I, of course, agree that partiality is an effect. And I have no
> issues with effects being reflected in the type system.
> We do that all the time with e.g. monads.
> If we indeed had something like
>     head :: Partial => [a] -> a
> that would be both informative and fairly straightforward to
> explain to students, for example. (Even if it is not clear to
> me that a type class really is the right way to express
> partiality of functions: I always thought information about
> partiality ought to be tied to the function arrow.)
> My point is that "HasCallStack" strongly suggest a specific approach
> to monitor the behaviour of a function in case it goes wrong.
> To me, at least, that is very operational.
> And I would struggle to explain
>     head :: HasCallStack => [a] -> a
> beyond saying "it's just something that sometimes will help you
> with debugging", and deeply hoping no clever student would
> ask about the lack of similar annotations for other partial
> functions.
> 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.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210609/14f1f71d/attachment.html>

More information about the Libraries mailing list