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.