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

[Henrik Nilsson]

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.