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