which are the highest priority, deal-breaker issues for you?
As I say, I’m uncomfortable, but since I can’t identify anything solidly wrong with it, I don’t want to stand in the way.
Once we have a full implementation, and can see the impacts on the codebase, we may be in a better position to judge. (This is true of every proposal whose impacts across the compiler are hard to predict,
not just this one.)
If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be
avoided both in derived or handwritten equality functions
Well, of course you need at least one mutable field! But having got it, how do we get rid of the unsafe-ptr-eq? Perhaps the thing to do is to update the proposal to whatever the new idea is?
Simon
From: Ryan Newton [mailto:rrnewton@indiana.edu]
Sent: 03 March 2018 23:14
To: Simon Marlow <marlowsd@gmail.com>; Simon Peyton Jones <simonpj@microsoft.com>
Cc: Joachim Breitner <mail@joachim-breitner.de>; ghc-steering-committee@haskell.org
Subject: Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton
I'm certainly fine with going back to discussion.
Simon PJ, much of your review was improvements/edits, and after those are incorporated, which are the highest priority, deal-breaker issues for you?
In particular, the requirement to use reallyUnsafePtrEq# received some
subsequent discussion. If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions. Does that improve your assessment?
Best,
-Ryan
On Thu, Mar 1, 2018 at 3:48 AM, Simon Marlow <marlowsd@gmail.com> wrote: