For what it's worth, I put this in my .zshrc cleancore=(-ddump-simpl -dsuppress-coercions -dsuppress-var-kinds -dsuppress-idinfo -dsuppress-type-signatures -dsuppress-type-applications)
and then ghc $cleancore -c Foo.hs but this is mainly for the use case of "I wonder if this thing is getting optimised the way I hope, let's have a look at the Core". There's also this little tool which is aimed at the same kind of thing: https://github.com/shachaf/ghc-core So I'd say there's definitely a demand for something, but it's not entirely clear what the something is. Someone could make a proposal... On Sat, 6 Oct 2018 at 00:12, Simon Peyton Jones via ghc-devs < [email protected]> wrote: > Like Richard I use the uniques all the time. > > I'd prefer to leave it as-is, unless there is widespread support for a > change > > S > > > | -----Original Message----- > | From: ghc-devs <[email protected]> On Behalf Of Ömer Sinan > | Agacan > | Sent: 05 October 2018 20:02 > | To: [email protected] > | Cc: ghc-devs <[email protected]> > | Subject: Re: Shall we make -dsuppress-uniques default? > | > | > What do you say to GHC to get it to print the uniques that you don't > | like? > | > | I usually use one of these: -ddump-simpl, -dverbose-core2core, > | -ddump-simpl-iterations, -ddump-stg. All of these print variables with > | unique > | details and I literally never need those details. Rarely I use -ddump-cmm > | too. > | > | Agreed that having different defaults in different dumps/traces might > | work .. > | > | Ömer > | > | Richard Eisenberg <[email protected]>, 5 Eki 2018 Cum, 21:54 > | tarihinde şunu yazdı: > | > > | > I'm in the opposite camp. More often than not, the biggest advantage of > | dumps during GHC development is to see the uniques. Indeed, I often > | ignore the actual names of variables and just work in my head with the > | uniques. > | > > | > Perhaps the more complete answer is to fine-tune what settings cause > | the uniques to be printed. -ddump-xx-trace should almost certainly. > | Perhaps other modes needn't. What do you say to GHC to get it to print > | the uniques that you don't like? > | > > | > Richard > | > > | > > On Oct 5, 2018, at 2:48 PM, Ömer Sinan Ağacan <[email protected]> > | wrote: > | > > > | > > I asked this on IRC and didn't hear a lot of opposition, so as the > | next step > | > > I'd like to ask ghc-devs. > | > > > | > > I literally never need the details on uniques that we currently print > | by > | > > default. I either don't care about variables too much (when not > | comparing the > | > > output with some other output), or I need -dsuppress-uniques (when > | comparing > | > > outputs). The problem is I have to remember to add -dsuppress-uniques > | if I'm > | > > going to compare the outputs, and if I decide to compare outputs > | after the fact > | > > I need to re-generate them with -dsuppress-uniques. This takes time > | and effort. > | > > > | > > If you're also of the same opinion I suggest making -dsuppress- > | uniques default, > | > > and providing a -dno-suppress-uniques (if it doesn't already exist). > | > > > | > > Ömer > | > > _______________________________________________ > | > > ghc-devs mailing list > | > > [email protected] > | > > > | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com > %7C07ec32bd26d149c457ab08d > | 62af537c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636743630029759709 > | &sdata=4DVsRJ4Burv2%2BZGf38py%2FNRqM5j5%2FJAUkJPrUl7%2F%2Fm0%3D&r > | eserved=0 > | > > | _______________________________________________ > | ghc-devs mailing list > | [email protected] > | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com > %7C07ec32bd26d149c457ab08d > | 62af537c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636743630029759709 > | &sdata=4DVsRJ4Burv2%2BZGf38py%2FNRqM5j5%2FJAUkJPrUl7%2F%2Fm0%3D&r > | eserved=0 > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
