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.edu] *Sent:* 03 March 2018 23:14 *To:* Simon Marlow ; Simon Peyton Jones < simonpj@microsoft.com> *Cc:* Joachim Breitner ; 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 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 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/8 https://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.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.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee