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

[Henrik Nilsson]

hi Hécate,

On 06/09/2021 09:44 AM, Hécate wrote:
> Henrik, Debug.Trace functions requires the use of "unsafePerformIO". Is
> this really the sort of thing we want to promote when we talk about
> "sophisticated debugging support to lazy languages without impacting the
> semantics"?
> Looks like the semantics of pure functional programming are flushed down
> the toilets with that one.

Not at all what I was saying. See

http://www.cs.nott.ac.uk/~psznhn/Publications/thesis-henni.ps.gz

for but one example.

No unsafePerformIO needed, as it happens

Tool support is obviously needed, though, but of pretty much exactly the 
kind that is already present for profiling.

(Not that unsafePerformIO would be a problem as an internal
implementation technique, for that matter.)

 > As a general comment, it is honestly appalling how RFCs like that
 > trigger such circlejerks that are so utterly disconnected from
 > reality.

With respect (and I always do try to maintain a respectful tone),
I think that is a deeply unfair comment.

I do not see what the purported reality disconnect is with observing
that HasCallStack is an operational annotation that has no place
in declarative type signatures (as others also have observed),
with observing that there are implications for education that
ought to be considered, that whenever types of basic functions
that have been around since Haskell was created changes, that
has implications for no end of books and other literature,
and reminding people that there are non-intrusive techniques,
for which the required infrastructure pretty much is in place,
that would provide a comprehensive solution to proper stack
traces.

On the contrary, this broader perspective is what is needed
to properly account for "reality", and soliciting that
perspective is the very point of an RFC, I would have thought.

And given the above comment that seems to suggest that Debug.Trace
and unsafePerformIO are the only ways to go about debugging in
pure languages, maybe the last point about reminding the community
about alternatives is particularly apt.

Respectfully,

/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.