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

Hécate <[email protected]>
Newsgroups gmane.comp.lang.haskell.libraries
Message-ID <[email protected]>
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 <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>> -1 for the reasons Henrik has listed
>>
>> Dominic Steinitz
>> [email protected] <mailto:[email protected]>
>> http://idontgetoutmuch.org <http://idontgetoutmuch.org>
>> Twitter: @idontgetoutmuch
>>
>>> On 5 Jun 2021, at 11:10, [email protected] 
>>> <mailto:[email protected]> wrote:
>>>
>>> Re: RFC: Add HasCallStack constraint to partial Data.List
>>>      functions.
>>
>> _______________________________________________
>> Libraries mailing list
>> [email protected] <mailto:[email protected]>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.