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>
wrote:
> > 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