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

"Oliver Charles" <[email protected]>
Newsgroups gmane.comp.lang.haskell.libraries
Message-ID <[email protected]>

On Tue, 8 Jun 2021, at 6:36 PM, Richard Eisenberg wrote:
> 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.

I don't think this is true.

Take:

foo :: Int -> Bool
foo _ = head [True]

Clearly foo is total - it is defined for all of its inputs. That it uses a partial function in its body isn't observable. So it's a shame that IsPartial leaks out.

I guess here you'd have me say

foo _ = partialityIsOk $ head [True]

?

Ollie

_______________________________________________
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.