Opened 22 months ago

Last modified 11 months ago

#11549 new bug

Add -fshow-runtime-rep

Reported by: goldfire Owned by:
Priority: normal Milestone: 8.4.1
Component: Compiler Version: 8.0.1-rc2
Keywords: TypeInType Cc: bgamari
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1961
Wiki Page:

Description

As discussed in several interwoven threads (original, café), it has been suggested to add a flag -fshow-runtime-rep. Without this flag enabled, the pretty printer will instantiate any RuntimeRep type parameters to PtrRep Lifted. This has the effect of changing

($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b

to

($) :: (a -> b) -> a -> b

under the default GHCi settings.

Note that Levity becomes RuntimeRep after #11471 is complete.

Change History (18)

comment:1 Changed 22 months ago by RyanGlScott

One thing isn't clear to me about how -fshow-runtime-rep works. I'm assuming that without -fshow-runtime-rep on, you won't see any mention of RuntimeRep in error messages. If so, what kind of error would this produce?

import GHC.Exts

bad :: forall (w :: RuntimeRep) (a :: TYPE w). a -> Int
bad _ = 42

The error would probably mention the type signature of bad, but would it be truncated to a -> Int instead of the full shebang?

comment:2 Changed 22 months ago by simonpj

Keywords: TypeInType added

comment:3 Changed 21 months ago by bgamari

Cc: bgamari added

comment:4 Changed 21 months ago by bgamari

Differential Rev(s): Phab:D1961
Status: newpatch

I gave this a shot in Phab:D1961.

The approach is admittedly rather simple-minded; it remains to be seen how much havoc this will wreak on error messages.

Last edited 21 months ago by bgamari (previous) (diff)

comment:5 Changed 21 months ago by simonpj

See #11660 for a probably better approach.

comment:6 Changed 21 months ago by goldfire

But #11660 seems orthogonal to this -- the general idea that is described in this ticket and the implementation in Phab:D1961 would still need to exist even after #11660.

comment:7 in reply to:  6 Changed 21 months ago by simonpj

Replying to goldfire:

But #11660 seems orthogonal to this -- the general idea that is described in this ticket and the implementation in Phab:D1961 would still need to exist even after #11660.

Well, the implementation in Phab:D1961 would move from Type to IfaceType, and might look a bit different there. That's all I meant

comment:8 Changed 20 months ago by Ben Gamari <ben@…>

In 371608f/ghc:

Default RuntimeRep variables unless -fprint-explicit-runtime-reps

Summary:
Addresses #11549 by defaulting `RuntimeRep` variables to `PtrRepLifted`
and adding a new compiler flag `-fprint-explicit-runtime-reps` to
disable this behavior.

This is just a guess at the right way to go about this. If it's
wrong-beyond-any-hope just say so.

Test Plan: Working on a testcase

Reviewers: goldfire, austin

Subscribers: simonpj, thomie

Differential Revision: https://phabricator.haskell.org/D1961

GHC Trac Issues: #11549

comment:9 Changed 20 months ago by bgamari

Resolution: fixed
Status: patchclosed
Last edited 20 months ago by bgamari (previous) (diff)

comment:10 Changed 20 months ago by RyanGlScott

Do you think it's worth special-casing this kind of behavior with -XTypeApplications as well? Currently, it's quite easy to leak RuntimeRep:

$ /opt/ghc/8.0.1/bin/ghci
GHCi, version 8.0.0.20160324: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
λ> :t undefined
undefined :: GHC.Stack.Types.HasCallStack => a
λ> :set -XTypeApplications 
λ> :t undefined @Int

<interactive>:1:12: error:
    • Expected kind ‘GHC.Types.RuntimeRep’, but ‘Int’ has kind ‘*’
    • In the type ‘Int’
      In the expression: undefined @Int

comment:11 Changed 20 months ago by bgamari

Mmm, comment:10 raises a good point. My first thought here was to look for kind errors in specified type arguments and provide the user with a better error (including the full type of the applied function) in the case of a unification error.

Austin and I discussed this and he suggested that perhaps -XTypeApplications should imply -fprint-explicit-runtime-reps. This sounds reasonable (if a bit surprising) at first glance given how likely it is that you will encounter RuntimeRep arguments with TypeApplications.

Last edited 20 months ago by bgamari (previous) (diff)

comment:12 Changed 20 months ago by thoughtpolice

Owner: goldfire deleted
Priority: highestnormal
Resolution: fixed
Status: closednew

comment:13 Changed 20 months ago by thoughtpolice

Version: 8.18.0.1-rc2

comment:14 Changed 20 months ago by bgamari

Milestone: 8.0.18.0.2

Unfortunately I don't see an easy way to make comment:11 happen.

comment:15 Changed 20 months ago by simonpj

Another problem: #11786

comment:16 Changed 15 months ago by bgamari

Milestone: 8.0.28.2.1

This won't be happening for 8.0.2.

comment:17 Changed 11 months ago by bgamari

Milestone: 8.2.18.4.1

Nor will this happen for 8.2.

comment:18 Changed 11 months ago by goldfire

While comment:10 is indeed an odd interaction, these sorts of problems become inevitable. I'm reminded of a scene in the movie Interstellar where a robot describes that his "honesty setting" is at 90%, because that just works out better than being 100% honest. As GHC's type system has become more complicated, users have been requesting it to lower its honesty setting, hiding bits and pieces that look scary. We now have -fprint-explicit-kinds, -fprint-explicit-coercions, -fprint-explicit-foralls, -fprint-equality-relations, and -fprint-explicit-runtime-reps. Each of these flags are off by default, and each one is essentially an honesty setting. Perhaps with the exception of -fprint-explicit-coercions, the fact that GHC lies about these aspects of a program means that programmers may make mistakes -- it's the old "garbage in, garbage out", but in reverse! (with the humans getting and producing the garbage)

I don't know how to really solve this, short of #8809, which would lead to Idris-like interactivity in error messages. We could try to figure out when a user has produced garbage in response to a lie that GHC has told and then tell the user to tell GHC not to lie (as we do when we suggest -fprint-explicit-kinds in error messages), but I think we'll always be playing catch-up. Instead, we should give the user the direct option (via #8809) to know when GHC is lying and to request the truth.

Note: See TracTickets for help on using tickets.