Also I should add that this is probably not just happening for ids mentioned by RULEs, but also for Unfoldings. E.g. although wrappers are exported, associated workers are not, but still visible through unfoldings. It's not as bad as with RULEs since they are still reachable, but it might make for weird results... And also contradicts Note [ExportFlag on binders] in Var.hs as I understand it.

On Mon, May 29, 2017 at 10:40 AM, Sebastian Graf <sgraf1337@gmail.com> wrote:
OK, I attached an example for a specialization of Show for a special case of a custom type, like Ratio in GHC.Real. My invokation with a custom GHC (8.0-based) was like this:

    $ <ghc> Module.hs -ddump-simpl -O -fforce-recomp

At the begin of the log, I listed all exported top-level identifiers, the only interesting of which is `$fShowRatio :: Show a => Show (Ratio a)`, the default implementation. Note that at the bottom, there are RULEs stating the specialization for `Show Integer`, but that the specialized dictionary `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)` isn't otherwise reachable from any exported top-level identifier. Same goes for any of the specialized dictionary methods.

Now consider what happens if we request a `Show (Ratio Integer)` dictionary in another module: GHC finds the exported default dictionary `$fShowRatio :: Show a => Show (Ratio a)`, but then applies a specialization RULE that will effectively use the presumably absent `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)`.

In my case, my custom GHC would substitute away the `showString " % "` for an `absentError "lvl [Char]"` and crash in subtle ways. The only reason this isn't happening for GHC master is that DmdAnal does consider all top-level arguments to be used, instead of only the exported ones (which is what CallArity does).

On Sun, May 28, 2017 at 11:53 PM, Sebastian Graf <sgraf1337@gmail.com> wrote:

welcome on this list!

Thanks :)

     isExportedId :: Var -> Bool

That's what I have been using so far, but I found that said RULE pragmas mentioned non-exported identifiers. Or maybe it was just some temporary build system mess-up, I'll work on a reproduction...

On Sun, May 28, 2017 at 10:33 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi Sebastian,

welcome on this list!

Am Sonntag, den 28.05.2017, 17:52 +0200 schrieb Sebastian Graf:
> Is there some function that tells me if an identifier is 'externally
> visible' in that sense? I think https://downloads.haskell.org/~ghc/8.
> 0.1/docs/html/libraries/ghc-8.0.1/GHC.html#v:isExternalName is what
> I'm after, but I want to be sure. Does that function already work
> when the Ids are still local?

I would expect

    isExportedId :: Var -> Bool

to do precisely that.

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  mail@joachim-breitner.dehttps://www.joachim-breitner.de/
  XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata@debian.org

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs