Re: Finding out if a binding is externally visible

[Sebastian Graf]

> 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  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
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Removing Hoopl dependency?

[Simon Peyton Jones via ghc-devs]

Is there really a compelling case for forking Hoopl?  I was talking to Kavon 
last week about doing exactly the opposite: using Hoopl more wholeheartedly!

Before going ahead with this, let’s remember the downsides

·If we fork Hoopl, improvements in one place will not be seen in the 
other.  GHC originally used its own containers library but now uses 
‘containers’, most of which is irrelevant to GHC, just to pick up the work that 
has been done to make ‘containers’ fast.  Similarly, GHC has a clone of 
‘pretty’, but someone is working (I think) to make GHC use ‘pretty’.

·It’s not clear to me why GHC has a clone of parts of Hoopl.  Would it 
not be better just to make Hoopl faster?

If anything I ‘d like to use Hoopl more in Cmm optimisation passes in GHC, so 
we may want to use more of Hoopl’s facilities.

The main reason you suggest for forking is that there are some awkward name 
clashes.  Surely we could resolve these? e.g we could change CLabel in GHC; or 
agree with Hoopl maintainers that BlockId would be more helpful than Label.

You mention that Hoopl uses Unique set/map.  Why not use ‘containers’ for that? 
 (Like GHC!)

Let’s discuss this a bit more before executing

I’m also interested to know:

·who is actively working on Hoopl (Michael, Sophie, …)?

·how are you using it (within GHC, or somewhere else)?

It’d be good to review and update 
https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup.  Are there any other 
improvements planned?
Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michal 
Terepeta
Sent: 27 May 2017 18:58
To: ghc-devs 
Subject: Removing Hoopl dependency?

Hi all,

I was looking at removing the `BlockId` type synonym in favor of
Hoopl's `Label` (there was already a TODO and it is a bit confusing).
But once I've started making the changes, I've realized that in a
bunch of places this makes the code *less* readable. Mostly because of
`CLabel` (sounds similar but is something quite different and having
to rename local variables from `label` to `clabel` is not great).

I started to look at alternatives and noticed that in general the
interface between GHC and Hoopl is quite noisy and confusing:
- Hoopl has `Label` which is GHC's `BlockId` but different than
  GHC's `CLabel`
- Hoopl has `Unique` which is different than GHC's `Unique`
- Hoopl has `Unique{Map,Set}` which are different than GHC's
  `Uniq{FM,Set}`
- GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is
  needed just to filter the exposed functions (filter out some of the
  Hoopl's and add the GHC ones).
- Working in `cmm/` requires constant switching between GHC code and
  Hoopl (`CmmNode`/`CmmGraph`/`CmmBlock` and dataflow stuff is in GHC,
  the actual implementation of `Block`/`Graph` are defined in Hoopl,
  etc.)

GHC is actually using only a small subset of Hoopl (e.g., the fixpoint
computation is copied/specialized: `cmm/Hoopl/Dataflow`). So I was
wondering - maybe it's worth to simply drop the dependency on Hoopl?
(and copy the code that is actually necessary in GHC)
I've done an experiment in [1] (to see how much we'd need to actually
copy) and I really like the result:
- We can remove one external dependency and git submodule at the
  cost of only 5 new modules in `cmm/Hoopl` (net gain of only 4
  modules: we add 5 new but can remove `cmm/Hoopl`, which is no longer
  needed)
- We should be able to fix all of the above issues and make the code
  easier to understand (less code, everything in one repo, fewer
  concepts).
- It's going to be easier to change things since we don't need to
  worry about changing the public interface of Hoopl (it's a
  standalone package on Hackage and other people already depend on the
  current behavior).

What do you think? Does anyone think we shouldn't do this?

Thanks,
Michal

[1] Branch: 
https://github.com/michalt/ghc/tree/hoopl/no-hoopl
Diff: 
https://github.com/ghc/ghc/compare/master...michalt:hoopl/no-hoopl
For now I just copied the code/updated imports and didn't do any
cleanups, but I'd be happy to do them in subsequent PRs

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

RE: [commit: ghc] master: Fix test output after 'Some tidying up of type pretty-printing' (09d5c99)

[Simon Peyton Jones via ghc-devs]

Sorry about this.  I carefully fixed all these and validated...thanks for fixing

Simon

