[ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton

[Simon Peyton Jones]

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 at indiana.edu]
Sent: 05 March 2018 15:42
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Simon Marlow <marlowsd at gmail.com>; Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee at 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 at indiana.edu<mailto:rrnewton at indiana.edu>]
Sent: 03 March 2018 23:14
To: Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>>; Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>; ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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 at gmail.com<mailto:marlowsd at 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 <mail at joachim-breitner.de<mailto:mail at 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/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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180305/9f2d16b2/attachment-0001.html>