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

[David Feuer]

head and tail are basic ... in Lisp. In Haskell, they're effectively used
... *checks notes* ... in the MonadFix instance for []. Almost every good
use of (!!) is for something that really should use an infinite list

  data Stream a = a :< Stream a

but that uses a list for convenience.

On Fri, Jun 4, 2021, 12:50 PM Henrik Nilsson <
Henrik.Nilsson at nottingham.ac.uk> wrote:

> Hi Ryan,
>
>  > 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.
>
> Fair point about not choose to bear costs *just* in the hope something
> better comes along. My main point was that the suggested approach in my
> opinion is too un-principled and too partial to have much appeal,
> especially when it is clear that solutions that are both principled
> and complete do exist, and that most of the required machinery is
> already in place.
>
> But others clearly disagree, although, in part for reasons that has
> more to do with philosophy of language design and partiality vs.
> totality, than the practical need to pinpoint the site of errors
> in programs in a language that was designed to allow partial
> functions.
>
>  > 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 -
>
> Just for the record, I have one feet solidly in each of the
> educational and industrial camps.
>
>  > 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.
>
> Well, head and tail *are* basic. There are no two ways about that.
> But there were also other affected functions, like
> list indexing, or indexing into other collection types,
> that I at least consider entirely reasonable (as long as the
> time complexity is taken into account properly when that is
> a consideration).
>
> The basic points I were making, to recap and rephrase, were that
>
> a) Type classes in general are considered a bit of a hurdle
>     when teaching beginners. Thus, more of them (for basic
>     functions) is not helpful.
>
> b) I don't find mixing what amounts to operational annotations
>     to assist with particular approaches to debugging into the
>     types of functions to be appealing at all.
>
>     In fact, I feel rather strongly that it is a fundamentally flawed
>     approach.
>
>     The types should tell me something important about what things are.
>     Not about how to go about debugging them.
>
> Best,
>
> /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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210604/01348d61/attachment.html>