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

Hécate hecate at glitchbra.in
Wed Jun 9 06:40:42 UTC 2021


At this point I think it is interesting to see what our cousins have 
done to address the problem of invisible partiality.

PureScript has the `Partial` typeclass¹.  I suggest we ask their 
community how they feel about it, what has been their experience and if 
they could do it differently, what it would be.

---

¹ https://pursuit.purescript.org/packages/purescript-partial/3.0.0

Le 08/06/2021 à 19:36, Richard Eisenberg a écrit :
> 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 
>> <mailto: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 <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 <mailto:Libraries at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210609/327d4fb3/attachment.html>


More information about the Libraries mailing list