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

I want to quickly chime in that I agree with Hécate's rant. The lack of stack traces for things like `head` are a well known problem in Haskell. We have a reasonable solution on hand, namely `HasCallStack`. It seems clear to me that we should use it. 

As already mentioned, PureScript has a `Partial` type class. I have used PureScript a little, and I found the `Partial` type class to be reasonable. I would be curious to hear from professional PureScript developers about their experience with the `Partial` type class. (Also note that it has *excellent* documentation already: <https://pursuit.purescript.org/packages/purescript-partial/3.0.0 <https://pursuit.purescript.org/packages/purescript-partial/3.0.0>>.)

Discussing if `IsPartial` is a better name seems like a good way to turn this into a drawn out bike shedding argument.

> On Jun 9, 2021, at 9:48 AM, David Feuer <[email protected]> wrote:
> 
> 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 <[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
> _______________________________________________
> 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