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

[Henrik Nilsson]

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.