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

[Ryan Trinkle]

I certainly agree that a more systemic solution would be preferable.
However, none have been forthcoming in the 15 or so years I've been
using Haskell.  The use of partial functions in library code has been
one of the few consistent sources of multi-day debugging exercises in
Haskell that I've seen, and even cutting that down in an ad-hoc way
would be valuable, since there are probably a dozen functions that
account for 80% of the debugging hours (I'd certainly like to see
fromJust on that list, for example).

I agree with your point about education, but I do wonder whether these
functions should be taught at all.  What is their purpose, really?  I've
found little downside (and a lot of upside) to simply never using any of
these functions.  (The times when I get bitten by them are when they are
used in libraries I use.)

On 5/31/21 11:10 AM, Henrik Nilsson wrote:
> Hi,
>
> > I'm proposing to add HasCallStack constraint for partial functions
> > in base package for functions in Data.List and Data.List.NonEmpty:
> >
> > - head, tail, init, last, ...
> > - foldr1, foldl1, maximum, minimum, ...
> > - (!!)
>
> (Strong) -1 from me.
>
> Reasons:
>
> It's been well known for close to three decades(!) that it is perfectly
> possible to add sophisticated debugging support to lazy languages like
> Haskell without impacting on the language semantics or formulation of
> its libraries. The existing tracing and profiling mechanisms of GHC
> are examples of this.
>
> Thus, letting one particular debugging mechanism becoming manifest
> at the type level of standard library functions is both very worrying
> and hugely disappointing. Especially when predicated on the compiler
> and specific aspects of the implementation strategy being sufficiently
> sophisticated to mitigate the runtime overhead.
>
> Moreover, the proposal is extremely partial. E.g. what about types like
> Maybe or Either, with functions fromJust/fromLeft/fromRight?
> Or integers and division? Or arrays and array indexing? And the list
> goes on.
>
> Once this first step has been taken, I fear it is only matter
> of time before we have constraints like this all over the core
> libraries. Is there a principled end-point to this? I cannot see
> one.
>
> Further, as far as I could see, the impact of the scheme also relies
> on cooperation of library authors, raising questions about just how
> much practical benefit the proposal would bring.
>
> It also appears that the impact on teaching has not been considered.
> Haskell's type classes are already often cited as a major impediment
> when using Haskell as a medium of instructions for beginners because
> it is quite difficult to teach the basics without also giving
> quite a comprehensive introduction to type classes, which makes for
> a steep initial learning step. Possibly too steep, in the opinion
> of many educators. And even if a carefully structured narrative
> can minimize what needs to be covered about type classes
> initially, students will inevitably come across them as soon as
> they try their hand at writing some actual code.
>
> The present proposal already exacerbate this problem, and if the
> idea were to become even more widespread, e.g. to provide good
> stack traces also for division by zero, out of bounds errors, or
> attempts to get something out of Nothing, it would be even worse.
>
> While the value of decent stack traces is undisputed, this is
> definitely the wrong way to go about addressing that issue.
> And the objection is not about letting the perfect be the enemy
> of the good, as suggested somewhere in the preceding discussions,
> but about not letting the manifestly imperfect getting a
> de facto irreversible foothold and then spreading from there.
>
> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries