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

[Ryan Trinkle]

Hi Henrik,

Regarding making systemic improvements less likely: I don't think we
should choose to bear costs, simply because the pain of those costs may
potentially motivate us to come up with something better.  If Oleg's
proposed solution actually makes it *harder* for -xc improvements to be
made, then I would certainly agree that we shouldn't use it as a stopgap.

Regarding teaching: although I don't want to usurp the role of the
educator - and it would be fantastic to get some input from actual
educators on this thread - I don't think we should simply say that
because these things exist, their teachability is important.  Let's let
people tell us, specifically, that they consider `head` to be important
to teaching students, and why, and then we can make sure it's suitable
for them.

I agree that partiality is sometimes necessary in real-world code,
although we have gotten very far at Obsidian with banning partial
functions like foldl1 in favor of explicit calls to `error`, which are
typically O(1) more work for the developer, and effectively encodes the
comment you mentioned for why it is safe (i.e. by saying why the error
ought to be impossible).  That also means that, when the developer is
wrong about the impossibility of the condition, which seems to be a
fairly common occurrence, there is at least some hope of tracking down
the production error message to something meaningful.


Best,

Ryan

On 6/1/21 2:57 AM, Henrik Nilsson wrote:
> Hi,
>
> Ryan Trinkle wrote:
>
> > I certainly agree that a more systemic solution would be preferable.
> > However, none have been forthcoming in the 15 or so years I've been
> > using Haskell.
>
> The sad irony of changes like the proposed one is, of course, that they
> make a systematic solution less likely to happen (the systematic
> solution in this case being some engineering effort around the existing
> -xc mechanism to lower the cost and hassle of using it, which seems to
> be the reason is it judged not to suffice at present).
>
> > I agree with your point about education, but I do wonder whether these
> > functions should be taught at all.  What is their purpose, really?
> > I've found little downside (and a lot of upside) to simply never
> > using any of these functions.  (The times when I get bitten by them
> > are when they are used in libraries I use.)
>
> I'd personally not like to suggest to educators what they should or
> should not teach: the context, specific learning goals, and students
> vary widely.
>
> In any case, these functions have been in Haskell since its inception,
> and so are deeply ingrained in books, literature, and code.
>
> Moreover, I do not find functions like (!!) or foldl1 to be unreasonable
> at all. List indexing is as reasonable as array indexing. And foldl1 and
> foldr1 are very useful when folding over lists where the type of the
> elements have no neutral element.
>
> In my day to day work, we also avoid using these partial functions
> whenever we can, and usually it is not that difficult. But every now and
> then the reason, say, a list is non-empty is just a little bit too
> subtle to capture in a reasonable way (benefit outweighing the cost)
> by a suitable design and/or at the type level, and the use of functions
> like foldl1 is entirely appropriate, along with a comment in the code
> explaining why it is safe.
>
> Hécate wrote:
>
> > I think the vast majority of the functions presented in this proposal
> > have a total counterpart, whether it is a function or a code pattern.
> > We have NonEmpty in `base`, as well as ExceptT/MonadError and
> > Exceptions to allow us to mimic such a cul-de-sac in the code with
> > appropriate annotations around it.
>
> While NonEmpty is useful on occasion, many operations on them
> of course returns a possibly empty list, and then the original
> problem is back.
>
> And having to resort to monadic code when it is completely clear
> that a piece of code using, say, a foldl1 or (!!) is safe, can be
> quite costly (major refactoring could be implied) as well as
> obscuring the nature and purpose of the code.
>
> So, again, while partial functions obviously should be use with
> great care, they certainly have perfectly legitimate uses in
> a practical setting in most languages in wide-spread use, including
> Haskell, and I'd again be somewhat wary of "tell the user: Don't use
> that function!" as Henning phrased it.
>
> Artem Pelenitsyn wrote:
>
> > As for educational uses, it's been clear for a while now that
> > industrial uses are at odds with educational ones (and both may be
> at > odds with research ones). In my opinion, we can't hold back one for
> > another. Rather, we need to figure out the right story for both.
> > There's a (seemingly) valid industrial use case for the HasCallStack
> > mechanism in base that is not covered by -xc, as explained by others
> > above. As for education, two possible avenues are 1) to explore
> > custom "educational" Preludes (tried by several people, the
> CodeWorld > project first comes to mind), and 2) custom error
> messages, which are > being reworked just as we speak by Richard,
> Alfredo and others.
>
> Different preludes for different classes of users are brought up from
> time to time.
>
> I think there are significant down-sides to this. And further, I am not
> at all convinced that "industrial users" are such a homogeneous group
> that they'd all agree on what they'd want in the prelude.
>
> Both of these suggest than rather than a separate prelude for
> education/beginners, the standard prelude should be kept simple/be
> left alone, and groups with specific needs and sufficient knowledge
> should pay the price for using refined preludes if they make
> an informed choice that the benefits of doing so outweigh the costs.
>
> But I digress.
>
> /Henrik
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please contact the sender and delete the email and
> attachment.
> Any views or opinions expressed by the author of this email do not
> necessarily reflect the views of the University of Nottingham. Email
> communications with the University of Nottingham may be monitored
> where permitted by law.
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries