On 6/1/21 2:57 AM, Henrik Nilsson wrote:
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 ..., and the use of functions like foldl1 is entirely appropriate, along with a comment in the code explaining why it is safe.
A bit off topic (my apologies for the hijacking), but if you my fellow Haskellers think you understand when the use of such a partial function is safe, I challenge you to look at: https://gitlab.haskell.org/ghc/ghc/-/issues/19917 I thought that e.g. `last (x : xs)` can never throw the error `Prelude.last: empty list` but I had to learn otherwise... (So my conviction is that `List.head`, `List.last` and the like should be eradicated entirely and any step that brings us closer to this goal gets my approval.) On 2021-06-01 11:20, Ryan Trinkle via Libraries wrote:
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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries