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

The sad part is seemingly it discards having an informative stack trace?

On Wed, Jun 9, 2021 at 10:16 AM Simon Peyton Jones via Libraries <
[email protected]> wrote:

> |  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.)
>
> OK -- that sounds promising.  It's what Richard suggested earlier, and
> sounds pretty good to me.
>
> Simon
>
>
> |  -----Original Message-----
> |  From: [email protected] <[email protected]>
> |  Sent: 09 June 2021 14:45
> |  To: Simon Peyton Jones <[email protected]>; Henrik Nilsson
> |  <[email protected]>; [email protected]
> |  Subject: Re: RFC: Add HasCallStack constraint to partial Data.List
> |  functions.
> |
> |   > 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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries