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

[Richard Eisenberg]

I've been very much of two minds in this debate: On the one hand, having these constraints is very practically useful. On the other, what we're doing here is very un-Haskellish, in that we're letting operational concerns leak into a declarative property (a function's type). The reason we're doing this is another un-Haskellish thing -- partiality -- but that ship has sailed.

So, may I propose a slightly different way forward?

Instead of adding a HasCallStack constraint on these functions, add an IsPartial constraint. For example:

> head :: IsPartial => [a] -> a

This is slightly awkward, still, because IsPartial is a class-constraint-like-thing, but it has no parameter. But it has a few very nice properties:
* IsPartial is declarative: it describes a property of the function without worrying about its operation.
* If we think about the way constraints propagate, IsPartial has the right semantics: the caller of a partial function would itself become partial.
* We have some room in how we relate IsPartial to HasCallStack. We could say that IsPartial is just a synonym for HasCallStack (e.g. with type IsPartial = HasCallStack). But perhaps better would be to somehow give users control over whether they want the HasCallStack mechanism to be able to solve IsPartial constraints. Maybe some users would prefer not to be able to satisfy IsPartial constraints immediately, but instead to require an acknowledgement in their code that they're doing something partial. For example:

partialityIsOK :: String -> (IsPartial => r) -> r
elements xs = map (partialityIsOK "lists returned by `group` are always non-empty" head) (group xs)

The partialityIsOK function has a more involved type than I would like, but it's very usable in practice. Of course, such a thing only makes sense if IsPartial cannot automatically be satisfied. Getting this to work properly probably needs an extra language feature (maybe make IsPartial magically built-in?), but it might provide a declarative, yet operationally practical way forward here.

Richard

> On Jun 6, 2021, at 12:49 PM, Dominic Steinitz <dominic at steinitz.org> wrote:
> 
> -1 for the reasons Henrik has listed
> 
> Dominic Steinitz
> dominic at steinitz.org <mailto:dominic at steinitz.org>
> http://idontgetoutmuch.org
> Twitter: @idontgetoutmuch
> 
>> On 5 Jun 2021, at 11:10, libraries-request at haskell.org <mailto:libraries-request at haskell.org> wrote:
>> 
>> Re: RFC: Add HasCallStack constraint to partial Data.List
>>      functions.
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210608/1f608d8f/attachment.html>