| -Original Message-
| From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of
| g...@git.haskell.org
| Sent: 27 May 2017 15:45
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Fix test output after 'Some tidying up of
| type pretty-printing' (09d5c99)
| 
| Repository : ssh://g...@git.haskell.org/ghc
| 
| On branch  : master
| Link   :
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske
| ll.org%2Ftrac%2Fghc%2Fchangeset%2F09d5c993aae208e3d34a9e715297922b6ea42b3
| f%2Fghc=02%7C01%7Csimonpj%40microsoft.com%7Ca2a237b8dabd42f3684f08d4
| a50ef9ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636314931129891311&
| sdata=VM04DE0U1RBSmJjbV6vCwu8LPvyqwqfo2K1I03W1cW4%3D=0
| 
| >---
| 
| commit 09d5c993aae208e3d34a9e715297922b6ea42b3f
| Author: Bartosz Nitka 
| Date:   Sat May 27 07:42:26 2017 -0700
| 
| Fix test output after 'Some tidying up of type pretty-printing'
| 
| Most are cosmetic. There's an interesting change in T7861,
| but the error is still accurate.
| 
| 
| >---
| 
| 09d5c993aae208e3d34a9e715297922b6ea42b3f
|  testsuite/tests/typecheck/should_run/T7861.stderr | 6 +-
|  testsuite/tests/typecheck/should_run/Typeable1.stderr | 2 +-
| testsuite/tests/typecheck/should_run/tcrun045.stderr  | 6 +++---
|  3 files changed, 5 insertions(+), 9 deletions(-)
| 
| diff --git a/testsuite/tests/typecheck/should_run/T7861.stderr
| b/testsuite/tests/typecheck/should_run/T7861.stderr
| index e9ee5e9..4a1c030 100644
| --- a/testsuite/tests/typecheck/should_run/T7861.stderr
| +++ b/testsuite/tests/typecheck/should_run/T7861.stderr
| @@ -1,9 +1,5 @@
|  T7861: T7861.hs:10:5: error:
| -• Couldn't match type ‘a’ with ‘[a]’
| -  ‘a’ is a rigid type variable bound by
| -the type signature for:
| -  f :: forall a. (forall b. a) -> a
| -at T7861.hs:9:1-23
| +• Occurs check: cannot construct the infinite type: a ~ [a]
|Expected type: (forall b. a) -> a
|  Actual type: (forall b. a) -> [a]
|  • In the expression: doA
| diff --git a/testsuite/tests/typecheck/should_run/Typeable1.stderr
| b/testsuite/tests/typecheck/should_run/Typeable1.stderr
| index 9a7d3b7..65f6fd4 100644
| --- a/testsuite/tests/typecheck/should_run/Typeable1.stderr
| +++ b/testsuite/tests/typecheck/should_run/Typeable1.stderr
| @@ -7,7 +7,7 @@ Typeable1.hs:22:5: error:
|App :: forall k2 (t :: k2).
|   () =>
|   forall k1 (a :: k1 -> k2) (b :: k1).
| - t ~ a b =>
| + (t ~ a b) =>
|   TypeRep a -> TypeRep b -> TypeRep t,
|  in a pattern binding in
|   'do' block
| diff --git a/testsuite/tests/typecheck/should_run/tcrun045.stderr
| b/testsuite/tests/typecheck/should_run/tcrun045.stderr
| index 19fca10..f6b1652 100644
| --- a/testsuite/tests/typecheck/should_run/tcrun045.stderr
| +++ b/testsuite/tests/typecheck/should_run/tcrun045.stderr
| @@ -1,18 +1,18 @@
| 
|  tcrun045.hs:11:10: error:
|  • Illegal implicit parameter ‘?imp::Int’
| -• In the context: (?imp::Int)
| +• In the context: ?imp::Int
|While checking an instance declaration
|In the instance declaration for ‘C Int’
| 
|  tcrun045.hs:24:1: error:
|  • Illegal implicit parameter ‘?imp::Int’
| -• In the context: (?imp::Int)
| +• In the context: ?imp::Int
|While checking the super-classes of class ‘D’
|In the class declaration for ‘D’
| 
|  tcrun045.hs:27:10: error:
|  • Illegal implicit parameter ‘?imp::Int’
| -• In the context: (?imp::Int)
| +• In the context: ?imp::Int
|While checking an instance declaration
|In the instance declaration for ‘D Int’
| 
| ___
| ghc-commits mailing list
| ghc-comm...@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| commits=02%7C01%7Csimonpj%40microsoft.com%7Ca2a237b8dabd42f3684f08d4
| a50ef9ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636314931129891311&
| sdata=MYdcDMAQcDnFVFlc0aNT1NXPHFa%2FT%2FSpNiDIu4hrvOY%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Finding out if a binding is externally visible

[Joachim Breitner]

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
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removing Hoopl dependency?

[Michal Terepeta]

Cool, thanks for quick replies!
I've sent out https://phabricator.haskell.org/D3616

Cheers,
Michal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Finding out if a binding is externally visible

[Sebastian Graf]

I just stumbled over Note [ExportFlag on binders] in Var.hs, which
indicates this might be a bug, right?

On Sun, May 28, 2017 at 5:52 PM, Sebastian Graf  wrote:

> Hi all,
>
> I'm tinkering around with GHCs Call Arity Analysis and Demand Analysis as
> part of my Master's thesis. The usage analysis part is what I'm interested
> in in particular.
>
> After quite some time spent debugging absent errors, I noticed that
> certain top-level bindings aren't exported, but still visible in other
> modules through generated RULE pragmas (e.g. through class instance
> specialization). These bindings were considered absent in my combined
> analysis, explaining the very sporadic absent errors I was getting.
>
> 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?
>
> Greetings,
> Sebastian
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HsParTy

[Alan & Kim Zimmerman]

See 3b23f680c2b1f80b693eb8896fb21e4bbf8edc7e

On 26 May 2017 at 13:32, Simon Peyton Jones  wrote:

> I can try to strip then all out and see what happens.
>
> That’d be good!  With a Note to explain why…
>
>
>
> We still need ctxt_prec, I think, to pass to the ordinary type
> pretty-printer, when we have HsCoreTy.
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs