<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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. <br class=""><div class=""><br class=""></div><div class="">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: <<a href="https://pursuit.purescript.org/packages/purescript-partial/3.0.0" class="">https://pursuit.purescript.org/packages/purescript-partial/3.0.0</a>>.)<br class=""><div class=""><br class=""></div><div class="">Discussing if `IsPartial` is a better name seems like a good way to turn this into a drawn out bike shedding argument.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jun 9, 2021, at 9:48 AM, David Feuer <<a href="mailto:david.feuer@gmail.com" class="">david.feuer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">FWIW, partiality annotations seem a bit silly to me when we don't have termination checking.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 9, 2021, 9:45 AM Henrik Nilsson <<a href="mailto:Henrik.Nilsson@nottingham.ac.uk" class="">Henrik.Nilsson@nottingham.ac.uk</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > I'm not sure I really agree with that. There is a rich literature on <br class="">
> effect systems, which decorate types with information about what<br class="">
> effects the function has: exceptions, divergence, IO, and the like. <br class="">
> So type like<br class="">
> head :: Partial => [a] -> a<br class="">
> where 'Partial =>' expresses the fact that calling this function<br class="">
> might lead to a call of 'error' doesn't seem inherently something<br class="">
> that doesn't belong in a type system.<br class="">
<br class="">
I, of course, agree that partiality is an effect. And I have no<br class="">
issues with effects being reflected in the type system.<br class="">
We do that all the time with e.g. monads.<br class="">
<br class="">
If we indeed had something like<br class="">
<br class="">
head :: Partial => [a] -> a<br class="">
<br class="">
that would be both informative and fairly straightforward to<br class="">
explain to students, for example. (Even if it is not clear to<br class="">
me that a type class really is the right way to express<br class="">
partiality of functions: I always thought information about<br class="">
partiality ought to be tied to the function arrow.)<br class="">
<br class="">
My point is that "HasCallStack" strongly suggest a specific approach<br class="">
to monitor the behaviour of a function in case it goes wrong.<br class="">
<br class="">
To me, at least, that is very operational.<br class="">
<br class="">
And I would struggle to explain<br class="">
<br class="">
head :: HasCallStack => [a] -> a<br class="">
<br class="">
beyond saying "it's just something that sometimes will help you<br class="">
with debugging", and deeply hoping no clever student would<br class="">
ask about the lack of similar annotations for other partial<br class="">
functions.<br class="">
<br class="">
Best,<br class="">
<br class="">
/Henrik<br class="">
<br class="">
<br class="">
<br class="">
This message and any attachment are intended solely for the addressee<br class="">
and may contain confidential information. If you have received this<br class="">
message in error, please contact the sender and delete the email and<br class="">
attachment. <br class="">
<br class="">
Any views or opinions expressed by the author of this email do not<br class="">
necessarily reflect the views of the University of Nottingham. Email<br class="">
communications with the University of Nottingham may be monitored <br class="">
where permitted by law.<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
Libraries mailing list<br class="">
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer" class="">Libraries@haskell.org</a><br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br class="">
</blockquote></div>
_______________________________________________<br class="">Libraries mailing list<br class=""><a href="mailto:Libraries@haskell.org" class="">Libraries@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<br class=""></div></blockquote></div><br class=""></div></body></html>