-ddump-types vs -fprint-explicit-foralls, and symbol-ness of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a) (fwd)]

Simon Peyton Jones simonpj at microsoft.com
Mon Mar 17 14:08:57 UTC 2014


Do they show up in -ddump-simpl? It would be nice to keep that output as readable as possible, as there are quite a few of us that read it on a regular basis.

I don't think so (because -ddump-simpl doesn't print *any* operators in parens) but I could be wrong, and I agree that would be bad.

Does that mean that any operator that starts with $ will now not be considered infix for printing purposes?

No, I believe that Gergo's suggestion is that a function be considered infix operator (for display purposes) only if all its characters are operator chars, rather than just the first one.

Simon

From: Johan Tibell [mailto:johan.tibell at gmail.com]
Sent: 17 March 2014 14:00
To: Simon Peyton Jones
Cc: Dr. ERDI Gergo; GHC Devs
Subject: Re: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a) (fwd)]

On Mon, Mar 17, 2014 at 2:45 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
| The one interesting case is T4306 which fails because the generated name
| $wupd is regarded as an infix name, and thus with my new code is
| rendered as
|
|    ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double#
|
| instead of the old
|
|    $wupd :: GHC.Prim.Double# -> GHC.Prim.Double#
I think it'd also be ok just to accept this output too. These "$wxx" names are generated by GHC and won't show up in user output.  It doesn't much matter displaying them in parens.

Do they show up in -ddump-simpl? It would be nice to keep that output as readable as possible, as there are quite a few of us that read it on a regular basis.

But changing isLexVarSym is probably equally fine too.  I think (worth a check) that it's only called for display purposes, and not in any performance-critical parts.

Whichever you choose, add a Note with isLexVarSym to explain the issue and the choice.

Does that mean that any operator that starts with $ will now not be considered infix for printing purposes?

-- Johan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140317/4cb1e926/attachment-0001.html>


More information about the ghc-devs mailing list