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 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 mailto:Henrik.Nilsson@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@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries