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

Ryan Newton rrnewton at indiana.edu
Mon Mar 5 15:42:20 UTC 2018


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]
> *Sent:* 03 March 2018 23:14
> *To:* Simon Marlow <marlowsd at gmail.com>; Simon Peyton Jones <
> simonpj at microsoft.com>
> *Cc:* 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
>
>
>
> 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> 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>
> 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
>   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
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> 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/8021d2a2/attachment-0001.html>


More information about the ghc-steering-committee mailing list