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

[Mario Blažević]

+1 on the proposal, however...

On 2021-05-31 11:10 a.m., Henrik Nilsson wrote:
> ...
> (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.
> ...


I agree with this point, even if I don't find it important enough to 
vote against the proposal. Adding a visible HasCallStack constraint to 
function signatures is a bad thing, because semantically it's nothing 
but noise.

I'd like to propose using a new alias Partial instead. This would 
actually have some educational value, and it would provide some future 
opportunity to treat partial functions separately from other functions 
with the HasCallStack constraint. The compiler might issue a warning on 
their use, to start with, and they might not be considered a part of the 
SAFE subset of the language.

The alternative alternative would be to leave this information out of 
the type signature and use a pragma {-# PARTIAL #-} or {-# CALLSTACK #-} 
instead. This however would take more effort to implement, and I 
actually like the idea of a clear, semantically meaningful, warning in 
the type signature.