-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 13:45:33 UTC 2014


| Yes, these are related. However, they all point to just a change in the
| output format of -ddump-types so that by default, foralls are not
| printed. The old output format can be restored by passing in an extra -
| fprint-explicit-foralls flag. I think this is actually an improvement,
| and thus my suggestion is to simply update the expected output of these
| tests.

Yes I agree.  Go ahead.

| 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.  

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.

| If there's agreement on this, I'm happy to implement both changes.

Thanks. It would be good to nail this today; currently there are a bunch of consequential validate failures.

Simon


| 
| I think this is actually a bug in isSymOcc, since I don't think the
| intention behind the generated name $wupd is to be regarded as an infix
| name. So we could change isLexVarSym so that if the first character is
| $, the rest is still checked for symbol-ness.
| 
| 
| Bye,
|  	Gergo
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list