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 <libraries@haskell.org> 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: Henrik.Nilsson@nottingham.ac.uk <Henrik.Nilsson@nottingham.ac.uk>
|  Sent: 09 June 2021 14:45
|  To: Simon Peyton Jones <simonpj@microsoft.com>; Henrik Nilsson
|  <Henrik.Nilsson@nottingham.ac.uk>; libraries@haskell.org
|  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
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries