Ref# equality is just a one-word pointer comparison of course, but unlike reallyUnsafePtrEq, it's always safe.
I haven’t checked, but there is presumably a new primop eqRef# :: Ref# a -> Ref# a -> Bool?
Or (hmm) maybe
eqRef# :: Ref# a -> Ref# b -> Maybe (a ~ b)
a bit like equality on TypeRep.
NNTR: just a suggestion for the proposal.
Simon
From: Ryan Newton [mailto:rrnewton@indiana.edu]
Sent: 05 March 2018 15:42
To: Simon Peyton Jones
Cc: Simon Marlow ; Joachim Breitner ; ghc-steering-committee@haskell.org
Subject: Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton
Dear Simon,
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?
FYI, the proposal as written now also allows constructors with no mutable fields but still offering O(1) physical identity:
data T where MkT :: [Int] -> IO T
deriving Eq
But if this is disallowed, and we have at least one mutable field...
data T where MkT :: mutable [Int] -> IO T
Then the simple observation is that we no longer need to use reallyUnsafePtrEq on two MkT constructors themselves, rather we can simply use Ref# equality on any pair of matching fields:
eq (MkT a) (MkT b) = refEq a b
Ref# equality is just a one-word pointer comparison of course, but unlike reallyUnsafePtrEq, it's always safe.
Perhaps the thing to do is to update the proposal to whatever the new idea is?
Yes, indeed! Let's.
Best,
-Ryan
Simon
From: Ryan Newton [mailto:rrnewton@indiana.edumailto:rrnewton@indiana.edu]
Sent: 03 March 2018 23:14
To: Simon Marlow mailto:marlowsd@gmail.com>; Simon Peyton Jones mailto:simonpj@microsoft.com>
Cc: Joachim Breitner mailto:mail@joachim-breitner.de>; ghc-steering-committee@haskell.orgmailto: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 mailto:marlowsd@gmail.com> wrote:
Simon has provided a detailed review (thanks!) so I think we'll need some time to digest those comments and suggestions and modify the proposal. In light of that shall we put the proposal back into the discussion phase for now?
Cheers
Simon
On 1 March 2018 at 05:17, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:
Hi,
Am Freitag, den 23.02.2018, 15:22 -0500 schrieb Ryan Newton:
Ok, I'm not hearing any strong objections and over the long course of
discussion in various venues, reactions have been mostly positive.
Since committee discussion here has died down, I move to go ahead and
accept this proposal if there are no further objections.
it has been quiet here, but I see new activity on
https://github.com/ghc-proposals/ghc-proposals/pull/8https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F8&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=0V4RHBIaGCfrcdDceNHqqgME11gjUc7o78vGYO2Xfog%3D&reserved=0
Is this a sign that the proposal is not yet as polished as would hope
for?
Joachim
--
Joachim “nomeata” Breitner
mail@joachim-breitner.demailto:mail@joachim-breitner.de
https://www.joachim-breitner.de/https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=q60KMAI7yEupX4KCbr0xqXNcxEeiNqfh6OdyoMLZJEA%3D&reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
