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

Simon Peyton Jones via Libraries <[email protected]>
Newsgroups gmane.comp.lang.haskell.libraries
Message-ID <AM5PR83MB0353610FDAE8C6035FAF8BE4AD369@AM5PR83MB0353.EURPRD83.prod.outlook.com>
|  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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.