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