RE: tcSubsumes

[Simon Peyton Jones via ghc-devs]

Richard

It's clearly wrong as it is, but I suggest you that you make tcSubsumes use 
captureConstraints rather than pushLevelAndCaptureConstratints.  That's what 
solveEqualities does, after all.

Simon

| -Original Message-
| From: Richard Eisenberg [mailto:r...@cs.brynmawr.edu]
| Sent: 26 October 2017 23:12
| To: Simon Peyton Jones 
| Cc: ghc-devs 
| Subject: tcSubsumes
| 
| Hi Simon,
| 
| Could you take a look at TcSimplify.tcSubsumes? This relatively new
| function pushes the TcLevel when calling tcSubType, but then doesn't set
| the TcLevel when calling the solver. Inexplicably, this sometimes works -
| - even passing the testsuite. Somehow, my work caused this to fail. I
| fixed it by setting the TcLevel before calling the solver.
| 
| Two questions:
| 
| 1. Is this a reasonable fix?
| 
| 2. (optional) How is it possible that this didn't fail drastically often?
| 
| Note (to author / reviewers of this function): my astonishment isn't that
| this error crept into the codebase -- I've done similar many many times.
| My astonishment is how the testsuite didn't find this error forthwith.
| 
| Thanks,
| Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: valid substitutions for holes

[Simon Peyton Jones via ghc-devs]

I'm not sure why pure and return are reported now when they weren't before.  
Characterising that would be helpful.

But yes, it's an experimental feature, so I don't think you should hold up the 
train for it.  You should talk to the author.

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard
| Eisenberg
| Sent: 27 October 2017 02:43
| To: ghc-devs 
| Subject: valid substitutions for holes
| 
| Hi all,
| 
| GHC HEAD currently suggests valid in-scope single-identifier
| substitutions for typed holes (underscores in terms). Some unrelated work
| somehow changed the output, and I'm wondering if this is a change for the
| better or for the worse.
| 
| The test case is this:
| 
| > f :: Int -> Int -> Int
| > f x y = _ x y
| 
| With my patch, GHC now suggests `pure` and `return` as replacements for _
| (along with the other top contenders of (-), asTypeOf, and const). (You
| can also increase the number of suggestions, which will then include (+)
| and (*) among others.) It's true that `pure` and `return` fit the bill,
| noting that ((->) Int) is an Applicative. But I doubt these suggestions
| will help the user.
| 
| I'm not keen to make fixing this "valid suggestions" feature (which I do
| really like) a dependency of finishing my patch, but I also don't want
| the change to output to go unnoticed. So, I'm asking: when I merge my
| patch, should I post a bug asking for perhaps a priority ordering of
| suggestions?
| 
| Thanks,
| Richard
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=02%7C01%7Csimonpj%40microsoft.com%7Cabcb64569709446adb0808d51d5
| 53ba6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447174270553152
| ta=bGgYpNvuhR7rWnubjsYG5FKfza5gmbP0PPu6bNcJBUs%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: GHC build broken

[Simon Peyton Jones via ghc-devs]

ps this Linux box is way behind

gcc --version

gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

Copyright (C) 2011 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



From: Simon Peyton Jones
Sent: 06 November 2017 16:23
To: ghc-devs@haskell.org
Subject: GHC build broken

Ben: I'm getting this from a clean build on Linux.  Any ideas?
I'm up to date on master

git branch -v

  data-kind-syntax 4174458178 Add IfacePromotionInfo

* master   436b3ef01e Clean up comments about match algorithm a bit.

  tc-untouchables  b737a45391 More simplifications to the constraint solver

  type-nats87d2a63b8d [behind 1491] Fix uses of (<=?) as a function 
to reduce properly.

  wip/pattern-synonyms e54d396752 [ahead 6, behind 4569] Comments and tracing 
only

  wip/spj-T13397   43540c8c6b Improve code generation for conditionals

  wip/spj-early-inline 8515fcfa91 Mark non-recursive join lambdas as one-shot

simonpj@cam-05-unx:~/code/HEAD/compiler$

Simon



libraries/ghc-prim/cbits/atomic.c:311:54: error:

 error: '__ATOMIC_SEQ_CST' undeclared (first use in this function)

|

311 |   __atomic_store_n((StgWord16 *) x, (StgWord16) val, __ATOMIC_SEQ_CST);

|  ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite32':



make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.o] Error 1

make[1]: *** Waiting for unfinished jobs

libraries/ghc-prim/cbits/atomic.c:318:54: error:

 error: '__ATOMIC_SEQ_CST' undeclared (first use in this function)

|

318 |   __atomic_store_n((StgWord32 *) x, (StgWord32) val, __ATOMIC_SEQ_CST);

|  ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite64':



libraries/ghc-prim/cbits/atomic.c:325:54: error:

 error: '__ATOMIC_SEQ_CST' undeclared (first use in this function)

|

325 |   __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST);

|  ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread64':



libraries/ghc-prim/cbits/atomic.c:294:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

294 | }

| ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread32':



libraries/ghc-prim/cbits/atomic.c:287:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

287 | }

| ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread16':



libraries/ghc-prim/cbits/atomic.c:280:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

280 | }

| ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread8':



libraries/ghc-prim/cbits/atomic.c:273:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

273 | }

| ^

cc1: all warnings being treated as errors

`gcc' failed in phase `C Compiler'. (Exit code: 1)

make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.dyn_o] Error 1

<>

make: *** [all] Error 2

simonpj@cam-05-unx:~/5builds/HEAD$ dirs

~/5builds/HEAD ~/5builds/HEAD/testsuite/tests/typecheck/should_fail

simonpj@cam-05-unx:~/5builds/HEAD$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC build broken

[Simon Peyton Jones via ghc-devs]

Ben: I'm getting this from a clean build on Linux.  Any ideas?
I'm up to date on master

git branch -v

  data-kind-syntax 4174458178 Add IfacePromotionInfo

* master   436b3ef01e Clean up comments about match algorithm a bit.

  tc-untouchables  b737a45391 More simplifications to the constraint solver

  type-nats87d2a63b8d [behind 1491] Fix uses of (<=?) as a function 
to reduce properly.

  wip/pattern-synonyms e54d396752 [ahead 6, behind 4569] Comments and tracing 
only

  wip/spj-T13397   43540c8c6b Improve code generation for conditionals

  wip/spj-early-inline 8515fcfa91 Mark non-recursive join lambdas as one-shot

simonpj@cam-05-unx:~/code/HEAD/compiler$

Simon



libraries/ghc-prim/cbits/atomic.c:311:54: error:

 error: '__ATOMIC_SEQ_CST' undeclared (first use in this function)

|

311 |   __atomic_store_n((StgWord16 *) x, (StgWord16) val, __ATOMIC_SEQ_CST);

|  ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite32':



make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.o] Error 1

make[1]: *** Waiting for unfinished jobs

libraries/ghc-prim/cbits/atomic.c:318:54: error:

 error: '__ATOMIC_SEQ_CST' undeclared (first use in this function)

|

318 |   __atomic_store_n((StgWord32 *) x, (StgWord32) val, __ATOMIC_SEQ_CST);

|  ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicwrite64':



libraries/ghc-prim/cbits/atomic.c:325:54: error:

 error: '__ATOMIC_SEQ_CST' undeclared (first use in this function)

|

325 |   __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST);

|  ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread64':



libraries/ghc-prim/cbits/atomic.c:294:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

294 | }

| ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread32':



libraries/ghc-prim/cbits/atomic.c:287:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

287 | }

| ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread16':



libraries/ghc-prim/cbits/atomic.c:280:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

280 | }

| ^

libraries/ghc-prim/cbits/atomic.c: In function 'hs_atomicread8':



libraries/ghc-prim/cbits/atomic.c:273:1: error:

 error: control reaches end of non-void function [-Werror=return-type]

|

273 | }

| ^

cc1: all warnings being treated as errors

`gcc' failed in phase `C Compiler'. (Exit code: 1)

make[1]: *** [libraries/ghc-prim/dist-install/build/cbits/atomic.dyn_o] Error 1

<>

make: *** [all] Error 2

simonpj@cam-05-unx:~/5builds/HEAD$ dirs

~/5builds/HEAD ~/5builds/HEAD/testsuite/tests/typecheck/should_fail

simonpj@cam-05-unx:~/5builds/HEAD$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [ANNOUNCE] GHC 8.2.2 release candidate 2

[Simon Peyton Jones via ghc-devs]

Thank you for doing this!

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ryan Scott
Sent: 03 November 2017 00:19
To: ghc-devs@haskell.org
Subject: Re: [ANNOUNCE] GHC 8.2.2 release candidate 2

I built all of Stackage with this RC the other night and didn't observe any 
regressions. Hooray!
(Thanks to Doug Wilson for helping me get set up with his 
https://github.com/duog/build-stackage
 repo.)
Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Bringing some observable sharing to GHCi

[Simon Peyton Jones via ghc-devs]

Do TypeReps need to be cyclic?

No – I think David is working on a non-cyclic version

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Marlow
Sent: 02 November 2017 10:27
To: David Feuer 
Cc: Joachim Breitner ; ghc-devs 
Subject: Re: Bringing some observable sharing to GHCi

Not being able to :print an exception would be quite annoying. Do TypeReps need 
to be cyclic?

Observable sharing can be done with StableName, but that would be a bit pile of 
hassle in the printer. Maybe exceptions warrant a special case.

Cheers
Simon

On 29 October 2017 at 20:40, David Feuer 
> wrote:
The :sprint, :print, and :force commands in GHCi fall into infinite
loops when confronted by cyclical data. This bit me hard in
https://phabricator.haskell.org/D4085 because that produces cyclical
TypeReps, which is trouble for (e.g.) the test break011 which tries to
:force a SomeException (which wraps an Exception dictionary, which has
a Typeable constraint). I could try coming up with a fix myself, but
I'm rather curious whether some of the work you (or others) have
already done on observing GHC data graphs could be yanked into GHCi
itself for this purpose. We want

1. To be able to display cyclical data in some sensible way.

> x = "hi" : x
> x `seq` ()
> :print x

should print some useful representation of x.

2. To be able to force cyclical data without looping.

> x = "hi" : x
> :force x

should print a useful representation of x.
___
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: When does GHC produce unlifted `let` bindings?

[Simon Peyton Jones via ghc-devs]

Re: let-bindings floating more easily, would a check for 
`exprIsOkForSpeculation scrut` in theory suffice to float out cases?

Yes; but instead we simply turn such cases into lets.

Simon

From: Sebastian Graf [mailto:sgraf1...@gmail.com]
Sent: 02 November 2017 08:33
To: Simon Peyton Jones 
Cc: ghc-devs 
Subject: Re: When does GHC produce unlifted `let` bindings?

Thanks both of you, that makes sense.

Re: let-bindings floating more easily, would a check for 
`exprIsOkForSpeculation scrut` in theory suffice to float out cases?

On Mon, Oct 30, 2017 at 10:56 AM, Simon Peyton Jones 
> wrote:
See Note [CoreSyn let/app invariant] in CoreSyn.

Briefly, you can write
let x::Int# = e in …
if e is “ok-for-speculation”.  See extensive comments in CoreUtils on what that 
means.

You could also use case, but let-bindings “float” more easily than cases, 
because they are not worried about preserving exception behaviour.

Simon

From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Sebastian Graf
Sent: 29 October 2017 21:07
To: ghc-devs >
Subject: When does GHC produce unlifted `let` bindings?

Hi folks,

I was debugging a Core-to-Core transform for 
TEST=spec-inline
 and was wondering (yet again) why GHC produces unlifted `let` bindings in Core 
like it seems supposed to be 
doing.

  *   Why doesn't this use `case` instead?
  *   Is there a semantic difference?
  *   Can `case` be used with unlifted types?
  *   And if not, why can `let`?
Unlifted `let` seems much close to `case` than to `let`. Some GHC passes seem 
to 
agree.

Cheers,
Sebastian

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

RE: GHCi recompilation avoidance UI

[Simon Peyton Jones via ghc-devs]

I'm lost.

* What causes the undesired behaviour in GHC 8.2.1?
  Is it this?
- GHCi wants to load module B with flags F
- There is a B.o but the flags differ
- So GHCi recompiles B to bytecode

* How does (1) help?

* Does (2) propose a new command (:load *M vs :load M)?
  If so, how does it help.

* Is (3), what is the spec of the proposed new flags?
  Is it this?
  - GHC wants to compile module B with flags F
  - There is a B.o compiled with flags F'
  - And B.hs (and its dependencies) have not changed
  - Then normally we'd recompile F unless F = F'
  - But with -fignore-optim-changes we would weaken that equality to
ignore differences between F and F' that only affected optimisation
level (the list of such flags would need to be written out)
  - And similarly for -fignore-hpc-changes


Precision is all!

Thanks

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David
|  Feuer
|  Sent: 31 October 2017 15:42
|  To: ghc-devs@haskell.org
|  Subject: GHCi recompilation avoidance UI
|  
|  Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now
|  refuses to load optimized code unless -fobject-code (and optimization
|  flags) are enabled. I propose the following slight modification to
|  https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48
|  
|  1. Optimization flags (except -O0) imply -fobject-code. This ensures
|  that GHC respects optimization flags regardless of --interactive.
|  
|  2. Even when -fobject-code is on, :load *M will load M as bytecode.
|  This provides the "escape hatch" from -fobject-code that you need to
|  use debugging features, etc.
|  
|  3. New -fignore-optim-changes and -fignore-hpc-changes (​​Phab:D4123)
|  flags should enable users to put together object code and bytecode with
|  diverse optimization levels/options and HPC options while still
|  updating automatically based on source changes and whether profiling is
|  enabled.
|  
|  Does this seem like a reasonable way forward?
|  
|  David Feuer
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.ha
|  skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7Cd533ac396d6a4a6ff68208d52
|  076040e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450613629249637
|  =9duvpS1xcNXXUm%2BOJgWg4jFBCgvT3SqPJMU2k8Rdxj0%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Building the docs, again

[Simon Peyton Jones via ghc-devs]

It is quite confusing that we can be setting the same variable to different 
values in different places.   It would also be quite helpful if we modified the 
Makefile to say `documentation build target is disabled` or some such, rather 
then going ahead and building the whole of GHC, only at the end to inform me 
that it doesn't know what is `html`.
Maybe Hadrian will help here?

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Iavor Diatchki
Sent: 31 October 2017 21:49
To: ghc-devs@haskell.org
Subject: Re: Building the docs, again

Hello,

never mind, I figured it out---apparently the build targets were disabled for 
the `quick` flavor, which I was using.

It is quite confusing that we can be setting the same variable to different 
values in different places.   It would also be quite helpful if we modified the 
Makefile to say `documentation build target is disabled` or some such, rather 
then going ahead and building the whole of GHC, only at the end to inform me 
that it doesn't know what is `html`.

-Iavor



On Tue, Oct 31, 2017 at 2:26 PM Iavor Diatchki 
> wrote:
Hello,

sometime ago, I asked if it is possible to build just the GHC docs, without 
building the compiler.  I was told to just run `make html`.  This does not 
appear to work, the command seems to just start building GHC.  What am I doing 
wrong?

Here is the output I see, running the command from the root of the GHC tree.

> make html V=0
===--- building phase 0
make --no-print-directory -f 
ghc.mk
 phase=0 phase_0_builds
make[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
make --no-print-directory -f 
ghc.mk
 phase=1 phase_1_builds
  HC [stage 0] compiler/stage1/build/BufWrite.o
  HC [stage 0] compiler/stage1/build/Pretty.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/PprColour.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Outputable.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Json.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/SrcLoc.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/BasicTypes.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Unique.o
  HC [stage 0] compiler/stage1/build/Packages.o-boot
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/FiniteMap.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Name.o-boot

(then I interrupted it).

Also, in 
`mk/config.mk`
 I see this:
BUILD_SPHINX_HTML= YES

-Iavor



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

FW: How does GHC's testsuite work?

[Simon Peyton Jones via ghc-devs]

Forwarding to ghc-devs, a better list for this question.

Simon 

-Original Message-
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Sébastien Hinderer
Sent: 30 October 2017 15:18
To: glasgow-haskell-us...@haskell.org
Subject: How does GHC's testsuite work?

Dear all,

I am a member of OCaml's developement team. More specifically, I am working on 
a test-driver for the OCaml compiler, which will be part of OCaml's 4.06 
release.

I am currently writing an article to describe the tool and its principles. In 
this article, I would like to also talk about how other compilers' testsuites 
are handled and loking how things are done in GHC is natural.

In OCaml, our testsuite essentially consist in whole programs that we compile 
and run, checking that the compilation and execution results match the expected 
ones.

From what I could see from GHC's testsuite, it seemed to me that it uses Python 
to drive the tests. I also understood that the testsuite has tests that are 
more kind of unit-tests, in the .T file. Am I correct here? Or do you guys also 
have whole program tests?
If you do, how do you compile and run them?

Any comment / hint on this aspect of the test harness' design would be really 
helpful.

Many thanks in advance,

Sébastien.





___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users=02%7C01%7Csimonpj%40microsoft.com%7C293aac933ae143b8690308d51fa9681f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636449734850370955=SY4ABziBhV4MxLwTpJ5bFyS8GJfHLL%2FZrTxQc90EGDs%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Types in GADT pattern match

[Simon Peyton Jones via ghc-devs]

foo b@(Bar :: Foo [a]) = quux b
The pattern (p :: ty) checks that the thing being matched has type ‘ty’ and 
THEN matches ‘p’.  You expected it to FIRST match ‘p’, and THEN check that the 
thing being matched has type ‘ty’.  But that’s not the way it works.

e.g what about this

rats ([Just (Bar, True)] :: [Maybe (Foo [a], Bool)]) = …

Here the pattern to be matched is deep, with the Bar part deep inside.  Do you 
still expect it to work?

This would be hard to change.  And I’m not sure it’d be an improvement.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor Greif
Sent: 29 October 2017 17:43
To: ghc-devs 
Subject: Q: Types in GADT pattern match

Hi Devs!

I encountered a curious restriction with type signatures (tyvar bindings) in 
GADT pattern matches.

GHC won't let me directly capture the refined type structure of GADT 
constructors like this:


{-# Language GADTs, ScopedTypeVariables #-}

data Foo a where
  Bar :: Foo [a]

foo :: Foo a -> ()
foo b@(Bar :: Foo [a]) = quux b
  where quux :: Foo [b] -> ()
quux Bar = ()


I get:



test.hs:7:8: error:

• Couldn't match type ‘a1’ with ‘[a]’

  ‘a1’ is a rigid type variable bound by

the type signature for:

  foo :: forall a1. Foo a1 -> ()

at test.hs:6:1-18

  Expected type: Foo a1

Actual type: Foo [a]


To me it appears that the type refinement established by the GADT pattern match 
is not accounted for.

Of course I can write:

foo :: Foo a -> ()
foo b@Bar | (c :: Foo [a]) <- b = quux c
  where quux :: Foo [b] -> ()
quux Bar = ()

but it feels like a complicated way to do it...

My question is whether this is generally seen as the way to go or whether 
ScopedTypeVariables coming from a GADT pattern match should be able to capture 
the refined type. To me the latter seems more useful.

Just wanted to feel the waters before writing a ticket about this.

Cheers and thanks,

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

RE: When does GHC produce unlifted `let` bindings?

[Simon Peyton Jones via ghc-devs]

See Note [CoreSyn let/app invariant] in CoreSyn.

Briefly, you can write
let x::Int# = e in …
if e is “ok-for-speculation”.  See extensive comments in CoreUtils on what that 
means.

You could also use case, but let-bindings “float” more easily than cases, 
because they are not worried about preserving exception behaviour.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Sebastian Graf
Sent: 29 October 2017 21:07
To: ghc-devs 
Subject: When does GHC produce unlifted `let` bindings?

Hi folks,

I was debugging a Core-to-Core transform for 
TEST=spec-inline
 and was wondering (yet again) why GHC produces unlifted `let` bindings in Core 
like it seems supposed to be 
doing.

  *   Why doesn't this use `case` instead?
  *   Is there a semantic difference?
  *   Can `case` be used with unlifted types?
  *   And if not, why can `let`?
Unlifted `let` seems much close to `case` than to `let`. Some GHC passes seem 
to 
agree.

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

RE: [commit: ghc] master: Make tagForCon non-linear (faf60e8)

[Simon Peyton Jones via ghc-devs]

| I considered that, but I'm shy at changing data types. Especially for
| caching, because sometimes keeping the data in sync can be difficult.

In this case, not so.  Just make a smart contructor for DataTyCon and use it.  
There are very few calls to it anyway!

As to the storage cost this is one word per data type.  There aren't that many 
data types!  (Compared to how many of everything else there is.)

Performance should be better -- no need to count the list repeatedly.

| Let me piggy-back a question for a follow-up diff on this.
| 
| Another bottleneck is in mkDataCon. For each data constructor we do [1]:
| 
|   tag = assoc "mkDataCon" (tyConDataCons rep_tycon `zip` [fIRST_TAG..])
| con
| 
| The easiest way to fix this was to cache the tag allocation (using
| UniqFM) in DataTyCon and SumTyCon.

I don’t like this.  Unlike the family size, the tag-map would be used in just 
one place, when building the data constructors.  Yes it'd be an extra argument 
to pass, but it's a local temporary thing, just during data type construction, 
whereas adding a field in DataTyCon stays forever.

To pass it around
* TcTyClsDecls.tcConDecls constructs a tag-map (NameEnv Tag) from the
  knot-tied tycoon
* Passes the tag-map to tcConDecl
* Which passes it to buildDataCon
* Which looks up the tag and passes it to mkDataCon

Not hard.

For the family size though, just cache it in DataTyCon.

Simon

| This is all in a knot, but it works out in this case.
| 
| Does that sound like a sound approach?
| An alternative would be to refactor the code to pass the tags down, but
| that looked harder.
| 
| Unfortunately going this route doesn't help with determining the size,
| because checking the size of UniqFM is linear.
| 
| 
| [1]
| https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/basi
| cTypes/DataCon.hs;faf60e858a293affca463043c830e1edb5685003$921
| 
| Thanks,
| Bartosz
| 
| 2017-10-27 15:06 GMT-07:00 Simon Peyton Jones :
| > Bartosz
| >
| > Why not just cache the #datacons in the TyCon (in the DataTyCon
| constructor).  That seems simple, direct, and fast.
| >
| > And simpler than the stuff you are forced into here.
| >
| > Simon
| >
| > | -Original Message-
| > | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf
| > | Of g...@git.haskell.org
| > | Sent: 27 October 2017 23:03
| > | To: ghc-comm...@haskell.org
| > | Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
| > |
| > | 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%2Ffaf60e858a293affca463043c830e1edb5
| > | 68500
| > | 3%2Fghc=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306
| > | 508d5
| > | 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63644738617630
| > | 3711&
| > | sdata=tp4PTSkN5iBwKkWgZdT%2BcHKK8EKz8NQZeE%2FegVdx%2FIM%3D=
| > | 0
| > |
| > | >---
| > |
| > | commit faf60e858a293affca463043c830e1edb5685003
| > | Author: Bartosz Nitka 
| > | Date:   Fri Oct 20 20:30:52 2017 +0100
| > |
| > | Make tagForCon non-linear
| > |
| > | Computing the number of constructors for TyCon is linear
| > | in the number of constructors.
| > | That's wasteful if all you want to check is if that
| > | number is smaller than what fits in tag bits
| > | (usually 8 things).
| > |
| > | What this change does is to use a function that can
| > | determine the ineqaulity without computing the size.
| > |
| > | This improves compile time on a module with a
| > | data type that has 10k constructors.
| > | The variance in total time is (suspiciously) high,
| > | but going by the best of 3 the numbers are 8.186s vs 7.511s.
| > | For 1000 constructors the difference isn't noticeable:
| > | 0.646s vs 0.624s.
| > | The hot spots were cgDataCon and cgEnumerationTyCon
| > | where tagForCon is called in a loop.
| > |
| > | One alternative would be to pass down the size.
| > |
| > | Test Plan: harbormaster
| > |
| > | Reviewers: bgamari, simonmar, austin
| > |
| > | Reviewed By: simonmar
| > |
| > | Subscribers: rwbarton, thomie
| > |
| > | Differential Revision: https://phabricator.haskell.org/D4116
| > |
| > |
| > | >---
| > |
| > | faf60e858a293affca463043c830e1edb5685003
| > |  compiler/codeGen/StgCmmClosure.hs | 11 ---
| > |  compiler/types/TyCon.hs   | 16 +++-
| > |  2 files changed, 23 insertions(+), 4 deletions(-)
| > |
| > | diff --git a/compiler/codeGen/StgCmmClosure.hs
| > | b/compiler/codeGen/StgCmmClosure.hs
| > | index 1da1f70..2501ec9 100644
| > | --- a/compiler/codeGen/StgCmmClosure.hs
| > | +++ b/compiler/codeGen/StgCmmClosure.hs
| > | @@ -361,13 +361,18 @@ type 

Family instance consistency

[Simon Peyton Jones via ghc-devs]

Edward
Could you possibly take a look at #14396?   It's going to bite us soon, as 
Alan's Trees That Grow patch lands (see the branch mentioned on the ticket).
(In fact, Alan, I don't know how you build that branch ; I can't build it.)
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa)

[Simon Peyton Jones via ghc-devs]

yes I think it's stopped.  I'' remove my junk-mail rule

| -Original Message-
| From: Ben Gamari [mailto:b...@smart-cactus.org]
| Sent: 27 October 2017 19:44
| To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org
| Subject: Re: FW: [commit: ghc] wip/nfs-locking: Use conventional
| whitespacing for @. (31515fa)
| 
| Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
| 
| > I've received 1500 of these commit messages overnight, and another
| arrives every few seconds.  Are they likely to stop soon?
| >
| Oh dear, this looks like an unfortunate consequence of my pushing a
| branch with the Hadrian history. Have they stopped yet?
| 
| Cheers,
| 
| - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

wip/nfsl-locking

[Simon Peyton Jones via ghc-devs]

Can anyone switch off this torrent of commit messages for wip/nfs-locking?  I'm 
submerged in junk.
I'm about to write a junk-mail rule
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa)

[Simon Peyton Jones via ghc-devs]

I've received 1500 of these commit messages overnight, and another arrives 
every few seconds.  Are they likely to stop soon?

Simon

-Original Message-
From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of 
g...@git.haskell.org
Sent: 27 October 2017 01:06
To: ghc-comm...@haskell.org
Subject: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. 
(31515fa)

Repository : ssh://g...@git.haskell.org/ghc

On branch  : wip/nfs-locking
Link   : 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fchangeset%2F31515fad107d28f83b47d6249dd7b8c1eeb3bc70%2Fghc=02%7C01%7Csimonpj%40microsoft.com%7Cebc410b60526437cbb3708d51d115271%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636446882594775349=KueMNn9bjSn8cimiE1IS1JZSRN0arIrgcpD%2FBeMJ%2FGk%3D=0

>---

commit 31515fad107d28f83b47d6249dd7b8c1eeb3bc70
Author: Andrey Mokhov 
Date:   Fri Feb 26 11:37:47 2016 +

Use conventional whitespacing for @.

See #210.


>---

31515fad107d28f83b47d6249dd7b8c1eeb3bc70
 src/GHC.hs |  2 +-
 src/Rules/Actions.hs   |  2 +-
 src/Rules/Compile.hs   |  2 +-
 src/Rules/Data.hs  |  4 ++--
 src/Rules/Dependencies.hs  |  2 +-
 src/Rules/Documentation.hs |  2 +-
 src/Rules/Generate.hs  |  2 +-
 src/Rules/Library.hs   |  4 ++--
 src/Rules/Program.hs   |  6 +++---
 src/Rules/Register.hs  |  2 +-
 src/Settings/Paths.hs  | 10 +-
 src/Way.hs |  2 +-
 12 files changed, 20 insertions(+), 20 deletions(-)

Diff suppressed because of size. To see it, use:

git diff-tree --root --patch-with-stat --no-color --find-copies-harder 
--ignore-space-at-eol --cc 31515fad107d28f83b47d6249dd7b8c1eeb3bc70
___
ghc-commits mailing list
ghc-comm...@haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-commits=02%7C01%7Csimonpj%40microsoft.com%7Cebc410b60526437cbb3708d51d115271%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636446882594785357=%2BWAgDLBOd5wU3M3bH2Sc6CqEzZM9RpEKUES3H8BU534%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Simplify.hs depends on typechecker

[Simon Peyton Jones via ghc-devs]

I agree.

Both of these code paths go through initTcForLookup which is massive overkill, 
as the comment with `TcEnv.lookupGlobal` says.  There's clearly a ToDo here to 
strip off the redundant stuff and do a minimal lookup.

Would you like to make a ticket?

Simon


|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 24 October 2017 16:40
|  To: ghc-devs@haskell.org
|  Subject: Simplify.hs depends on typechecker
|  
|  Hi,
|  
|  while rebuilding Simplify.o only I noticed that all of the type
|  checker, and HsSyn stuff, and renamer stuff, and so needed to be
|  rebuilt, which I found strange.
|  
|  After a little investigation, it seems that the simplifier depends on
|  CoreMonad, and that pulls some very few type-checker related things:
|  
|  1.
|  import TcRnMonad( initTcForLookup )
|  import {-# SOURCE #-} TcSplice ( lookupThName_maybe )
|  
|  for
|  
|  thNameToGhcName :: TH.Name -> CoreM (Maybe Name)
|  thNameToGhcName th_name = do
|  hsc_env <- getHscEnv
|  liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name)
|  
|  which is not even used in GHC, but only in GHC Plugins, so this could
|  probably be moved to a separate module pulled in by GhcPlugins.hs
|  
|  2.
|  
|  import TcEnv( lookupGlobal )
|  
|  for
|  
|  instance MonadThings CoreM where
|  lookupThing name = do { hsc_env <- getHscEnv
|; liftIO $ lookupGlobal hsc_env name }
|  
|  This might be a bit harder to disentangle. But if successful, it would
|  probably make building GHC in parallel quite a bit faster. And it just
|  seems strange to me that the Core-to-Core code should depend on the
|  type checker…
|  
|  
|  I’m sending this out there in case someone has dug in that direction
|  before and has insights to share.
|  
|  
|  Greetings,
|  Joachim
|  
|  (Attached is a transitively reduced dependency graph of Simplify.hs,
|  created using Iavor’s
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
|  .com%2Fyav%2Fgraphmod%2Fwiki=02%7C01%7Csimonpj%40microsoft.com%7Cb
|  16c817556de4d55d74c08d51af5a8cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C636444565247573129=oHpA%2F%2BHGyc0mHv%2FWj3nzGBiJCM2ufriryF
|  oZYNHSjqk%3D=0).
|  
|  
|  --
|  Joachim “nomeata” Breitner
|m...@joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jo
|  achim-
|  breitner.de%2F=02%7C01%7Csimonpj%40microsoft.com%7Cb16c817556de4d5
|  5d74c08d51af5a8cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63644456
|  5247583137=wO14DxiOaXUOx59N22YoS%2FoC2%2Bi4IEp3bNnB4Dli12U%3D
|  erved=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: forall in constraint

[Simon Peyton Jones via ghc-devs]

  *   Like I say I am DEEPLY suspicious of ForallXImplicitBndrs.  I can’t make 
head or tail of it.  Is see in you patch you define



type ForallXPat (c :: * -> Constraint) (x :: *) =…

   What is this?  Why do we need it? What goes wrong if we remove 
it altogether?



  *   Likewise `forall thing. Data thing` makes no sense to me as a constraint, 
 even with quantified context. Shayan and I discussed this at ICFP and agreed 
it made no sense.  The hoped-for quantified-context extension is NOT a solution.

Overall I’ve lost track of these enormous constraint tuples that seem to be 
associated with Data instances. Can you give a small artificial (ie not full 
GHC) example of why they are necessary?   Perhaps it’s this

data T p = T1 (XT1 p) Int
| T1 (XT2 p) (IdP p)

I suppose that a Data instance would need to have
   instance (Data (XT1 p), Data (XT2p), Data (IdP p)) => Data IT p) 
where…
Is that right?  In which case why do you have all this PostRn stuff in the 
DataId type?  (And why is it called DataId?)


  *   “The first approach leads to a spread of the constraint throughout the 
AST, which gets very messy.”  I don’t understand what the first approach is, or 
why it gets messy.  Could you be more concrete?
  *   “Perhaps the simplest way forward is to get rid of the `thing` parameter 
completely, and introduce the three or so ImplicitBinders variants that are 
used.”   I don’t’ think it could possibly make anything simpler to have three 
separate data types.   Can you illustrate concretely?
It’d be great to explore these issues with small, concrete examples, rather 
than the full glory of GHC, both for our own benefit and the benefit of those 
who will review the patch and (in future) understand the code.

Sorry to be slow

Simon


From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 23 October 2017 22:36
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Re: forall in constraint

In Shayan's implementation he has [1]

data ImplicitBndrs x thing
  = IB
  (XIB x thing)
  thing

  | NewImplicitBndrs
  (XNewImplicitBndrs x thing)

type family XIB   x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs c x thing =
   ( c (XIB   x thing)
   , c (XNewImplicitBndrs x thing)
   )
This gets used, in the same file as

type LSigType   x = ImplicitBndrs x (LType x)
where `thing` is resolved to a specific type.

Because it is all in the same file, there is no problem making a
constraint on anything using LSigType, that mentions LHsType.



But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.

In order to derive a Data instance for anything using `LSigType x`, we
need to be able to specify that a Data instance exists for `LHsType x`.

So we can either do that directly in HsBinds, or try to add it to the existing
DataId constraint in HsExtension.

The first approach leads to a spread of the constraint throughout the AST,
which gets very messy.

The second approach requires being able to specify a
`forall thing. Data thing` constraint in HsExtension.


I tried an intermediate approach, introducing a constraint in HsDecls[3] to 
capture this,
but it eventually runs into needing it in the HsExpr.hs-boot file, which means 
I need
LHsType in that file.

Perhaps the simplest way forward is to get rid of the `thing` parameter 
completely,
and introduce the three or so ImplicitBinders variants that are used.

I hope this does not just confuse things even more.

Alan

[1] 
https://github.com/ghc/ghc/blob/wip/GrowableAST/compiler/hsSyn/AST.hs#L475
[2] 
https://github.com/ghc/ghc/tree/wip/ttg/2017-10-21
[3] 
https://github.com/ghc/ghc/commit/22812296818fe955752fa4762cf72250abd09bf9#diff-7cfa6eef12e44d312aca9ef4af0081b3R1439



On 23 October 2017 at 23:04, Simon Peyton Jones 

RE: forall in constraint

[Simon Peyton Jones via ghc-devs]

I’m lost. Could you give me a bit more context?

I’m deeply suspicious about that ForallXImplicitBndrs thing with strange higher 
kinded parameters.   Smells all wrong to me.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim 
Zimmerman
Sent: 23 October 2017 16:07
To: ghc-devs@haskell.org
Subject: forall in constraint

I am working on the Trees that Grow stuff, and hit a small problem
I have

type family XIB   x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) =
   ( c (XIB   x thing)
   , c (XNewImplicitBndrs x thing)
   )
and I want to extend the DataId constraint

type DataId p =
  ( Data p

  , ForallXImplicitBndrs Data p thing
  )
But the problem is I do not have `thing` at this point, and to get it in the 
code will involve some hs-boot nastiness.
Is there any way to require "forall thing. Data thing" inside the DataId 
constraint?
Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: haddock specializeInstHead

[Simon Peyton Jones via ghc-devs]

I don’t know, but my instinct is to stick to the monomorphic version for now, 
it that’s all you need.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim 
Zimmerman
Sent: 20 October 2017 18:33
To: ghc-devs@haskell.org
Subject: haddock specializeInstHead

I am working the next stage of Trees that Grow into GHC [1], and need to update 
Haddock.
The `Specialize` module[2] exports a single function, `specializeInstHead` 
which is called once, specialised to `GhcRn`.
So all it needs to be for haddock use is

specializeInstHead :: InstHead GhcRn -> InstHead GhcRn
But the entire module is polymorphic in the AST parameter, so it has the 
following instead

specializeInstHead :: (Ord (IdP name), DataId name, SetName (IdP name),
NamedThing (IdP name))
   => InstHead name -> InstHead name

Question: does it need to be so polymorphic?

I am hitting issues getting the type parameter change worked through, and it 
seems a bit pointless to slog on with it if it is unnecessary.

Alan

[1] 
https://github.com/ghc/ghc/tree/wip/ttg-2017-10-13
[2] 
https://github.com/haskell/haddock/blob/a5bdb46185b7c0b3fced9a7fac9a62883d9d57b7/haddock-api/src/Haddock/Interface/Specialize.hs#L87
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: splitting metavariables

[Simon Peyton Jones via ghc-devs]

|  Actually, I wonder if we can put the check in just one spot: coreView.
|  Whenever we use coreView, we're about to inspect a type. And we should
|  never be inspecting a metavariable in this way.

Yes, that's right. Maybe that makes a useful distinction between coreView and 
tcView; the former should never see a meta-variable.

I'm not sure we are fully consistent on when we call each, but it'd be a good 
start.

Go for it

Simon

|  -Original Message-
|  From: Richard Eisenberg [mailto:r...@cs.brynmawr.edu]
|  Sent: 20 October 2017 22:44
|  To: Simon Peyton Jones 
|  Cc: ghc-devs 
|  Subject: splitting metavariables
|  
|  Hi Simon,
|  
|  I just commented
|  (https://ghc.haskell.org/trac/ghc/ticket/14331#comment:35) about a
|  situation where we call splitFunTys on a type that might be a
|  metavariable. (You don't have to read the comment -- that's just to
|  set the context.) Now that I think of it, we should never call the
|  splitXXX functions on metavariables -- any time we do so is wrong. I
|  suppose it's OK if we, say, call splitTyConApp_maybe on (T alpha beta
|  gamma), because we never look through the metavariables there. But it
|  can't possible be write to call splitTyConApp_maybe on alpha.
|  
|  Do you agree? Should we ASSERT that we don't do this?
|  
|  The tcXXX variants are no different in this regard.
|  
|  Actually, I wonder if we can put the check in just one spot: coreView.
|  Whenever we use coreView, we're about to inspect a type. And we should
|  never be inspecting a metavariable in this way.
|  
|  Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: More windows

[Simon Peyton Jones via ghc-devs]

Oddly it's started working.   I have no idea why.  I'll yell if it breaks again.

Simon

| -Original Message-
| From: Ben Gamari [mailto:b...@well-typed.com]
| Sent: 11 October 2017 14:11
| To: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>; Simon Peyton
| Jones <simo...@microsoft.com>; GHC developers <ghc-devs@haskell.org>
| Subject: RE: More windows
| 
| Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
| 
| > Any ideas anyone? When I restart the build, it gets past the blockage
| > (which seems highly specific). But it’s jolly annoying.
| >
| Hi Simon,
| 
| Perhaps let's try this,
| 
|  1. download and run the procmon tool from [1]
|  2. from the "Filter" menu select the "Filter..." option
|  3. select "Path" in the first drop-down
|  4. select "contains" in the second drop-down
|  5. enter "ghc-cabal.exe" in the third text box
|  6. select "Include in the fourth drop-down
|  8. click the "Add" button
|  7. click the "Ok" button
| 
| Now you should be logging events pertaining to the file in question. Now
| simply run `./validate` to try to reproduce the issue.
| 
| With luck this will produce a handful of events, some of which ought to
| point to the process that it responsible for meddling with the GHC
| build.
| 
| Now export this log,
| 
|  1. select "Save" from the "File" menu
|  2. select the "Events displayed using current filter" option
|  3. select the "CSV" format, select a path that will be easy to file
|  4. return this file to me (perhaps via GitHub Gist [2]?)
| 
| Hopefully this will give us some insight into what is happening.
| 
| Cheers,
| 
| - Ben
| 
| 
| [1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
| [2] https://gist.github.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Determine instance method from class method callsite

[Simon Peyton Jones via ghc-devs]

|  lookupInstEnv from the InstEnv module seemed to do it, but it seems to
|  look up the matching key from a set of instEnv keys and not anything
|  that contains the instance bindr. Not sure.

I couldn't understand this.  lookupInstEnv is probably what you want.  It 
returns a ClsInstLookupResult

type InstMatch = (ClsInst, [DFunInstType])

type ClsInstLookupResult
 = ( [InstMatch] -- Successful matches
   , [ClsInst]   -- These don't match but do unify
   , [InstMatch] )   -- Unsafe overlapped instances under Safe Haskell
 -- (see Note [Safe Haskell Overlapping Instances] in
 -- TcSimplify).

Inside the ClsInst of the InstMatches you'll find a DFunId, which is (I think) 
what you are after.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Tillmann Vogt via ghc-devs
|  Sent: 19 October 2017 18:13
|  To: ghc-devs@haskell.org
|  Subject: Re: Determine instance method from class method callsite
|  
|  I have the same problem  with a compiler plugin that I am writing.
|  
|  In GHC Core I need to get from a dict-fun identifier (e.g.
|  $fMyClassDouble to the type class instance bindr (starting with $c).
|  
|  lookupInstEnv from the InstEnv module seemed to do it, but it seems to
|  look up the matching key from a set of instEnv keys and not anything
|  that contains the instance bindr. Not sure.
|  
|  Where is the dictionary lookup that gives me the bindr?
|  
|  What I did so far:
|  
|  evalExpr :: DynFlags -> ModGuts -> CoreExpr -> Var ->  CoreM NodeType
|  evalExpr dflags guts (Var iD) v = do
|  
| hsc_env <- getHscEnv
| eps <- liftIO (hscEPS hsc_env)
| let instEnvs = InstEnvs (eps_inst_env eps)
| (mg_inst_env guts)
| (mkModuleSet (dep_orphs (mg_deps guts)))
| let ty = tyConAppTyCon_maybe (idType iD)
| let cl = fromJust (tyConClass_maybe (fromJust ty))
| let tys = snd (splitTyConApp (idType iD))
| let (matches,_,_) | isDictId iD = lookupInstEnv False instEnvs cl
|  tys
|   | otherwise = ([],[],[])
|  
| let inst = map (nameStableString . varName . is_dfun . fst) matches
|  
| liftIO $ B.appendFile ("debug.txt") (B.pack (show inst))
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7Caa82860ef55a428ab1e908d5
|  1714eb63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364403011206865
|  53=lpbVMttf5W7p%2FGIs3e5pTd6ZS0w4i%2BHwUr9ysRnuCBE%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: GHC rewrite rule type-checking failure

[Simon Peyton Jones via ghc-devs]

For now, I'm trying to determine whether it possible to use the in-scope 
dictionary variables for constraint solving from a built-in rewrite rule.

It would not take deep, pervasive changes.

I suggest that you do /not/ call solveWanteds, but instead make a custom 
constraint solver.  The constraint solver in the type checker is profoundly 
influenced by

  *   The need to discover suitable instantiations for unification variables
  *   The need to generate good error messages
  *   The need for nested implication constraints to handle GADTs, skolem 
escape checks etc
The type checker’s monad is full of junk that you don’t need or want in this 
simpler context.  Just look at TcRnTypes.TcGblEnv and TcLclEnv.


I think you don’t need either of those things here.I think you probably 
only want type-class constraints, not equalities (which add a great deal of 
complexity).

You just want to say

  *   I’m trying to solve Eq [a].  Ah I have an instance for that.
  *   I’m trying to solve Eq a.  Ah, I have an in-scope Id with that type.
In fact, we already have something a bit like this, for ground class 
constraints.  See TcInteract.shortCutSolver, and Note [Shortcut solving] in 
that file.  So it’s not hard.   [Mumble mumble: instance decls with variables 
not bound in the head might be a problem.  But I doubt that’s what you want.]

Other thoughts

  *   To make this work you’d need access to the top-level class instances in 
rules.  That’s a change but not a difficult one.  The simplifier already 
carries around the top-level type-family instances, so you could add the class 
instances in a similar way..
  *   I’m more concerned about how you’d express all this in the concrete 
syntax of a RULE.  Maybe you don’t need to do that?  It’s all generated 
thorough the API?
  *   Even if you don’t need concrete syntax, you’d still need abstract syntax, 
some change to the CoreRule data type.  And I’m not sure what exactly that is.

I’m unlikely to do all of this myself, but I’m happy advise; but without making 
a prior commitment to incorporating the result in GHC.  We’d have to see how it 
goes.

Simon

From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of 
Conal Elliott
Sent: 12 October 2017 20:02
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Re: GHC rewrite rule type-checking failure

For now, I'm trying to determine whether it possible to use the in-scope 
dictionary variables for constraint solving from a built-in rewrite rule. I 
guess (unsure) my question is how to set up a call to `solveWanteds` to take 
those variables into account when solving a given constraint/predicate.

On Thu, Oct 12, 2017 at 11:07 AM, Conal Elliott 
> wrote:
Thanks for the helpful reply, Simon!

> > The new bit here is that `$dC'` is not found via matching in the LHS, but
> > rather by instance resolution from `k`, which does appear explicitly in
> > the LHS

> Well this would be something qualitatively new. We don’t that ability in
> rules; and it’s far from clear to me what it would mean anyway. I suppose
> that if k was instantiated to a ground type then you might hope to solve it,
> but what if it was instantiated to some in-scope type variable t, and some
> variable of type (C t) was in scope. Should that work too?

Yes, we'd want to use in-scope dictionary variables to help solve the needed
constraints in the presence of polymorphism. I've run into exactly this need
in my own manually programmed ("built-in") rewrite rules. Would it be possible
to do so (without deep/pervasive changes to GHC)?

> Happily it sounds as if you are making progress with help from Joachim.

No, I think Joachim agrees that it's impractical to write all of the needed
rule specializations, and that generating then programmatically would be less
convenient than the implementing the built-in rules as I do now.

Cheers, -- Conal

On Wed, Oct 4, 2017 at 2:08 AM, Simon Peyton Jones 
> wrote:
The new bit here is that `$dC'` is not found via matching in the LHS, but 
rather by instance resolution from `k`, which does appear explicitly in the LHS

Well this would be something qualitatively new.  We don’t that ability in 
rules; and it’s far from clear to me what it would mean anyway.  I suppose that 
if k was instantiated to a ground type then you might hope to solve it, but 
what if it was instantiated to some in-scope type variable t, and some variable 
of type (C t) was in scope.  Should that work too?

I’m highly dubious.

Happily it sounds as if you are making progress with help from Joachim.

Simon

From: conal.elli...@gmail.com 
[mailto:conal.elli...@gmail.com] On Behalf Of 
Conal Elliott
Sent: 03 October 2017 16:30
To: Simon Peyton Jones >
Subject: Re: GHC rewrite rule type-checking 

RE: Invariants about UnivCo?

[Simon Peyton Jones via ghc-devs]

5) The first suspect turned out to be the culprit: I was using my plugin's 
by-fiat coercions in the most naive possible way, always simply `EvCast ev 
(fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new 
Given unlifted equality witnesses from existing Given unlifted equality 
witnesses when simplifying Given constraints (e.g. for example reducing a 
plugin-specific type family application on one side of an unlifted equality 
type ~#).

I don’t understand the issue here at all. Can you give a concrete example?

Simon
From: Nicolas Frisby [mailto:nicolas.fri...@gmail.com]
Sent: 09 October 2017 03:50
To: Richard Eisenberg 
Cc: Simon Peyton Jones ; ghc-devs@haskell.org
Subject: Re: Invariants about UnivCo?


Yep, that's the current question: why does preferring `EvCoercion (TransCo 
UnivCo (TransCo co UnivCo))` to `EvCast (EvCoercion co) UnivCo` seem to matter? 
In my scenario, `co` is the evidence for a Given equality type. And the 
coercion I'm building is also a Given constraint's evidence -- I'm simplifying 
Givens.

The only hard indication I currently have of what "goes wrong" is the ASSERT 
failure described in the previous email.

I'm planning to spend some time investigating. I would appreciate any cycles 
you spend on it!

On Sun, Oct 8, 2017, 18:53 Richard Eisenberg 
> wrote:
Thanks for this status report. If I'm to boil it down to the question you seem 
to be asking: What does changing EvCast ... to EvCoercion ... fix the problem? 
I'm not sure of the answer at this point, but I want to make sure I understand 
the question before I go digging for an answer. It's always possible a Note is 
wrong!

Thanks for this!

Richard

On Oct 7, 2017, at 8:19 PM, Nicolas Frisby 
> wrote:

I can happily report some progress: I'm seeing no more Core lint errors!

1) Thank you both Richard and Simon for your pointers -- 
-fprint-typechecker-elaboration in particular was a revelation.

2) Simon, I intend to match the spirit of the favor you requested, but not to 
the letter. My goal with this project is to write a typechecker plugin for 
achieving row types _without_ editing GHC's source code. I'm keeping an 
annotated bibliography of things I've studied (papers, guide/wiki/blog, source 
Notes, etc). (It's nice to put a bunch of related notes in the same text file!) 
I'm also logging my epiphanies, which I do intend to write-up in some kind of 
document (probably on the dev wiki). I'm planning a section for suggesting 
which Notes should be adjusted/expanded, but I don't anticipate feeling 
comfortable enough to actually edit the Notes myself. This is unfortunately 
just a hobby project. My intent is to offer you, Richard, and other experts the 
details of what wasn't clear to me.

3) I confirmed that the lack of cobox uniques in the dump output was indeed due 
to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every 
coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to 
persist those uniques just for debugging purposes.

4) My top-level error is an "out of scope cobox" Lint error, but (once I 
patched the dumper) the output of -fprint-typechecker-elaboration showed 
sufficient bindings for all of the cobox occurrences, even the one that the 
Lint error was flagging! Stymied, I finally did a -DDEBUG build of the 
ghc-8.2.2-rc1 tag and used that. It ultimately lead to me finding my mistakes. 
(New wisdom: always use a DEBUG build when authoring a plugin. (... Duh.))

4a) ASSERT failures showed that I was invoking `substTy' without correctly 
initializing the `InScopeSet'. I also was ignorant that I should be using 
`extendTvSubstAndInScope' instead of just `extendTvSubst'. I don't think this 
was relevant to my particular Lint error, but I fixed it if only to see further 
ASSERT failures.

4b) Fixing my `InScopeSet's ASSERT failure revealed another: `extendIdSubst' 
was being called with a CoVar! That's something that my plugin code absolutely 
does not do, so at that point I knew that some higher-level operation I was 
doing was knocking the rest of GHC's pipeline off the rails. (In particular, I 
traced this ASSERT callstack to extendIdSubst called from simpleOptExpr called 
from mkInlineUnfoldingWithArity called from DsBinds. I stopped there.)

5) The first suspect turned out to be the culprit: I was using my plugin's 
by-fiat coercions in the most naive possible way, always simply `EvCast ev 
(fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new 
Given unlifted equality witnesses from existing Given unlifted equality 
witnesses when simplifying Given constraints (e.g. for example reducing a 
plugin-specific type family application on one side of an unlifted equality 
type ~#).

In summary, I see no more ASSERT failures or Lint errors having now changed my 
plugin to 

RE: Invariants about UnivCo?

[Simon Peyton Jones via ghc-devs]

3) I confirmed that the lack of cobox uniques in the dump output was indeed due 
to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every 
coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to 
persist those uniques just for debugging purposes.

Would you like to offer a patch?

I eventually gave up on the via-iface-type route for debug printing.  See 
TyCoRep.pprPrecType, which checks for debugStyle and if so calls a simple but 
direct debug_ppr_ty.  Not beautiful, but very direct.  For debugging it’s 
terrible if tidying and other stuff goes on.

Maybe we want the same for coercions?

Simon

From: Nicolas Frisby [mailto:nicolas.fri...@gmail.com]
Sent: 09 October 2017 03:50
To: Richard Eisenberg 
Cc: Simon Peyton Jones ; ghc-devs@haskell.org
Subject: Re: Invariants about UnivCo?


Yep, that's the current question: why does preferring `EvCoercion (TransCo 
UnivCo (TransCo co UnivCo))` to `EvCast (EvCoercion co) UnivCo` seem to matter? 
In my scenario, `co` is the evidence for a Given equality type. And the 
coercion I'm building is also a Given constraint's evidence -- I'm simplifying 
Givens.

The only hard indication I currently have of what "goes wrong" is the ASSERT 
failure described in the previous email.

I'm planning to spend some time investigating. I would appreciate any cycles 
you spend on it!

On Sun, Oct 8, 2017, 18:53 Richard Eisenberg 
> wrote:
Thanks for this status report. If I'm to boil it down to the question you seem 
to be asking: What does changing EvCast ... to EvCoercion ... fix the problem? 
I'm not sure of the answer at this point, but I want to make sure I understand 
the question before I go digging for an answer. It's always possible a Note is 
wrong!

Thanks for this!

Richard

On Oct 7, 2017, at 8:19 PM, Nicolas Frisby 
> wrote:

I can happily report some progress: I'm seeing no more Core lint errors!

1) Thank you both Richard and Simon for your pointers -- 
-fprint-typechecker-elaboration in particular was a revelation.

2) Simon, I intend to match the spirit of the favor you requested, but not to 
the letter. My goal with this project is to write a typechecker plugin for 
achieving row types _without_ editing GHC's source code. I'm keeping an 
annotated bibliography of things I've studied (papers, guide/wiki/blog, source 
Notes, etc). (It's nice to put a bunch of related notes in the same text file!) 
I'm also logging my epiphanies, which I do intend to write-up in some kind of 
document (probably on the dev wiki). I'm planning a section for suggesting 
which Notes should be adjusted/expanded, but I don't anticipate feeling 
comfortable enough to actually edit the Notes myself. This is unfortunately 
just a hobby project. My intent is to offer you, Richard, and other experts the 
details of what wasn't clear to me.

3) I confirmed that the lack of cobox uniques in the dump output was indeed due 
to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every 
coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to 
persist those uniques just for debugging purposes.

4) My top-level error is an "out of scope cobox" Lint error, but (once I 
patched the dumper) the output of -fprint-typechecker-elaboration showed 
sufficient bindings for all of the cobox occurrences, even the one that the 
Lint error was flagging! Stymied, I finally did a -DDEBUG build of the 
ghc-8.2.2-rc1 tag and used that. It ultimately lead to me finding my mistakes. 
(New wisdom: always use a DEBUG build when authoring a plugin. (... Duh.))

4a) ASSERT failures showed that I was invoking `substTy' without correctly 
initializing the `InScopeSet'. I also was ignorant that I should be using 
`extendTvSubstAndInScope' instead of just `extendTvSubst'. I don't think this 
was relevant to my particular Lint error, but I fixed it if only to see further 
ASSERT failures.

4b) Fixing my `InScopeSet's ASSERT failure revealed another: `extendIdSubst' 
was being called with a CoVar! That's something that my plugin code absolutely 
does not do, so at that point I knew that some higher-level operation I was 
doing was knocking the rest of GHC's pipeline off the rails. (In particular, I 
traced this ASSERT callstack to extendIdSubst called from simpleOptExpr called 
from mkInlineUnfoldingWithArity called from DsBinds. I stopped there.)

5) The first suspect turned out to be the culprit: I was using my plugin's 
by-fiat coercions in the most naive possible way, always simply `EvCast ev 
(fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new 
Given unlifted equality witnesses from existing Given unlifted equality 
witnesses when simplifying Given constraints (e.g. for example reducing a 
plugin-specific type family application on one side of an unlifted equality 
type ~#).

RE: More windows

[Simon Peyton Jones via ghc-devs]

Any ideas anyone?   When I restart the build, it gets past the blockage (which 
seems highly specific).  But it’s jolly annoying.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones via ghc-devs
Sent: 04 October 2017 17:25
To: Phyx <loneti...@gmail.com>; ghc-devs@haskell.org
Subject: RE: More windows

As you’ll see the directory is empty when the crash happens.  And yes the 
folder is excluded (from virus checking).

Also this behaviour is new.

Simon

From: Phyx [mailto:loneti...@gmail.com]
Sent: 04 October 2017 14:17
To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>>; 
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
Subject: Re: More windows


This looks like a file lock issue. Just to double check, but do you have the 
build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
Now in my Windows build, staring with “sh validate –fast –no-clean” I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( 
libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, 
bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( 
libraries\Cabal\Cabal\Distribution\Simple.hs, 
bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, 
bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D=0>:
 
utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D=0>:
 No such file or directory

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D=0>:
 utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus “sh validate –fast”, I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f 
ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D=0>
 phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141

RE: In C--: should CmmCall and CmmProc agree on their live registers?

[Simon Peyton Jones via ghc-devs]

Moritz

I have this stuff all paged out.  Would you like to give a couple of concrete 
examples of what you have in mind, with any design alternatives?  And 
illustrate your suggestion about propagation, which I don't yet grok.

Thanks

Simon

|  -Original Message-
|  From: Moritz Angermann [mailto:moritz.angerm...@gmail.com]
|  Sent: 06 October 2017 04:37
|  To: Simon Peyton Jones 
|  Cc: GHC developers 
|  Subject: Re: In C--: should CmmCall and CmmProc agree on their live
|  registers?
|  
|  Hi Simon,
|  
|  no, I did not until now. Thank you! As such it is acceptable that the
|  CmmCalls set of live registers is a superset of the CmmProcs live registers
|  that is called.
|  
|  Say we shrink the set of live registers of the CmmProc, as we determine that
|  some of the arguments passed in registers are not used in the graph at all.
|  Would we want to propagate this information to the CmmCall if possible?
|  
|  Cheers,
|   Moritz
|  
|  
|  > On Oct 5, 2017, at 5:59 PM, Simon Peyton Jones 
|  wrote:
|  >
|  > Did you ever get a reply to this?
|  >
|  > In the output of the codegen, CmmProcs should have no live registers apart
|  from those used to pass args, and the standard ones.
|  >
|  > Simon
|  >
|  > |  -Original Message-
|  > |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  > | Moritz  Angermann
|  > |  Sent: 22 September 2017 07:33
|  > |  To: GHC developers 
|  > |  Subject: In C--: should CmmCall and CmmProc agree on their live
|  registers?
|  > |
|  > |  Hi,
|  > |
|  > |  apologies for writing so many emails recently. This is a minor
|  > | spinoff from  the "The Curious Case of T6084" email.
|  > |
|  > |  While digging into it, I keep asking myself if CmmProc’s live
|  > | registers  should match those of the CmmCall that is calling it?
|  > |
|  > |  Is there any invariant we try to enforce or would want to enforce?
|  > |
|  > |  - Can the CmmProcs live registers be a strict superset of
|  > |the corresponding CmmCalls?
|  > |
|  > |From the source comments in `compiler/cmm/Cmm.hs`:
|  > |> Registers live on entry. Note that the set of live
|  > |> registers will be correct in generated C-- code, but
|  > |> not in hand-written C-- code. However,
|  > |> splitAtProcPoints calculates correct liveness
|  > |> information for CmmProcs.
|  > |
|  > |I would assume that this is an invalid case?
|  > |
|  > |  - Can the CmmProcs live registers be a strict subset of
|  > |the corresponding CmmCalls?
|  > |
|  > |This case however seems to be valid case.  However, this
|  > |makes me wonder if we can, and should(?) propagate the
|  > |live register info from the CmmProc to the CmmCall so
|  > |that they match up, and the registers are not kept live
|  > |at the origin of the CmmCall if they aren’t needed?  And
|  > |as such potentially compute anything to put into the
|  > |registers the CmmCall considers live, but the CmmProc
|  > |would ignore anyway?
|  > |
|  > |  Cheers,
|  > |   Moritz
|  > |  ___
|  > |  ghc-devs mailing list
|  > |  ghc-devs@haskell.org
|  > |
|  > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
|  > | .haskell
|  > |  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  > |
|  > | devs=02%7C01%7Csimonpj%40microsoft.com%7C6009bb0f47a447a4217708
|  > | d50183ce
|  > | fa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416587981602708
|  > | data=vII
|  > |  rlKVJa6E%2FBvVz5Sod1c544nw6gsGp54Mlhr7bQ8g%3D=0

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

RE: Determine instance method from class method callsite

[Simon Peyton Jones via ghc-devs]

well the HsWrapper might have something much more complicated than a DFunId.  
It might need to construct the dictionary for Eq [a] from the DFun for Eq [a] 
and a dictionary for Eq a.

it would be easy to resolve the Var of the instance method.
I don't know what "the var of the instance method" is.

I feel I'm missing the point.  maybe others can help?

Simon

From: Robin Palotai [mailto:palotai.ro...@gmail.com]
Sent: 05 October 2017 11:17
To: Simon Peyton Jones 
Cc: GHC developers ; haskell 
Subject: Re: Determine instance method from class method callsite

Hello Simon - I outlined the approach in 
https://github.com/google/haskell-indexer/issues/73.
TLDR is
1) at callsite, indeed the HsWrapper needs to be analysed to get the instance 
DFunId
2) at instance declaration site, we need to again take note of the DFunId.
It is slightly more complicated than I expected the API. I would have expected 
that from having the Var of a class method, and the  of the instance 
(here DFunId), it would be easy to resolve the Var of the instance method.
But it seems there's no direct way, one has to build a lookup table from the 
instance methods' (DFunId + plain stringy method name), and look that up from 
the callsite.
Or I might have missed a way to deconstruct / query a DFunId for the method 
Vars.
I'll put augmenting the commentary on my mental TODO list :)

2017-10-05 11:58 GMT+02:00 Simon Peyton Jones 
>:
Did you get a reply?

I'm not 100% certain of your question, but consider the

bar = show 
for some expression e.   In the input to the type type checker the syntax tree 
for the RHS will be something like
HsApp (HsVar "show") 

(The "show" isn't really a string, it's the Name for the class method.)

After typechecking the syntax tree is augmented (or "elaborated") with type and 
dictionary application.  So in concrete form it might look like
bar = show @Foo dShowFoo 

Because show :: forall a. Show a => a -> String, so show is apply to the type 
of its argument, and then to the dictionary.

In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The 
elaborated syntax tree look like

HsApp (HsWrap  (HsVar "show"))
  

The  part expresses the type and dictionary application. In this case 
it'll look like
WpEvApp dShowFoo (WpTyApp Foo WpHole)

See the notes with `HsWrapper` in TcEvidence.

Does that help?

It would be great to augment the 
https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info 
(insofar as it doesn't have it already).  If you augment I can review.  Email 
is quickly lost.

Simon
From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Robin Palotai
Sent: 19 September 2017 06:39
To: GHC developers >; haskell 
>
Subject: Determine instance method from class method callsite

Sorry, I messed up subject and mailing list. Copying to both list now after the 
mistake (wanted only ghc-devs for specificity).

Thanks!

2017-09-19 7:36 GMT+02:00 Robin Palotai 
>:
Hello GHC devs,

Before inventing the wheel, want to check if there is a GHC API way to look up 
the (fully) resolved instance method from a class method.

For example, given a code

data Foo Int deriving Show

bar = show (Foo 3)

when inspecting the Typechecked AST for bar's show call, I would like to get to 
the Name / Id of 'show' of the 'Show' typeclass.

I believe I could use splitHsSigmaTy on the HsType of the function call to get 
the context, and then evaluate the HsWrapper somehow to find out what instance 
dictionary is applied to the class restriction in the context, and then look up 
the instance method from the dictionary..

Two questions:

1) Is there maybe functionality for this?

2) If not, is there any guarantee about the constraint order in the context, at 
the method call? So I could more easily determine which constraint's 
application to look for..

Any hints welcome && Thank you!
Robin


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

RE: In C--: should CmmCall and CmmProc agree on their live registers?

[Simon Peyton Jones via ghc-devs]

Did you ever get a reply to this?

In the output of the codegen, CmmProcs should have no live registers apart from 
those used to pass args, and the standard ones.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz
|  Angermann
|  Sent: 22 September 2017 07:33
|  To: GHC developers 
|  Subject: In C--: should CmmCall and CmmProc agree on their live registers?
|  
|  Hi,
|  
|  apologies for writing so many emails recently. This is a minor spinoff from
|  the "The Curious Case of T6084" email.
|  
|  While digging into it, I keep asking myself if CmmProc’s live registers
|  should match those of the CmmCall that is calling it?
|  
|  Is there any invariant we try to enforce or would want to enforce?
|  
|  - Can the CmmProcs live registers be a strict superset of
|the corresponding CmmCalls?
|  
|From the source comments in `compiler/cmm/Cmm.hs`:
|> Registers live on entry. Note that the set of live
|> registers will be correct in generated C-- code, but
|> not in hand-written C-- code. However,
|> splitAtProcPoints calculates correct liveness
|> information for CmmProcs.
|  
|I would assume that this is an invalid case?
|  
|  - Can the CmmProcs live registers be a strict subset of
|the corresponding CmmCalls?
|  
|This case however seems to be valid case.  However, this
|makes me wonder if we can, and should(?) propagate the
|live register info from the CmmProc to the CmmCall so
|that they match up, and the registers are not kept live
|at the origin of the CmmCall if they aren’t needed?  And
|as such potentially compute anything to put into the
|registers the CmmCall considers live, but the CmmProc
|would ignore anyway?
|  
|  Cheers,
|   Moritz
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7C6009bb0f47a447a4217708d50183ce
|  fa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416587981602708=vII
|  rlKVJa6E%2FBvVz5Sod1c544nw6gsGp54Mlhr7bQ8g%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Determine instance method from class method callsite

[Simon Peyton Jones via ghc-devs]

Did you get a reply?

I’m not 100% certain of your question, but consider the

bar = show 
for some expression e.   In the input to the type type checker the syntax tree 
for the RHS will be something like
HsApp (HsVar “show”) 

(The “show” isn’t really a string, it’s the Name for the class method.)

After typechecking the syntax tree is augmented (or “elaborated”) with type and 
dictionary application.  So in concrete form it might look like
bar = show @Foo dShowFoo 

Because show :: forall a. Show a => a -> String, so show is apply to the type 
of its argument, and then to the dictionary.

In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The 
elaborated syntax tree look like

HsApp (HsWrap  (HsVar “show”))
  

The  part expresses the type and dictionary application. In this case 
it’ll look like
WpEvApp dShowFoo (WpTyApp Foo WpHole)

See the notes with `HsWrapper` in TcEvidence.

Does that help?

It would be great to augment the 
https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info 
(insofar as it doesn’t have it already).  If you augment I can review.  Email 
is quickly lost.

Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Robin Palotai
Sent: 19 September 2017 06:39
To: GHC developers ; haskell 
Subject: Determine instance method from class method callsite

Sorry, I messed up subject and mailing list. Copying to both list now after the 
mistake (wanted only ghc-devs for specificity).

Thanks!

2017-09-19 7:36 GMT+02:00 Robin Palotai 
>:
Hello GHC devs,

Before inventing the wheel, want to check if there is a GHC API way to look up 
the (fully) resolved instance method from a class method.

For example, given a code

data Foo Int deriving Show

bar = show (Foo 3)

when inspecting the Typechecked AST for bar's show call, I would like to get to 
the Name / Id of 'show' of the 'Show' typeclass.

I believe I could use splitHsSigmaTy on the HsType of the function call to get 
the context, and then evaluate the HsWrapper somehow to find out what instance 
dictionary is applied to the class restriction in the context, and then look up 
the instance method from the dictionary..

Two questions:

1) Is there maybe functionality for this?

2) If not, is there any guarantee about the constraint order in the context, at 
the method call? So I could more easily determine which constraint's 
application to look for..

Any hints welcome && Thank you!
Robin

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

RE: More windows

[Simon Peyton Jones via ghc-devs]

As you’ll see the directory is empty when the crash happens.  And yes the 
folder is excluded.

Also this behaviour is new.

Simon

From: Phyx [mailto:loneti...@gmail.com]
Sent: 04 October 2017 14:17
To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org
Subject: Re: More windows


This looks like a file lock issue. Just to double check, but do you have the 
build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
Now in my Windows build, staring with “sh validate –fast –no-clean” I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( 
libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, 
bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( 
libraries\Cabal\Cabal\Distribution\Simple.hs, 
bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, 
bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D=0>:
 
utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D=0>:
 No such file or directory

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D=0>:
 utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus “sh validate –fast”, I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f 
ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D=0>
 phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D=0>:
 utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

But trying “sh validate –fast” once more succeeds:

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkU

More windows

[Simon Peyton Jones via ghc-devs]

Now in my Windows build, staring with "sh validate -fast -no-clean" I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( 
libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, 
bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( 
libraries\Cabal\Cabal\Distribution\Simple.hs, 
bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, 
bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No 
such file or directory

make[1]: *** [utils/ghc-cabal/ghc.mk:57: 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus "sh validate -fast", I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** [utils/ghc-cabal/ghc.mk:57: 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

But trying "sh validate -fast" once more succeeds:

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

"cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe

"inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot 
--with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" 
--with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg"  
--package-db=C:/code/HEAD/libraries/bootstrapping.conf 
--disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci 
--disable-library-profiling --disable-shared 
--with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour" 
--configure-option=CFLAGS="-Wall -fno-stack-protector-Wno-error=inline" 

RE: Windows build broken

[Simon Peyton Jones via ghc-devs]

I’m in a shell inside emacs.
My $SHELL variable (which emacs uses to invoke it) is
c:/msys64/usr/bin/bash.exe

Should it be something else?

run 'export MSYSTEM=MINGW64' to change subsystem.

That worked.  Should I add it to my .bashrc, or are you going to do something 
else?

Thanks


From: Phyx [mailto:loneti...@gmail.com]
Sent: 04 October 2017 13:30
To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org
Subject: Re: Windows build broken

Hi Simon,

You seem to be in an msys shell instead of a mingw-64 shell (they have 
different startup shortcuts). We don't support the msys shell as we only want 
to compile for native windows.

You should use the shortcut marked mingw-64.

Alternatively to get you going in aclocal.m4 remove line 112.

Or

run 'export MSYSTEM=MINGW64' to change subsystem.



The recent llvm changes now force the host validation on all targets, I'll add 
msys when I get home.

Kind regards,

Tamar

On Wed, Oct 4, 2017, 11:19 Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
My Windows build is broken again.  With a clean checkout, I get “”

Target platform inferred as: x86_64-unknown-mingw32

Unknown OS msys
How can I get past this?  Full log below.
Simon




make[1]: Leaving directory '/c/code/HEAD/testsuite'

['libraries/array/', 'libraries/base/', 'libraries/binary/', 
'libraries/bytestring/', 'libraries/Cabal/Cabal', 'libraries/Cabal/', 
'libraries/compact/', 'libraries/containers/', 'libraries/deepseq/', 
'libraries/directory/', 'libraries/doc/', 'libraries/dph/dph-base', 
'libraries/dph/dph-prim-interface', 'libraries/dph/dph-prim-seq', 
'libraries/dph/dph-prim-par', 'libraries/dph/dph-lifted-base', 
'libraries/dph/dph-lifted-boxed', 'libraries/dph/dph-lifted-copy', 
'libraries/dph/dph-lifted-vseg', 'libraries/dph/', 'libraries/dph/', 
'libraries/filepath/', 'libraries/ghc-boot/', 'libraries/ghc-boot-th/', 
'libraries/ghc-compact/', 'libraries/ghc-prim/', 'libraries/ghci/', 
'libraries/haskeline/', 'libraries/hoopl/', 'libraries/hpc/', 
'libraries/integer-gmp/', 'libraries/integer-simple/', 'libraries/mtl/', 
'libraries/parallel/', 'libraries/parsec/', 'libraries/pretty/', 
'libraries/primitive/', 'libraries/process/', 'libraries/random/', 
'libraries/stm/', 'libraries/template-haskell/', 'libraries/terminfo/', 
'libraries/text/', 'libraries/time/', 'libraries/transformers/', 
'libraries/unix/', 'libraries/vector/', 'libraries/Win32/', 'libraries/xhtml/']

Creating 
libraries/array/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/base/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/binary/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/bytestring/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/Cabal/Cabal/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/containers/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/deepseq/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/directory/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D=0>

Creating 
libraries/dph/dph-base/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk

Windows build broken

[Simon Peyton Jones via ghc-devs]

My Windows build is broken again.  With a clean checkout, I get ""

Target platform inferred as: x86_64-unknown-mingw32

Unknown OS msys
How can I get past this?  Full log below.
Simon




make[1]: Leaving directory '/c/code/HEAD/testsuite'

['libraries/array/', 'libraries/base/', 'libraries/binary/', 
'libraries/bytestring/', 'libraries/Cabal/Cabal', 'libraries/Cabal/', 
'libraries/compact/', 'libraries/containers/', 'libraries/deepseq/', 
'libraries/directory/', 'libraries/doc/', 'libraries/dph/dph-base', 
'libraries/dph/dph-prim-interface', 'libraries/dph/dph-prim-seq', 
'libraries/dph/dph-prim-par', 'libraries/dph/dph-lifted-base', 
'libraries/dph/dph-lifted-boxed', 'libraries/dph/dph-lifted-copy', 
'libraries/dph/dph-lifted-vseg', 'libraries/dph/', 'libraries/dph/', 
'libraries/filepath/', 'libraries/ghc-boot/', 'libraries/ghc-boot-th/', 
'libraries/ghc-compact/', 'libraries/ghc-prim/', 'libraries/ghci/', 
'libraries/haskeline/', 'libraries/hoopl/', 'libraries/hpc/', 
'libraries/integer-gmp/', 'libraries/integer-simple/', 'libraries/mtl/', 
'libraries/parallel/', 'libraries/parsec/', 'libraries/pretty/', 
'libraries/primitive/', 'libraries/process/', 'libraries/random/', 
'libraries/stm/', 'libraries/template-haskell/', 'libraries/terminfo/', 
'libraries/text/', 'libraries/time/', 'libraries/transformers/', 
'libraries/unix/', 'libraries/vector/', 'libraries/Win32/', 'libraries/xhtml/']

Creating libraries/array/ghc.mk

Creating libraries/base/ghc.mk

Creating libraries/binary/ghc.mk

Creating libraries/bytestring/ghc.mk

Creating libraries/Cabal/Cabal/ghc.mk

Creating libraries/containers/ghc.mk

Creating libraries/deepseq/ghc.mk

Creating libraries/directory/ghc.mk

Creating libraries/dph/dph-base/ghc.mk

Creating libraries/dph/dph-prim-interface/ghc.mk

Creating libraries/dph/dph-prim-seq/ghc.mk

Creating libraries/dph/dph-prim-par/ghc.mk

Creating libraries/dph/dph-lifted-base/ghc.mk

Creating libraries/dph/dph-lifted-boxed/ghc.mk

Creating libraries/dph/dph-lifted-copy/ghc.mk

Creating libraries/dph/dph-lifted-vseg/ghc.mk

Creating libraries/filepath/ghc.mk

Creating libraries/ghc-boot/ghc.mk

Creating libraries/ghc-boot-th/ghc.mk

Creating libraries/ghc-compact/ghc.mk

Creating libraries/ghc-prim/ghc.mk

Creating libraries/ghci/ghc.mk

Creating libraries/haskeline/ghc.mk

Creating libraries/hoopl/ghc.mk

Creating libraries/hpc/ghc.mk

Creating libraries/integer-gmp/ghc.mk

Creating libraries/integer-simple/ghc.mk

Creating libraries/mtl/ghc.mk

Creating libraries/parallel/ghc.mk

Creating libraries/parsec/ghc.mk

Creating libraries/pretty/ghc.mk

Creating libraries/primitive/ghc.mk

Creating libraries/process/ghc.mk

Creating libraries/random/ghc.mk

Creating libraries/stm/ghc.mk

Creating libraries/template-haskell/ghc.mk

Creating libraries/terminfo/ghc.mk

Creating libraries/text/ghc.mk

Creating libraries/time/ghc.mk

Creating libraries/transformers/ghc.mk

Creating libraries/unix/ghc.mk

Creating libraries/vector/ghc.mk

Creating libraries/Win32/ghc.mk

Creating libraries/xhtml/ghc.mk

Booting .

Booting libraries/base/

Booting libraries/directory/

Booting libraries/integer-gmp/

Booting libraries/process/

Booting libraries/terminfo/

Booting libraries/time/

Booting libraries/unix/

checking for gfind... no

checking for find... /usr/bin/find

checking for sort... /usr/bin/sort

checking for GHC version date... inferred 8.3.20171004

checking for GHC Git commit id... inferred 
3030eee24c9d538f7ae2c854fd86129563b6ddf3

checking for ghc... /c/fp/ghc-8.0.2/bin/ghc

checking version of ghc... 8.0.2

GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc

checking build system type... x86_64-pc-msys

checking host system type... x86_64-pc-msys

checking target system type... x86_64-pc-msys

Build platform inferred as: x86_64-unknown-mingw32

Host platform inferred as: x86_64-unknown-mingw32

Target platform inferred as: x86_64-unknown-mingw32

Unknown OS msys

/c/code/HEAD$ git pull

Already up-to-date.

/c/code/HEAD$ git submodule update

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

RE: GHC rewrite rule type-checking failure

[Simon Peyton Jones via ghc-devs]

The new bit here is that `$dC'` is not found via matching in the LHS, but 
rather by instance resolution from `k`, which does appear explicitly in the LHS

Well this would be something qualitatively new.  We don’t that ability in 
rules; and it’s far from clear to me what it would mean anyway.  I suppose that 
if k was instantiated to a ground type then you might hope to solve it, but 
what if it was instantiated to some in-scope type variable t, and some variable 
of type (C t) was in scope.  Should that work too?

I’m highly dubious.

Happily it sounds as if you are making progress with help from Joachim.

Simon

From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of 
Conal Elliott
Sent: 03 October 2017 16:30
To: Simon Peyton Jones 
Subject: Re: GHC rewrite rule type-checking failure


The revised example I gave earlier in the thread:

``` haskell
class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f 
#-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
-- bound by the RULE "morph/(.)"
```

A hypothetical generated Core rule (tweaked slightly from Joachim's note):

``` haskell
forall (@ k) (@ b) (@ c) (@ a)
   ($dC :: C (->))
   (f :: a -> b) (g :: b -> c).
  morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f)
  = comp @ k @ b @ c @ a
  $dC'
  (morph @ k @ b @ c g)
  (morph @ k @ a @ b f)
 where
   $dC' :: C k
```

The new bit here is that `$dC'` is not found via matching in the LHS, but 
rather by instance resolution from `k`, which does appear explicitly in the 
LHS. If `C k` cannot be solved, the rule fails. The "where" clause here lists 
the dictionary variables to be instantiated by instance resolution rather than 
matching.

-- Conal


On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones 
> wrote:
But synthesising from what?

And currently no: there is no type-class dictionary synthesis after the type 
checker.  Not impossible I suppose, but one more fragility: a rule does not 
fire because some synthesis thing didn’t happen.Maybe give an 
as-simple-as-poss example of what you have in mind, now you understand the 
situation better?   With all the type and dictionary abstractions written 
explicitly…

S

From: conal.elli...@gmail.com 
[mailto:conal.elli...@gmail.com] On Behalf Of 
Conal Elliott
Sent: 03 October 2017 15:56
To: Simon Peyton Jones >

Subject: Re: GHC rewrite rule type-checking failure

Thanks, Simon. Your explanation make sense to me. Do you think that the rewrite 
rule mechanism could be enhanced to try synthesizing the needed dictionaries 
after LHS matching and before RHS instantiation? I'm doing as much now in my 
compiling-to-categories plugin, but without the convenience of using concrete 
syntax for the rules.

Regard, - Conal


On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones 
> wrote:
*   Is it feasible for GHC to combine the constraints needed LHS and RHS to 
form an applicability condition?
I don’t think so.

Remember that a rewrite rule literally rewrites LHS to RHS.  It does not 
conjure up any new dictionaries out of thin air.  In your example, (D k b) is 
needed in the result of the rewrite.  Where can it come from?  Only from 
something matched on the left.

So GHC treats any dictionaries matched on the left as “givens” and tries to 
solve the ones matched on the left.  If it fails you get the sort of error you 
see.

One way to see this is to write out the rewrite rule you want, complete with 
all its dictionary arguments. Can you do that?

Simon

From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org]
 On Behalf Of Conal Elliott
Sent: 03 October 2017 01:03
To: Joachim Breitner >
Cc: glasgow-haskell-us...@haskell.org
Subject: Re: GHC rewrite rule type-checking failure

Thanks very much for the reply, Joachim.

Oops! I flubbed the example. I really `morph` to distribute over an application 
of `comp`. New code below (and attached). You're right that I wouldn't want to 
restrict the type of `morph`, since each `morph` *rule* imposes its own 
restrictions.

My questions:

*   Is it feasible for GHC to combine the constraints needed LHS and RHS to 
form an applicability condition?
*   Is there any way I can make the needed constraints explicit in my rewrite 
rules?
*   Are there any other 

RE: GHC rewrite rule type-checking failure

[Simon Peyton Jones via ghc-devs]

But synthesising from what?

And currently no: there is no type-class dictionary synthesis after the type 
checker.  Not impossible I suppose, but one more fragility: a rule does not 
fire because some synthesis thing didn’t happen.Maybe give an 
as-simple-as-poss example of what you have in mind, now you understand the 
situation better?   With all the type and dictionary abstractions written 
explicitly…

S

From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of 
Conal Elliott
Sent: 03 October 2017 15:56
To: Simon Peyton Jones 
Subject: Re: GHC rewrite rule type-checking failure

Thanks, Simon. Your explanation make sense to me. Do you think that the rewrite 
rule mechanism could be enhanced to try synthesizing the needed dictionaries 
after LHS matching and before RHS instantiation? I'm doing as much now in my 
compiling-to-categories plugin, but without the convenience of using concrete 
syntax for the rules.

Regard, - Conal


On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones 
> wrote:
*   Is it feasible for GHC to combine the constraints needed LHS and RHS to 
form an applicability condition?
I don’t think so.

Remember that a rewrite rule literally rewrites LHS to RHS.  It does not 
conjure up any new dictionaries out of thin air.  In your example, (D k b) is 
needed in the result of the rewrite.  Where can it come from?  Only from 
something matched on the left.

So GHC treats any dictionaries matched on the left as “givens” and tries to 
solve the ones matched on the left.  If it fails you get the sort of error you 
see.

One way to see this is to write out the rewrite rule you want, complete with 
all its dictionary arguments. Can you do that?

Simon

From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org]
 On Behalf Of Conal Elliott
Sent: 03 October 2017 01:03
To: Joachim Breitner >
Cc: glasgow-haskell-us...@haskell.org
Subject: Re: GHC rewrite rule type-checking failure

Thanks very much for the reply, Joachim.

Oops! I flubbed the example. I really `morph` to distribute over an application 
of `comp`. New code below (and attached). You're right that I wouldn't want to 
restrict the type of `morph`, since each `morph` *rule* imposes its own 
restrictions.

My questions:

*   Is it feasible for GHC to combine the constraints needed LHS and RHS to 
form an applicability condition?
*   Is there any way I can make the needed constraints explicit in my rewrite 
rules?
*   Are there any other work-arounds that would enable writing such 
RHS-constrained rules?

Regards, -- Conal

``` haskell
{-# OPTIONS_GHC -Wall #-}
-- Demonstrate a type checking failure with rewrite rules

module RuleFail where

class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f 
#-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
-- bound by the RULE "morph/(.)"
```


On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner 
> wrote:
Hi Conal,

The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):

*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)

but the LHS of the second rule side does not:

*RuleFail> :t morph addC
morph addC :: Num b => k (b, b) b



A work-around is to add the constraint to `morph`:

morph :: D k b => (a -> b) -> k a b
morph = error "morph: undefined"

but I fear that this work-around is not acceptable to you.

Joachim

Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
> -- Demonstrate a type checking failure with rewrite rules
>
> module RuleFail where
>
> class C k where comp' :: k b c -> k a b -> k a c
>
> instance C (->) where comp' = (.)
>
> -- Late-inlining version to enable rewriting.
> comp :: C k => k b c -> k a b -> k a c
> comp = comp'
> {-# INLINE [0] comp #-}
>
> morph :: (a -> b) -> k a b
> morph = error "morph: undefined"
>
> {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine



> class D k a where addC' :: k (a,a) a
>
> instance Num a => D (->) a where addC' = uncurry (+)
>
> -- Late-inlining version to enable rewriting.
> addC :: D k a => k (a,a) a
> addC = addC'
> {-# INLINE [0] addC #-}
>
> {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
>
> -- • Could not deduce (D k b) arising from a use of ‘addC’
> --   from the context: D (->) b
>
> -- Why does GHC infer the (C k) constraint for the first rule but not (D k b)
> 

RE: Invariants about UnivCo?

[Simon Peyton Jones via ghc-devs]

Some thoughts


  *   Read Note [Coercion holes] in TyCoRep.



  *   As you’ll see, generally we don’t create value-bindings for (unboxed) 
coercions of type t1 ~# t2.  (yes for boxed ones t1 ~ t2). Reasons in the 
Note.  Exception: for superclasses of Givens we do create(co :: a ~# b) = 
sc_sel1 d

where d is some dictionary with a superclass of type (a ~# b).

Side note: the use of “cobox” is wildly unhelpful.  These Ids are specifically 
unboxed!  I’m going to change it to just “co”.


  *   You appear to have bindings like[G]  cobox_a67J = CO Sym cobox_a654.  
That is suspicious.  Who is creating them?  It may not actually be wrong but 
it’s suspicious.  The time it’d be outright wrong is if you dropped the 
ev-binds on the floor.

Ha!  runTcSEqualites makes up an ev_binds_var, and solves the equalities – but 
it should be the case that no value bindings end up in the ev_binds_var.  
(reason: we are solving equalities in a type signature, so there is no place to 
put the evidence bindigns)   I suggest you add a DEBUG-only assertion to check 
this.


  *   Do -ddump-tc -fprint-typechecker-elaboration; that should show you the 
evidence binds.

Can I ask you a favour?  Separately from your branch, can you start a branch of 
small patches to GHC that include

  *   Extra assertions, such as that above
  *   Notes that explain things you wish you’d known earlier, with references 
to those Notes from the places you were studying when you that information 
would have been useful

Richard and I know too much! – your learning curve is very valuable and I don’t 
want to lose it.

Keeping this separate from your branch is useful : you can commit (via Phab) 
these updates right away, so they aren’t predicated on adding row types to GHC.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Nicolas Frisby
Sent: 19 September 2017 16:51
To: ghc-devs@haskell.org
Subject: Invariants about UnivCo?

[I summarize with some direct questions at the bottom of this email.]

I spent time last night trying to eliminate -dcore-lint errors from my record 
and variant library using the coxswain row types plugin. I made some progress, 
but I'm currently stuck, as discussed on this github Issue.

https://github.com/nfrisby/coxswain/issues/3#issuecomment-330577609

Here's the relevant bit:

The latest unresolved -dcore-lint error is an out-of-scope cobox co var. I'm 
certainly not creating it directly (there are no U(plugin:coxswain,... in the 
Core Lint warning), but I have to wonder if my somewhat loose use of UnivCo is 
violating some assumptions somewhere that's causing GHC to drop the co var 
binding or overlook this occurrence of it on a renaming/subst pass. I checked 
UnivCo for source comments looking for anything it should not be used for, but 
I didn't find an obvious explanation along those lines.

I haven't yet been able to effectively distill the test case.

I'm doing this all at -O0.

With `-ddump-tc-trace`, I can see the offending cobox (cobox_a67M) is present 
in an "implication evbinds" listing after a "solveImplication end }" delimiter, 
but that's the last obvious binding of it.

 [G] cobox_a67J = CO Sym cobox_a654,
 [G] cobox_a67M
   = cobox_a67J `cast` U(plugin:coxswain,...)

cobox_a654 is introduced by a GADT pattern match.

I'm also not seeing obvious occurrences of cobox_a67M, but I think the reason 
is that I'm seeing several (Sym cobox) with no uniques printed (even with 
`-dppr-debug`). Those are probably the cobox in question, but I can't confirm.

Questions:

1) Is there a robust way to ensure that covar's uniques are always printed? (Is 
the pprIface reuse  with a free cobox part of the issue here?)

2) Is my plugin asking for this kind of trouble by using UnivCo to cast coboxes?

3) If I spent the effort to create non-UnivCo coercions where possible, would 
that likely help? This is currently an "eventually" task, but I haven't seen an 
urgency for it yet. I could bump its priority if it might help. E.G. I'm using 
UnivCo to cast entire givens when all I'm doing is reducing a type family 
application somewhere "deep" within the given's predtype. I could, with 
considerable effort, instead wrap a single, localized UnivCo within a bunch of 
non-UnivCo "lifting" coercion constructors. Would that likely help?

3) Is there a usual suspect for this kind of situation where a cobox binding is 
seemingly dropped (by the typechecker) even though there's an occurrence of it?

Thank you for your time. -Nick
___
ghc-devs mailing list
ghc-devs@haskell.org

RE: The Curious Case of T6084 -or- Register Confusion with LLVM

[Simon Peyton Jones via ghc-devs]

|  One way to make this happen would be for C-- call nodes to carry information
|  about the calling convention of the target (e.g. how many arguments of each
|  type the function expects; in the same way identifiers in Core carry their
|  type).

That's be entirely possible for "known" calls, where the target is known, but 
not for "unknown" (i.e higher order) ones where the target of the call varies.

The "Making a fast curry" paper goes into this in some detail.  I think we 
already have different entry points for these two cases.  So maybe they could 
have different entry conventions...

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben Gamari
|  Sent: 20 September 2017 16:54
|  To: Moritz Angermann ; GHC developers 
|  Subject: Re: The Curious Case of T6084 -or- Register Confusion with LLVM
|  
|  Moritz Angermann  writes:
|  
|  [snip]
|  >
|  > I should not have the YMM*, and ZMM* registers as I don’t have any AVX
|  > nor AVX512; that looks like only a patch away.  However we try to
|  > optimize our register, such that we can pass up to six doubles or six
|  > floats or any combination of both if needed in registers, without
|  > having to allocate them on the stack, by assuming overlapping registers
|  (See Note [Overlapping global registers]).
|  >
|  > And as such a full function signature in LLVM would as opposed to one
|  > that’s based on the “live” registers as we have right now, would
|  > consist of 12 float/double registers, and LLVM only maps 6.  My
|  > current idea is to, pass only the explicit F1,D1,…,F3,D3 and try to
|  > disable the register overlapping for LLVM.  This would probably force
|  > more floating values to be stack allocated rather than passed via
|  > registers, but would likely guarantee that the registers match up.
|  > The other option I can think of is to define some viertual generic
|  > floating registers in the llvm code gen: V1,…,V6 and then perform
|  > something like
|  >
|  >   F1 <- V1 as float
|  >   D1 <- V1 as double
|  >
|  > in the body of the function, while trying to use the `live`
|  > information at the call site to decide which of F1 or D1 to pass as V1.
|  >
|  Arguably the fundamental problem here is the assumption that all STG entry-
|  points have the same machine-level calling convention. As you point out, our
|  calling conventions in fact change due to things like register overlap.
|  Ideally the LLVM we produce would reflect this.
|  
|  One way to make this happen would be for C-- call nodes to carry information
|  about the calling convention of the target (e.g. how many arguments of each
|  type the function expects; in the same way identifiers in Core carry their
|  type). Unfortunately a brief look at the code generator suggests that this
|  may require a fair amount of plumbing.
|  
|  It's important to note though that this overlap problem is something that
|  will need to be addressed eventually if we are are to have proper SIMD
|  support (due to overlap between XMM, YMM, and ZMM).
|  
|  Cheers,
|  
|  - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: The Curious Case of T6084 -or- Register Confusion with LLVM

[Simon Peyton Jones via ghc-devs]

Moritz

Talk to Kavon.  He was thinking about passing a struct instead of a huge list 
of registers, and only initialising the live fields of the struct.  I don't 
know whether he ultimately discarded the idea, but it sounded promising.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz
|  Angermann
|  Sent: 20 September 2017 10:45
|  To: GHC developers 
|  Subject: The Curious Case of T6084 -or- Register Confusion with LLVM
|  
|  Hi *,
|  
|  TLDR: The LLVM backend might confuse floating registers in GHC.
|  
|  # Demo (Ticket #14251)
|  
|  Let Demo.hs be the following short program (a minor modification from
|  T6084):
|  ```
|  {-# LANGUAGE MagicHash, BangPatterns #-} module Main where
|  
|  import GHC.Exts
|  
|  {-# NOINLINE f #-}
|  f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String f
|  g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!"
|  
|  {-# NOINLINE q #-}
|  q :: Int# -> Float# -> Double# -> Float# -> Double# -> String q i j k l m =
|  "Hello " ++ show (F# l) ++ " " ++ show (D# m)
|  
|  main = putStrLn (f $ q)
|  ```
|  
|  What happens if we compile them with the NCG and LLVM?
|  
|  $ ghc -fasm -fforce-recomp Demo.hs -O2 -o Demo-ncg && ./Demo-ncg Hello 6.0
|  6.9 World!
|  
|  $ ghc -fllvm -fforce-recomp Demo.hs -O2 -o Demo-llvm && ./Demo-llvm Hello
|  4.0 5.0 World!
|  
|  # Discussion
|  
|  What is happening here?  The LLVM backend passes the registers in arguments,
|  which are then mapped to registers via the GHC calling convention we added
|  to LLVM.
|  
|  As the LLVM backend takes off from Cmm, we produce function that always hold
|  the always live registers (on x86_64 these are: Base, Sp, Hp, R1, R2, R3,
|  R4, R5, R6, SpLim) and appends those registers that are live throughout the
|  function call: in the case of `q` this is one Float and one Double register.
|  Let’s assume these are
|  F3 and D4.  Thus the function signature we generate looks like:
|  
|  ghccc void @q(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float,
|  double)
|  
|  And expect the passed arguments to represent the following registers:
|  
|base, sp, hp, r1, r2, r3, r4, r5, r6, spLim, f3, d4
|  
|  as we found that f1 and d1 are not live.
|  
|  Yet, when we call `q` in the form of `g` in the body of `f`. We will pass it
|  14 arguments instead of 12.  To make this “typecheck” in LLVM, we
|  
|  @q' = bitcast @q to (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64,
|  float, double, float, double)
|  
|  and call @q’(base, sp, hp, r1, r2, r3, r4, r5, r6, spLim, f1, d2, f3, d4).
|  
|  at this point, we now assign f3 <- f1 and d4 <- d2; while silently ignoring
|  the passed arguments f3 and d4.
|  
|  (This is where my llvmng backend fell over, as it does not bitcast function
|  signatures but tries to unify them.)
|  
|  # Solution?
|  
|  Initially, Ben and I though we could simply always pass all registers as
|  arguments in LLVM and call it a day with the downside of create more verbose
|  but correct code.  As I found out, that comes with a few complications.  For
|  some reason, all active stg registers for my machine give me
|  
|Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim,
|F1, D1, F2, D2, F3, D3,
|XMM1,XMM2,XMM3,XMM4,XMM5,XMM6,
|YMM1,YMM2,YMM3,YMM4,YMM5,YMM6,
|ZMM1,ZMM2,ZMM3,ZMM4,ZMM5,ZMM6
|  
|  I should not have the YMM*, and ZMM* registers as I don’t have any AVX nor
|  AVX512; that looks like only a patch away.  However we try to optimize our
|  register, such that we can pass up to six doubles or six floats or any
|  combination of both if needed in registers, without having to allocate them
|  on the stack, by assuming overlapping registers (See Note [Overlapping
|  global registers]).
|  
|  And as such a full function signature in LLVM would as opposed to one that’s
|  based on the “live” registers as we have right now, would consist of 12
|  float/double registers, and LLVM only maps 6.  My current idea is to, pass
|  only the explicit F1,D1,…,F3,D3 and try to disable the register overlapping
|  for LLVM.  This would probably force more floating values to be stack
|  allocated rather than passed via registers, but would likely guarantee that
|  the registers match up.  The other option I can think of is to define some
|  viertual generic floating registers in the llvm code gen: V1,…,V6 and then
|  perform something like
|  
|F1 <- V1 as float
|D1 <- V1 as double
|  
|  in the body of the function, while trying to use the `live` information at
|  the call site to decide which of F1 or D1 to pass as V1.
|  
|  Ideas?
|  
|  Cheers,
|   Moritz
|  
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  

RE: Overapproximation of loopbreakers due to unfoldings

[Simon Peyton Jones via ghc-devs]

INLINE means "Inline what I wrote".   So in your example we'd have

===>

bindWith [INLINE = ]
 = bindWith_abc |> co
bindWith_abc = 

If you see a call to bindWith, we will /not/ inline bindWith_abc |> co!  We'll 
inline .  That's what the programmer asked for.

That's why self-recursive INLINE things are loop breakers.

Does that help?

Now, it's true that /in the rhs of bindWith_abc/ it might be better to inline 
(bindWith_abc |> co) in place of bindWith, rather than inlining the .  But currently GHC can carry only one unfolding for an 
Id.  We could review that, but it'd make things more complicated.

I have not yet found time to dig into the mysteries of #14211.  Thank you for 
investigating so diligently.

Simon




| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew
| Pickering
| Sent: 15 September 2017 16:46
| To: GHC developers 
| Subject: Overapproximation of loopbreakers due to unfoldings
| 
| I have been puzzling over the example presented by Harendra in #14211 for
| the last two days.
| 
| Ultimately it led me to discover that if a self-recursive definition is
| marked with an INLINE pragma then it will always be marked as a
| loopbreaker.
| 
| This is undesirable in this case as the simplifier ends up with in the
| first pass..
| 
| bindWith = ... bindWith ...
| =>
| bindWith = bindWith_abc |> co
| bindWith_abc = ... bindWith ...
| 
| So we can then inline `bindWith` into the RHS of `bindWith_abc` and
| create a single self-recursive function rather than a mutually recursive
| block. Marking `bindWith` as `INLINE` means that both `bindWith` and
| `bindWith_abc` are marked as loopbreakers.
| 
| Mutual recursive blocks are bad as they completely stop the static
| argument transformation from working.
| 
| My question is, why is it necessary to mark "bindWith" as a loopbreaker
| in the current module? Are there any tickets or notes which discuss this
| problem?
| 
| Matt
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=02%7C01%7Csimonpj%40microsoft.com%7C2a71eb929ce24b4dcefc08d4fc5
| 0f2db%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636410871981371365
| ta=RmtbOXJcB9bzKa%2FV95pICCIyTbTfzw1%2BooD52dI%2FzE0%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: A type checker plugin for row types

[Simon Peyton Jones via ghc-devs]

Nick

Good work!

You ask some questions about the constraint solver – I hope that the answer 
from others have helped. If not, do re-ask.

My main comment is: what does Core look like?  I think your answer is “No 
change to Core, but there are lots of unsafe coerces littered around”.   But 
even then I’m not sure.  Even

f :: Lacks r “f” => V (Row (r .& (“f” .= Int))) -> V (Row (r .& (“f” .= Int)))
f n x = ???

Somehow in the ??? I have to update field n of a tuple x.  How do I do that?

And I’m also very uncomfortable having Core littered with unsafeCoerces.   I 
like Core being statically typed.  What is the simplest primitive(s) we could 
add to Core to make it possible to express this stuff type-safely?

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Nicolas Frisby
Sent: 10 September 2017 23:25
To: ghc-devs@haskell.org
Cc: Andres Löh ; Adam Gundry ; 
Richard Eisenberg 
Subject: A type checker plugin for row types

Hi all. I've been spending my free time for the last couple months on a type 
checker plugin for row types. The free time waxes and wanes; sending an email 
like this one was my primary goal for the past couple weeks.

At the very least, I hoped this project would let me finally get some hands on 
experience with OutsideIn. And I definitely have. But I've also made more 
progress than I anticipated, and I think the plugin is starting to have legs!

I haven't uploaded the code yet to github -- it's not quite ready to share. But 
I did do a write up on the dev wiki.

  https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain

I would really appreciate and questions, comments, and --- boy, oh boy --- 
answers.

I hope to upload within a week or so, and I'll update that wiki page and reply 
to this email when I do.

Thanks very much. -Nick

P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically 
interested in this (e.g. plugins, row types, etc). Please feel free to forward 
to others that come to mind; I know some inboxes abjectly can't afford default 
list traffic.

P.P.S. -- One hold up for the upload is: which license? I intend to release 
under BSD3, mainly to match GHC since one ideal scenario would involve being 
packaged with/integrated into GHC. But my brief recent research suggests that 
the Apache license might be more conducive to eventual widespread adoption. If 
you'd be willing to advise or even just refer me to other write ups, please 
feel free to email me directly or to start a separate thread on a more 
appropriate distribution list (CC'ing me, please). Thanks again.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Perf improvement

[Simon Peyton Jones via ghc-devs]

Bump it down, maybe... it got /better/!

|  -Original Message-
|  From: Ben Gamari [mailto:b...@smart-cactus.org]
|  Sent: 14 September 2017 16:54
|  To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org
|  Subject: Re: Perf improvement
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
|  
|  > I'm seeing this in validate
|  >
|  > bytes allocated value is too low:
|  >
|  > (If this is because you have improved GHC, please
|  >
|  > update the test so that GHC doesn't regress again)
|  >
|  > ExpectedT5837(normal) bytes allocated: 56782344 +/-7%
|  >
|  > Lower bound T5837(normal) bytes allocated: 52807579
|  >
|  > Upper bound T5837(normal) bytes allocated: 60757109
|  >
|  > Actual  T5837(normal) bytes allocated: 52424864
|  >
|  > Deviation   T5837(normal) bytes allocated: -7.7 %
|  >
|  > *** unexpected stat test failure for T5837(normal) Does anyone else?
|  
|  Unfortunately I'm not seeing this locally. It sounds like yet another
|  environmentally-sensitive issue. Perhaps we should just bump it.
|  
|  Cheers,
|  
|  - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: ./validate --slow results

[Simon Peyton Jones via ghc-devs]

Wow... 97 unexpected failures is bad.

Ben/David/someone else: might you investigate/characterise them?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Bartosz
|  Nitka
|  Sent: 14 September 2017 13:57
|  To: ghc-devs Devs 
|  Subject: ./validate --slow results
|  
|  Hi all,
|  
|  I happened to run ./validate --slow on my linux machine and I thought it
|  would be useful to share the results.
|  
|  Results:
|  
|  Unexpected results from:
|  TEST="EtaExpandLevPoly PatternSplice StrictPats T10508_api T11627b
|  T12809 T12870a T12870b T12870c T12870d T12870e T12870f T12870g T12870h
|  T12903 T12962 T13366 T13543 T13688 T13780c T13822 T13949 T14137 T2552
|  T2783 T3001-2 T4114c T4114d T4188 T4334 T5129 T5363 T5559 T5611 T680
|  T7411 T7837 T7944 T8025 T8089 T8542 TH_spliceE5_prof_ext UnsafeReenter
|  compact_gc compact_share dsrun014 dynamic-paper haddock.Cabal hpc_fork prof-
|  doc-fib prof-doc-last profinline001 read029 return_mem_to_os
|  rn041 scc001 scc002 scc003 scc005 space_leak_001 tc165 tryReadMVar2"
|  
|  SUMMARY for test run started at Thu Sep 14 04:57:20 2017 PDT
|   0:12:27 spent to go through
|  6091 total tests, which gave rise to
| 24105 test cases, of which
|  4531 were skipped
|  
|   143 had missing libraries
| 19120 expected passes
|   203 expected failures
|  
| 0 caused framework failures
| 0 caused framework warnings
| 6 unexpected passes
|97 unexpected failures
| 5 unexpected stat failures
|  
|  Unexpected passes:
| /tmp/ghctest-e17wqi8b/test
|  spaces/./dependent/should_compile/dynamic-paper.run  dynamic-paper
|  [unexpected] (optasm)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./indexed-types/should_compile/T7837.run  T7837
|  [unexpected] (profasm)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./parser/should_compile/read029.run   read029
|  [unexpected] (optasm)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./rename/should_compile/rn041.run rn041
|  [unexpected] (optasm)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./simplCore/should_fail/T7411.run T7411
|  [unexpected] (hpc)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./typecheck/should_compile/tc165.run  tc165
|  [unexpected] (optasm)
|  
|  Unexpected failures:
| /tmp/ghctest-e17wqi8b/test   spaces/./codeGen/should_run/T5129.run
|   T5129 [bad exit code] (hpc)
| /tmp/ghctest-e17wqi8b/test   spaces/./codeGen/should_run/T5129.run
|   T5129 [bad exit code] (optasm)
| /tmp/ghctest-e17wqi8b/test   spaces/./codeGen/should_run/T5129.run
|   T5129 [bad exit code] (threaded2)
| /tmp/ghctest-e17wqi8b/test   spaces/./codeGen/should_run/T5129.run
|   T5129 [bad exit code] (dyn)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./concurrent/should_run/T5611.runT5611 [bad
|  stdout] (ghci)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./concurrent/should_run/tryReadMVar2.run
|  tryReadMVar2 [bad heap profile] (profasm)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./deSugar/should_run/dsrun014.rundsrun014
|  [bad stderr] (hpc)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./deSugar/should_run/dsrun014.rundsrun014
|  [bad stderr] (optasm)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./deSugar/should_run/dsrun014.rundsrun014
|  [bad stderr] (threaded2)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./deSugar/should_run/dsrun014.rundsrun014
|  [bad stderr] (dyn)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./dependent/should_fail/T13780c.run  T13780c
|  [stderr mismatch] (normal)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./dependent/should_compile/dynamic-paper.run
|  dynamic-paper [exit code non-0] (profasm)
| /tmp/ghctest-e17wqi8b/test   spaces/./driver/T4114d.run
|   T4114d [bad exit code] (ghci)
| /tmp/ghctest-e17wqi8b/test   spaces/./driver/T4114c.run
|   T4114c [bad exit code] (ghci)
| /tmp/ghctest-e17wqi8b/test   spaces/./ghc-api/T10508_api.run
|   T10508_api [bad exit code] (profasm)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./numeric/should_compile/T8542.run   T8542
|  [stderr mismatch] (hpc)
| /tmp/ghctest-e17wqi8b/test   spaces/./ghc-api/T10508_api.run
|   T10508_api [bad exit code] (profthreaded)
| /tmp/ghctest-e17wqi8b/test
|  spaces/./partial-sigs/should_compile/PatternSplice.run
|  PatternSplice [exit code non-0] (profasm)
| /tmp/ghctest-e17wqi8b/test   spaces/./patsyn/should_run/T13688.run
|   T13688 [exit code non-0] (profasm)
| /tmp/ghctest-e17wqi8b/test   spaces/./patsyn/should_run/T13688.run
|   T13688 [exit code non-0] (profthreaded)
| /tmp/ghctest-e17wqi8b/test
|  

Perf improvement

[Simon Peyton Jones via ghc-devs]

I'm seeing this in validate

bytes allocated value is too low:

(If this is because you have improved GHC, please

update the test so that GHC doesn't regress again)

ExpectedT5837(normal) bytes allocated: 56782344 +/-7%

Lower bound T5837(normal) bytes allocated: 52807579

Upper bound T5837(normal) bytes allocated: 60757109

Actual  T5837(normal) bytes allocated: 52424864

Deviation   T5837(normal) bytes allocated: -7.7 %

*** unexpected stat test failure for T5837(normal)
Does anyone else?
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Performance degradation when factoring out common code

[Simon Peyton Jones via ghc-devs]

I know that this is not an easy request, but can either of you produce a small 
example that demonstrates your problem?   If so, please open a ticket.

I don’t like hearing about people having to use trial and error  with INLINE or 
SPECIALISE pragmas.  But I can’t even begin to solve the problem unless I can 
reproduce it.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Harendra Kumar
Sent: 08 September 2017 13:50
To: Mikolaj Konarski 
Cc: ghc-devs@haskell.org
Subject: Re: Performance degradation when factoring out common code

I should also point out that I saw performance improvements by manually 
factoring out and propagating some common expressions to outer loops in 
performance sensitive paths. Now I have made this a habit to do this manually. 
Not sure if something like this has also been fixed with that ticket or some 
other ticket.

-harendra

On 8 September 2017 at 17:34, Harendra Kumar 
> wrote:
Thanks Mikolaj! I have seen some surprising behavior quite a few times recently 
and I was wondering whether GHC should do better. In one case I had to use 
SPECIALIZE very aggressively, in another version of the same code it worked 
well without that. I have been doing a lot of trial and error with the 
INLINE/NOINLINE pragmas to figure out what the right combination is. Sometimes 
it just feels like black magic, because I cannot find a rationale to explain 
the behavior. I am not sure if there are any more such problems lurking in, 
perhaps this is an area where some improvement looks possible.

-harendra


On 8 September 2017 at 17:10, Mikolaj Konarski 
> wrote:
Hello,

I've had a similar problem that's been fixed in 8.2.1:

https://ghc.haskell.org/trac/ghc/ticket/12603

You can also use some extreme global flags, such as

ghc-options: -fexpose-all-unfoldings -fspecialise-aggressively

to get most the GHC subtlety and shyness out of the way
when experimenting.

Good luck
Mikolaj



On Fri, Sep 8, 2017 at 11:21 AM, Harendra Kumar
> wrote:
> Hi,
>
> I have this code snippet for the bind implementation of a Monad:
>
> AsyncT m >>= f = AsyncT $ \_ stp yld ->
> let run x = (runAsyncT x) Nothing stp yld
> yield a _ Nothing  = run $ f a
> yield a _ (Just r) = run $ f a <> (r >>= f)
> in m Nothing stp yield
>
> I want to have multiple versions of this implementation parameterized by a
> function, like this:
>
> bindWith k (AsyncT m) f = AsyncT $ \_ stp yld ->
> let run x = (runAsyncT x) Nothing stp yld
> yield a _ Nothing  = run $ f a
> yield a _ (Just r) = run $ f a `k` (bindWith k r f)
> in m Nothing stp yield
>
> And then the bind function becomes:
>
> (>>=) = bindWith (<>)
>
> But this leads to a performance degradation of more than 10%. inlining does
> not help, I tried INLINE pragma as well as the "inline" GHC builtin. I
> thought this should be a more or less straightforward replacement making the
> second version equivalent to the first one. But apparently there is
> something going on here that makes it perform worse.
>
> I did not look at the core, stg or asm yet. Hoping someone can quickly
> comment on it. Any ideas why is it so? Can this be worked around somehow?
>
> Thanks,
> Harendra
>
> ___
> 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: A newcomer: how to start

[Simon Peyton Jones via ghc-devs]

Yes, welcome!

Do join ghc-devs and watch the fun.

There is a learning curve, but as Ara says, everyone is friendly.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ara Adkins
Sent: 05 September 2017 13:47
To: Sergey Bykov 
Cc: ghc-devs@haskell.org
Subject: Re: A newcomer: how to start

Hey Sergey,

I’d honestly head straight for the GHC newcomers guide [0]! Once you’re 
familiar with all of that just head for Trac and look for the low hanging fruit 
tasks! Most importantly, don’t forget to ask questions! Nobody here bites!

Best,
_ara

[0] https://ghc.haskell.org/trac/ghc/wiki/Newcomers

On 5 Sep 2017, at 13:42, Sergey Bykov 
> wrote:
Hi,

my name is Sergey and I'm recently joined to this mailing list. I would like to 
help GHC's community and start contributing to the GHC project. Could someone 
recommend a few tasks, which seems to be suitable for a beginner?

About myself:

I'm pretty experienced Research Scientist/Software Developer in such areas like 
discrete optimization and machine learning.


Thanks in advance!

___
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: [broken HEAD] In which the strict state monad fails at basic arithmetic

[Simon Peyton Jones via ghc-devs]

Wow -- Fast work!   Do add a test case

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben
| Gamari
| Sent: 01 September 2017 14:53
| To: Moritz Angermann ; GHC developers 
| Subject: Re: [broken HEAD] In which the strict state monad fails at basic
| arithmetic
| 
| Moritz Angermann  writes:
| 
| > Hi *,
| >
| > while working on some related code.  I came across a rather peculiar
| > behavior with GHC built from the current master branch at b2c2e3e8.
| >
| The issue was a bug indeed introduced by the commit you cite below. The
| problem was a mistake in a change in constant folding which,
| frighteningly, the testsuite did not catch. See D3904 for a fix and a
| test is forthcoming.
| 
| Cheers,
| 
| - Ben

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

RE: [commit: ghc] master: Adjust test suite stats (a055f24)

[Simon Peyton Jones via ghc-devs]

Ha!  They didn’t regress for me.  I validated before committing.  How strange.

I agree about keeping it green

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David Feuer
Sent: 28 August 2017 22:13
To: ghc-devs <ghc-devs@haskell.org>
Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24)

These were regressions from your simplifier refactoring. Yes, we should 
investigate. I'll open a ticket this evening, unless someone else gets to it 
first. But we surely don't want to keep CI red on every commit until then.



David Feuer
Well-Typed, LLP

 Original message 
From: Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>>
Date: 8/28/17 4:57 PM (GMT-05:00)
To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24)

David, are you sure we want to accept a more than 5% increase in compile time 
without investigation?   What commit caused these increases?  Maybe they are 
readily squashed? Generally we are trying to improve compiler perf not accept 
it getting worse!

Simon

| -Original Message-
| From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of
| g...@git.haskell.org<mailto:g...@git.haskell.org>
| Sent: 28 August 2017 19:34
| To: ghc-comm...@haskell.org<mailto:ghc-comm...@haskell.org>
| Subject: [commit: ghc] master: Adjust test suite stats (a055f24)
|
| 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%2Fa055f240aeda538c656a59e810870e6a2ccc2db
| 7%2Fghc=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4
| ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722&
| sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D=0
|
| >---
|
| commit a055f240aeda538c656a59e810870e6a2ccc2db7
| Author: David Feuer <david.fe...@gmail.com<mailto:david.fe...@gmail.com>>
| Date:   Mon Aug 28 14:35:19 2017 -0400
|
| Adjust test suite stats
|
| T1969 and T12150 were failing (stat too high)
|
|
| >---
|
| a055f240aeda538c656a59e810870e6a2ccc2db7
|  testsuite/tests/perf/compiler/all.T | 6 --
|  1 file changed, 4 insertions(+), 2 deletions(-)
|
| diff --git a/testsuite/tests/perf/compiler/all.T
| b/testsuite/tests/perf/compiler/all.T
| index 1da2883..cf49981 100644
| --- a/testsuite/tests/perf/compiler/all.T
| +++ b/testsuite/tests/perf/compiler/all.T
| @@ -72,7 +72,7 @@ test('T1969',
|   # 2017-03-24 9261052 (x86/Linux, 64-bit machine)
|   # 2017-04-06 9418680 (x86/Linux, 64-bit machine)
|
| -   (wordsize(64), 16679176, 15)]),
| +   (wordsize(64), 19199872, 15)]),
|   # 2014-09-10 10463640, 10  # post-AMP-update (somewhat
| stabelish)
| # looks like the peak is around ~10M, but we're
| # unlikely to GC exactly on the peak.
| @@ -87,6 +87,7 @@ test('T1969',
|   # 2017-02-01 19924328 (amd64/Linux) Join points (#12988)
|   # 2017-02-14 16393848 Early inline patch
|   # 2017-03-31 16679176 Fix memory leak in simplifier
| + # 2017-08-25 19199872 Refactor the Mighty Simplifier
|
|compiler_stats_num_field('bytes allocated',
|[(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7
| +,8 @@ test('T12150',
|   [ only_ways(['optasm']),
| compiler_stats_num_field('bytes allocated',
|[(wordsize(64), 70773000, 5)
| -  # initial:  70773000
| +  # initial:70773000
| +  # 2017-08-25: 74358208  Refactor the Mighty Simplifier
|]),
|   ],
|  compile,
|
| ___
| ghc-commits mailing list
| ghc-comm...@haskell.org<mailto: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%7C382263fbefc643e95a6308d4
| ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722&
| sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org<mailto: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: [commit: ghc] master: Adjust test suite stats (a055f24)

[Simon Peyton Jones via ghc-devs]

David, are you sure we want to accept a more than 5% increase in compile time 
without investigation?   What commit caused these increases?  Maybe they are 
readily squashed? Generally we are trying to improve compiler perf not accept 
it getting worse!

Simon

| -Original Message-
| From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of
| g...@git.haskell.org
| Sent: 28 August 2017 19:34
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Adjust test suite stats (a055f24)
| 
| 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%2Fa055f240aeda538c656a59e810870e6a2ccc2db
| 7%2Fghc=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4
| ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722&
| sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D=0
| 
| >---
| 
| commit a055f240aeda538c656a59e810870e6a2ccc2db7
| Author: David Feuer 
| Date:   Mon Aug 28 14:35:19 2017 -0400
| 
| Adjust test suite stats
| 
| T1969 and T12150 were failing (stat too high)
| 
| 
| >---
| 
| a055f240aeda538c656a59e810870e6a2ccc2db7
|  testsuite/tests/perf/compiler/all.T | 6 --
|  1 file changed, 4 insertions(+), 2 deletions(-)
| 
| diff --git a/testsuite/tests/perf/compiler/all.T
| b/testsuite/tests/perf/compiler/all.T
| index 1da2883..cf49981 100644
| --- a/testsuite/tests/perf/compiler/all.T
| +++ b/testsuite/tests/perf/compiler/all.T
| @@ -72,7 +72,7 @@ test('T1969',
|   # 2017-03-24 9261052 (x86/Linux, 64-bit machine)
|   # 2017-04-06 9418680 (x86/Linux, 64-bit machine)
| 
| -   (wordsize(64), 16679176, 15)]),
| +   (wordsize(64), 19199872, 15)]),
|   # 2014-09-10 10463640, 10  # post-AMP-update (somewhat
| stabelish)
| # looks like the peak is around ~10M, but we're
| # unlikely to GC exactly on the peak.
| @@ -87,6 +87,7 @@ test('T1969',
|   # 2017-02-01 19924328 (amd64/Linux) Join points (#12988)
|   # 2017-02-14 16393848 Early inline patch
|   # 2017-03-31 16679176 Fix memory leak in simplifier
| + # 2017-08-25 19199872 Refactor the Mighty Simplifier
| 
|compiler_stats_num_field('bytes allocated',
|[(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7
| +,8 @@ test('T12150',
|   [ only_ways(['optasm']),
| compiler_stats_num_field('bytes allocated',
|[(wordsize(64), 70773000, 5)
| -  # initial:  70773000
| +  # initial:70773000
| +  # 2017-08-25: 74358208  Refactor the Mighty Simplifier
|]),
|   ],
|  compile,
| 
| ___
| 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%7C382263fbefc643e95a6308d4
| ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722&
| sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Alex install failure

[Simon Peyton Jones via ghc-devs]

sudo rpcinfo -p
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  56434  status
1000241   tcp  34797  status
simonpj@cam-05-unx:~/code/HEAD$

|  -Original Message-
|  From: Ben Gamari [mailto:b...@smart-cactus.org]
|  Sent: 28 August 2017 13:36
|  To: Simon Peyton Jones <simo...@microsoft.com>; Herbert Valerio Riedel
|  <hvrie...@gmail.com>; ghc-devs <ghc-devs@haskell.org>
|  Subject: RE: Alex install failure
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
|  
|  > |  note that you mistyped "lockd" (aka "lock daemon") as "locd"
|  >
|  > Oh, sorry about mistyping
|  >
|  > simonpj@cam-05-unx:~/tmp$ ps -Af | grep lockd
|  > root   140 2  0  2016 ?00:00:00 [kblockd]
|  > simonpj   7882  1184  0 13:22 pts/700:00:00 grep lockd
|  >
|  Interesting; no lock daemon.
|  
|  > |  also, the output of "rpcinfo -p" would be interesting to know
|  >
|  > simonpj@cam-05-unx:~/tmp$ rpcinfo -p
|  > Command 'rpcinfo' is available in '/usr/sbin/rpcinfo'
|  > The command could not be located because '/usr/sbin' is not included in
|  the PATH environment variable.
|  > This is most likely caused by the lack of administrative privileges
|  associated with your user account.
|  > rpcinfo: command not found
|  >
|  Silly me; are you able to run `sudo rpcinfo -p`?
|  
|  Cheers,
|  
|  - Ben

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

RE: Alex install failure

[Simon Peyton Jones via ghc-devs]

|  note that you mistyped "lockd" (aka "lock daemon") as "locd"

Oh, sorry about mistyping

simonpj@cam-05-unx:~/tmp$ ps -Af | grep lockd
root   140 2  0  2016 ?00:00:00 [kblockd]
simonpj   7882  1184  0 13:22 pts/700:00:00 grep lockd

|  also, the output of "rpcinfo -p" would be interesting to know

simonpj@cam-05-unx:~/tmp$ rpcinfo -p
Command 'rpcinfo' is available in '/usr/sbin/rpcinfo'
The command could not be located because '/usr/sbin' is not included in the 
PATH environment variable.
This is most likely caused by the lack of administrative privileges associated 
with your user account.
rpcinfo: command not found


|  -Original Message-
|  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
|  Sent: 28 August 2017 12:51
|  To: Simon Peyton Jones <simo...@microsoft.com>
|  Subject: Re: Alex install failure
|  
|  Simon,
|  
|  note that you mistyped "lockd" (aka "lock daemon") as "locd"
|  
|  also, the output of "rpcinfo -p" would be interesting to know
|  
|  On Mon, Aug 28, 2017 at 1:47 PM, Simon Peyton Jones via ghc-devs  wrote:
|  > |  Hmm, alright then. What do the following say,
|  > |
|  > |   * ps -Af | grep lockd
|  > |   * ps -Af | grep portmap
|  > |   * ps -Af | grep rpcbind
|  > |   * mount | grep nfs
|  > |
|  >
|  > simonpj@cam-05-unx:~/tmp$ ps -Af | grep locd
|  > simonpj  20138  1184  0 12:46 pts/700:00:00 grep locd
|  >
|  > simonpj@cam-05-unx:~/tmp$ ps -Af | grep portmap
|  > simonpj  22601  1184  0 12:46 pts/700:00:00 grep portmap
|  >
|  > simonpj@cam-05-unx:~/tmp$ ps -Af | grep rpcbind
|  > root  1472 1  0  2016 ?00:00:13 rpcbind -w
|  > simonpj  26634  1184  0 12:46 pts/700:00:00 grep rpcbind
|  >
|  > simonpj@cam-05-unx:~/tmp$ mount | grep nfs camresunxa02:/home on /home
|  > type nfs (rw,intr,vers=4,addr=10.190.50.19,clientaddr=10.190.108.81)
|  >
|  > |  -Original Message-
|  > |  From: Ben Gamari [mailto:b...@well-typed.com]
|  > |  Sent: 25 August 2017 17:46
|  > |  To: Simon Peyton Jones <simo...@microsoft.com>
|  > |  Cc: ghc-devs <ghc-devs@haskell.org>
|  > |  Subject: RE: Alex install failure
|  > |
|  > |  Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
|  > |
|  > |  > |  I have implemented this in wip/ghc-pkg-locking. Do you think
|  > | you  > | could give  this branch a try? If it still fails then we'll
|  > | have to  > | try to debug things  in-situ.
|  > |  >
|  > |  > Alas, no go.
|  > |  >
|  > |  Hmm, alright then. What do the following say,
|  > |
|  > |   * ps -Af | grep lockd
|  > |   * ps -Af | grep portmap
|  > |   * ps -Af | grep rpcbind
|  > |   * mount | grep nfs
|  > |
|  > |  Cheers,
|  > |
|  > |  - Ben
|  >
|  > ___
|  > ghc-devs mailing list
|  > ghc-devs@haskell.org
|  > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs=02%7C01%7Csi
|  > monpj%40microsoft.com%7C33b163bdb97f4f59d80f08d4ee0b07ea%7C72f988bf86f
|  > 141af91ab2d7cd011db47%7C1%7C0%7C636395178517098924=EOVdQbvvTDGP9
|  > 2o8AHcVEcapHMicnVptxMCpwRPrsvE%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Alex install failure

[Simon Peyton Jones via ghc-devs]

|  I have implemented this in wip/ghc-pkg-locking. Do you think you could give
|  this branch a try? If it still fails then we'll have to try to debug things
|  in-situ.

Alas, no go.

* I'm on wip/ghc-pkg-locking
* I checked that the lock file was removed

then I tried this:

simonpj@cam-05-unx:~/code/HEAD-2$ cabal install lens 
--with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2
Resolving dependencies...
Configuring base-orphans-0.6...
Configuring cabal-doctest-1.0.2...
Configuring call-stack-0.1.0...
Configuring fail-4.9.0.0...
Configuring hashable-1.2.6.1...
Configuring parallel-3.2.1.1...
Configuring prelude-extras-0.4.0.3...
Configuring primitive-0.6.2.0...
Configuring reflection-2.1.2...
Configuring semigroups-0.18.3...
Configuring stm-2.4.4.1...
Configuring th-abstraction-0.2.5.0...
Configuring transformers-compat-0.5.1.4...
Configuring void-0.7.2...
Building base-orphans-0.6...
Building cabal-doctest-1.0.2...
Building fail-4.9.0.0...
Building call-stack-0.1.0...
Building parallel-3.2.1.1...
Building hashable-1.2.6.1...
Building primitive-0.6.2.0...
Building prelude-extras-0.4.0.3...
Building reflection-2.1.2...
Building semigroups-0.18.3...
Building stm-2.4.4.1...
Building void-0.7.2...
Building th-abstraction-0.2.5.0...
Building transformers-compat-0.5.1.4...
Installed fail-4.9.0.0
Failed to install base-orphans-0.6
Build log ( /home/simonpj/.cabal/logs/base-orphans-0.6.log ):
cabal: Entering directory '/tmp/cabal-tmp-28239/base-orphans-0.6'
Configuring base-orphans-0.6...
Building base-orphans-0.6...
Preprocessing library base-orphans-0.6...
[1 of 2] Compiling Data.Orphans ( src/Data/Orphans.hs, 
dist/build/Data/Orphans.o )
[2 of 2] Compiling Data.Orphans.Prelude ( src/Data/Orphans/Prelude.hs, 
dist/build/Data/Orphans/Prelude.o )
Creating package registration file:
/tmp/pkgConf-base-orphans-010599613932089018456.6
Installing library in
/home/simonpj/.cabal/lib/x86_64-linux-ghc-8.3.20170825/base-orphans-0.6-9iPDLrUqQ5yHb9fb9OUZ9L
Registering base-orphans-0.6...
cabal: '/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-pkg' exited with an
error:
ghc-pkg: Couldn't open database
/home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d for modification:
{handle:
/home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d/package.cache.lock}:
hLock: invalid argument (Bad file descriptor)
cabal: Leaving directory '/tmp/cabal-tmp-28239/base-orphans-0.6'
Failed to install void-0.7.2
Build log ( /home/simonpj/.cabal/logs/void-0.7.2.log ):
cabal: Entering directory '/tmp/cabal-tmp-28252/void-0.7.2'
Configuring void-0.7.2...
Building void-0.7.2...
Preprocessing library void-0.7.2...
[1 of 1] Compiling Data.Void.Unsafe ( src/Data/Void/Unsafe.hs, 
dist/build/Data/Void/Unsafe.o )
Creating package registration file: /tmp/pkgConf-void-0.76281750111656478042.2
Installing library in
/home/simonpj/.cabal/lib/x86_64-linux-ghc-8.3.20170825/void-0.7.2-KNNEd7XG9bDRysTndgnf2
Registering void-0.7.2...
cabal: '/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-pkg' exited with an
error:
ghc-pkg: Couldn't open database
/home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d for modification:
{handle:
/home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d/package.cache.lock}:
hLock: invalid argument (Bad file descriptor)
cabal: Leaving directory '/tmp/cabal-tmp-28252/void-0.7.2'
Failed to install semigroups-0.18.3
Build log ( /home/simonpj/.cabal/logs/semigroups-0.18.3.log ):
cabal: Entering directory '/tmp/cabal-tmp-28248/semigroups-0.18.3'
Configuring semigroups-0.18.3...
Building semigroups-0.18.3...
Preprocessing library semigroups-0.18.3...
[1 of 1] Compiling Data.Semigroup.Generic ( src/Data/Semigroup/Generic.hs, 
dist/build/Data/Semigroup/Generic.o )
Creating package registration file:
/tmp/pkgConf-semigroups-0.188594844211914544919.3
Installing library in
/home/simonpj/.cabal/lib/x86_64-linux-ghc-8.3.20170825/semigroups-0.18.3-9GRyDnRvoqO5HfdYR3Qz4o
Registering semigroups-0.18.3...
cabal: '/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-pkg' exited with an
error:
ghc-pkg: Couldn't open database
/home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d for modification:
{handle:
/home/simonpj/.ghc/x86_64-linux-8.3.20170825/package.conf.d/package.cache.lock}:
hLock: invalid argument (Bad file descriptor)
cabal: Leaving directory '/tmp/cabal-tmp-28248/semigroups-0.18.3'
  C-c C-c
simonpj@cam-05-unx:~/code/HEAD-2$

|  -Original Message-
|  From: Ben Gamari [mailto:b...@well-typed.com]
|  Sent: 24 August 2017 13:53
|  To: Simon Peyton Jones 
|  Cc: ghc-devs 
|  Subject: RE: Alex install failure
|  
|  Simon Peyton Jones  writes:
|  
|  > | Hmm. Here's a shot in the dark: is home home directory mounted via
|  > | NFS by any chance?
|  >
|  > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think.
|  > So what?
|  
|  Hi Simon,
|  
|  Sorry for the rather belated reply; I was knocked off my feet for a few days
|  by a 

RE: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

[Simon Peyton Jones via ghc-devs]

Hmm I see. I still prefer the concrete form (no intermediate layer).   Many 
constructors use record fields, so you can just omit the ones that aren’t valid.

Simon


From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 24 August 2017 15:39
To: Simon Peyton Jones 
Cc: Alan & Kim Zimmerman ; ghc-devs@haskell.org
Subject: Re: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

(1)-(3) appears to be three different approaches, but I don’t think that’s what 
you intend.  I think there are only two: add the indirection layer or not?

(1)-(3) are just steps when we do choose to add the indirection layer: add the 
layer, and do the changes when desired.
If we choose to not to add the indirection layer, nothing needs to be changed 
and the internals of the encoding (`PostTc`, place holders, etc) remain visible 
in the code.

Can you give an example function or two, and what it would look like under the 
different approaches.

For example, the function clause

> rnExpr (HsMultiIf _ty alts)
>  = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts
>   ; return (HsMultiIf placeHolderType alts', fvs) }

becomes

> rnExpr (PsMultiIf alts)
>  = do { (alts', fvs) <- mapFvRn (rnGRHS IfAlt rnLExpr) alts
>   ; return (RnMultiIf alts', fvs) }

I hope it clarifies what I mean a bit.

There is always a choice between how distinct we want the phases to be.
The more distinct they are, the higher static guarantees. The code also gets 
more clear in a way, e.g. `RnMultiIf` is talking about a renamed expression, 
`PsMultiIf` about a parsed expression, while `HsMultiIf` is talking about an 
expression of any phase.
At the same, distinctness means more work for the programmer.
Also, such distinction sometimes implies a pedagogic burdon, as readers should 
now learn about more than one AST. However, this burden is very low here thanks 
to the prefixing convention: `PsMultiIf` and `RnMultiIf` are easily understood 
to represent the same thing in different phases.
Finally, such distinctions often lead to code duplication. But in our case, 
Trees that Grow machinery saves us from such duplication, e.g., we have the 
same base ASTs and we can write generic programmers over the bases ASTs anytime 
we want (point/step (3) above).

Thanks,
  Shayan

On Thu, Aug 24, 2017 at 3:35 PM, Simon Peyton Jones 
> wrote:
I’m keen NOT to introduce these layers of indirection.  I think they make the 
code harder to understand.

Can you give an example function or two, and what it would look like under the 
different approaches.

(1)-(3) appears to be three different approaches, but I don’t think that’s what 
you intend.  I think there are only two: add the indirection layer or not?

S

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 23 August 2017 13:26
To: ghc-devs@haskell.org
Cc: Simon Peyton Jones >; 
Alan & Kim Zimmerman >
Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

In this thread, I am going to raise a topic for discussion. Please share your 
opinions and related experiences.

Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed 
phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*.
However, when programming with these ASTs, we use patterns, such as `HsMultiIf 
:: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among 
phases.
We can
(1) introduce a layer of abstraction providing a set of type and pattern 
synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS  LPsExpr] -> 
PsExpr`; and
(2) updating code working on ASTs of specific phase to use the interface 
specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by 
removing unused variables and placeholders; and
(3) leaving untouched code working uniformly on ASTs of different phases (i.e., 
the generic functions in Trees that Grow terminology), such as the existing 
functions whose types are polymorphic on phase index.

Some comments:

- It can be done gradually and smoothly: we add three separate files in HsSyn 
(per each phase) containing the phase-specific interfaces, and gradually import 
them and do the changes per module.
- Using the interfaces is optional: code using the current method (e.g., using 
`HsMultiIf`) should work just fine.
- It introduces a layer of indirection and three more files to maintain.
- It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as 
placeholders and similar machinery are abstracted away by the interfaces (e.g., 
no need to import bits and pieces of `HsExtension`)
- In theory, there should be zero impact on GHC's runtime performance.

I am myself undecided about its benefit-cost ratio, but willing to at least 
implement the phase-specific 

RE: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

[Simon Peyton Jones via ghc-devs]

I’m keen NOT to introduce these layers of indirection.  I think they make the 
code harder to understand.

Can you give an example function or two, and what it would look like under the 
different approaches.

(1)-(3) appears to be three different approaches, but I don’t think that’s what 
you intend.  I think there are only two: add the indirection layer or not?

S

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 23 August 2017 13:26
To: ghc-devs@haskell.org
Cc: Simon Peyton Jones ; Alan & Kim Zimmerman 

Subject: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

In this thread, I am going to raise a topic for discussion. Please share your 
opinions and related experiences.

Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed 
phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*.
However, when programming with these ASTs, we use patterns, such as `HsMultiIf 
:: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among 
phases.
We can
(1) introduce a layer of abstraction providing a set of type and pattern 
synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS  LPsExpr] -> 
PsExpr`; and
(2) updating code working on ASTs of specific phase to use the interface 
specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by 
removing unused variables and placeholders; and
(3) leaving untouched code working uniformly on ASTs of different phases (i.e., 
the generic functions in Trees that Grow terminology), such as the existing 
functions whose types are polymorphic on phase index.

Some comments:

- It can be done gradually and smoothly: we add three separate files in HsSyn 
(per each phase) containing the phase-specific interfaces, and gradually import 
them and do the changes per module.
- Using the interfaces is optional: code using the current method (e.g., using 
`HsMultiIf`) should work just fine.
- It introduces a layer of indirection and three more files to maintain.
- It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as 
placeholders and similar machinery are abstracted away by the interfaces (e.g., 
no need to import bits and pieces of `HsExtension`)
- In theory, there should be zero impact on GHC's runtime performance.

I am myself undecided about its benefit-cost ratio, but willing to at least 
implement the phase-specific interfaces.
For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, 
and dummy placeholders from the front-end code is the most valuable.

Yours,
  Shayan







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

RE: Docs

[Simon Peyton Jones via ghc-devs]

sphinx-build --version
Sphinx v1.1.3

|  -Original Message-
|  From: Ben Gamari [mailto:b...@smart-cactus.org]
|  Sent: 22 August 2017 14:55
|  To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs 
|  Subject: Re: Docs
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
|  
|  > Ben et al
|  > I’m getting this on Linux when making documentation. I have not
|  > modified any of this documentation. Any ideas?
|  
|  Strangely I'm not able to reproduce any of these. Do these cause the build
|  to fail?
|  
|  What does sphinx-build --version say?
|  
|  Cheers,
|  
|  - Ben

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

RE: Stg-lint and bootstrapping (fails?)

[Simon Peyton Jones via ghc-devs]

Is this with HEAD?  I have an up to date HEAD, and with your command line I 
don't get those warnings.  But I do get the OccAnal warnings, so it's not that 
the warnings are being suppressed.

I'm not sure how to reproduce.

Does this happen on anything smaller?  Eg. on a testsuite program (you'll need 
to switch off the -dno-debug-output)?

Simon

|  -Original Message-
|  From: Gabor Greif [mailto:ggr...@gmail.com]
|  Sent: 22 August 2017 09:57
|  To: Simon Peyton Jones ; ghc-devs 
|  Subject: Re: Stg-lint and bootstrapping (fails?)
|  
|  On 8/21/17, Gabor Greif  wrote:
|  > Hi Simon,
|  >
|  > for me it happens on many files that are compiled with
|  >
|  >   $ make GhcStage2HcOpts="-O1 -g"
|  >
|  > while the stage1 compiler is active.
|  >
|  > Tomorrow I can add a concrete invocation.
|  
|  Here is it:
|  
|  "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall
|  -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -
|  Iincludes/dist-derivedconstants/header
|  -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages
|  -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -
|  icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -
|  icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -
|  icompiler/nativeGen -icompiler/parser -icompiler/prelude -
|  icompiler/profiling -icompiler/rename -icompiler/simplCore -
|  icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -
|  icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -
|  icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -
|  icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -
|  Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build
|  -Icompiler/stage2 -optP-DGHCI -optP-include -
|  optPcompiler/stage2/build/./autogen/cabal_macros.h
|  -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id
|  directory-1.3.0.2 -package-id process-1.6.1.0 -package-id
|  bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id
|  time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -
|  package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-
|  id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id
|  ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id
|  unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -
|  this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -
|  DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing
|  -O1 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir
|  compiler/stage2/build -hidir compiler/stage2/build -stubdir
|  compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs -o
|  compiler/stage2/build/TcEvidence.o -dyno
|  compiler/stage2/build/TcEvidence.dyn_o
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_soeO]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_soeN]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_sosq]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_soxX]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_soy2]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_soy9]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_soyw]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_sowZ]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_sovR]
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|OccurAnal failed to rediscover join point(s): [$j_sovx]
|  WARNING: file compiler/simplCore/SimplCore.hs, line 700
|Simplifier bailing out after 4 iterations [721, 479, 80, 4]
|  Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96}
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
|  WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
|  WARNING: file compiler/simplCore/SimplCore.hs, line 1024
|Not shorting out: ebv_uniq
|  
|  
|  And with `-g` I get even more:
|  
|  
|  $ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -
|  Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -
|  Iincludes/dist-derivedconstants/header
|  -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages
|  -i -icompiler/backpack 

Docs

[Simon Peyton Jones via ghc-devs]

Ben et al
I’m getting this on Linux when making documentation.  I have not modified any 
of this documentation.  Any ideas?
Simon


reading sources... [ 97%] what_glasgow_exts_does

reading sources... [100%] win32-dlls

reading sources... [ 97%] what_glasgow_exts_does

reading sources... [100%] win32-dlls



/5playpen/simonpj/HEAD-1/docs/users_guide/editing-guide.rst:398: ERROR: Error 
in "ghci-cmd" directive:

invalid option block.



.. ghci-cmd:: :module; [*]⟨file⟩

:noindex:



Load a module

/5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:496: ERROR: Error in 
"ghci-cmd" directive:

invalid option block.



.. ghci-cmd:: :{

  :}



Begin or end a multi-line GHCi command block.

/5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:527: ERROR: Error in 
"warning" directive:

invalid option block.



.. warning::

Temporary bindings introduced at the prompt only last until the

next :ghci-cmd:`:load` or :ghci-cmd:`:reload` command, at which time they

will be simply lost. However, they do survive a change of context with

:ghci-cmd:`:module`: the temporary bindings just move to the new location.

/5playpen/simonpj/HEAD-1/docs/users_guide/ghci.rst:533: ERROR: Error in "hint" 
directive:

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

RE: Stg-lint and bootstrapping (fails?)

[Simon Peyton Jones via ghc-devs]

|  Oh dear, then I've really misunderstood the intent of this warning. I've
|  been noticing these during the GHC build for quite some time now.

Really?   

After stumbling on #14142, I removed -dno-debug-output from 
mk/flavours/validate.mk and re-validated.  Not a single occurrence of

|  > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|  > |   OccurAnal failed to rediscover join point(s): [go58_akKa]

How can I reproduce what you are seeing?

Simon

|  -Original Message-
|  From: Ben Gamari [mailto:b...@smart-cactus.org]
|  Sent: 19 August 2017 16:54
|  To: Simon Peyton Jones ; Gabor Greif
|  
|  Cc: ghc-devs 
|  Subject: RE: Stg-lint and bootstrapping (fails?)
|  
|  Simon Peyton Jones  writes:
|  
|  > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|  > |   OccurAnal failed to rediscover join point(s): [go58_akKa]
|  >
|  > That shouldn't happen!  If you can make a repro case, please open a
|  ticket.
|  >
|  Oh dear, then I've really misunderstood the intent of this warning. I've
|  been noticing these during the GHC build for quite some time now.
|  
|  Cheers,
|  
|  - Ben

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

RE: Alex install failure

[Simon Peyton Jones via ghc-devs]

Maybe so, but it's really not a good experience for GHC/Cabal users.   If 
aptget did this, people would bleat loudly.

Simon

| -Original Message-
| From: Ara Adkins [mailto:m...@ara.io]
| Sent: 19 August 2017 00:07
| To: Simon Peyton Jones <simo...@microsoft.com>
| Cc: Ben Gamari <b...@smart-cactus.org>; ghc-devs <ghc-devs@haskell.org>
| Subject: Re: Alex install failure
| 
| [You don't often get email from m...@ara.io. Learn why this is important at
| http://aka.ms/LearnAboutSenderIdentification.]
| 
| NFS can be pretty dodgy with transient files due to latency. Sometimes
| the delete takes appreciable time after the command is issued so the lock
| file might just be persisting. I’d try installing into a cabal sandbox on
| a local drive and see if the same issue crops up.
| 
| _ara
| 
| > On 18 Aug 2017, at 23:43, Simon Peyton Jones <simo...@microsoft.com>
| wrote:
| >
| > | Hmm. Here's a shot in the dark: is home home directory mounted via
| > | NFS by any chance?
| >
| > Direct hit!  (for the shot in the dark).  Yes it's NFS mounted I think.
| So what?
| >
| > Simon
| >
| > | -Original Message-
| > | From: Ben Gamari [mailto:b...@smart-cactus.org]
| > | Sent: 18 August 2017 13:05
| > | To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs  | d...@haskell.org>
| > | Subject: Re: Alex install failure
| > |
| > | Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
| > |
| > | > Friends
| > | > I'm trying to update my installation of alex, on Unix (Ubuntu).
| > | > But I get the dump below It's complaining about a lock file being
| > | > an invalid
| > | argument (see highlight below).
| > | > If I manually remove the file I get past that, it successfully
| > | > installs tf-random, but the same thing happens on the next
| > | > package. So I can install packages one at a time, but that's silly.
| > |
| > | Hmm. Here's a shot in the dark: is home home directory mounted via
| > | NFS by any chance?
| > |
| > | Cheers,
| > |
| > | - Ben
| >
| >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Alex install failure

[Simon Peyton Jones via ghc-devs]

| Then you're another victim of
| 
| https://ghc.haskell.org/trac/ghc/ticket/13945

[Reads ticket].  Blimey.  This looks serious. As in release-blocker (except 
that we have released).   Why does it only happen with 8.2.1?  The ticket has 
no how-to-fix plan.

Simon

| -Original Message-
| From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
| Sent: 18 August 2017 23:53
| To: Simon Peyton Jones <simo...@microsoft.com>
| Cc: Ben Gamari <b...@smart-cactus.org>; ghc-devs <ghc-devs@haskell.org>
| Subject: Re: Alex install failure
| 
| On Sat, Aug 19, 2017 at 12:43 AM, Simon Peyton Jones via ghc-devs  wrote:
| > | Hmm. Here's a shot in the dark: is home home directory mounted via
| > | NFS by any chance?
| >
| > Direct hit!  (for the shot in the dark).  Yes it's NFS mounted I think.
| So what?
| 
| Then you're another victim of
| 
| https://ghc.haskell.org/trac/ghc/ticket/13945
| 
| :-/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Where to discuss the linear types extension of GHC?

[Simon Peyton Jones via ghc-devs]

But it could also be never, if the committee rejects the proposal...

Don’t let that put you off.   The more numerous and compelling the 
applications, the more likely it is that the committee will accept it!

It’s a Big Feature, so the bar is high.  But if there is a diverse bunch of 
actual users saying “this will make our lives much better, and here’s how” the 
case becomes much stronger.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Boespflug, 
Mathieu
Sent: 18 August 2017 22:39
To: Wolfgang Jeltsch 
Cc: ghc-devs ; Edvard Hübinette 
Subject: Re: Where to discuss the linear types extension of GHC?


You don't often get email from m...@tweag.io, which 
appears similar to someone who has previously sent you email, but may not be 
that person. Learn why this may be a 
problem

Feedback

Hi Wolfgang,

great to see interest in linear types! I would advise caution about building 
anything on top of the linear types extension at this time. If you have 
interesting use cases, however, do tell, so that these use cases can influence 
the design.

This is pre-alpha software, meaning that it's not even good enough as a 
developer preview of all the basic features. It's an in-progress development 
branch, which is going to take time to stabilize. Furthermore, whether the 
feature makes it into GHC will depend on what the GHC proposals committee 
thinks about it. The current authors of the would-be extension have yet to 
draft a proposal and submit it to the committee.

If we manage to write a proposal in time, based on a beta level implementation 
of linear types, and if the committee accepts the proposal, then maybe the 
feature can make it into GHC 8.4. Or in GHC 8.6. That's our hope, at any rate. 
But it could also be never, if the committee rejects the proposal...

Best,

--
Mathieu Boespflug
Founder at 
http://tweag.io.

On 18 August 2017 at 22:55, Wolfgang Jeltsch 
> wrote:
Hi!

I just read through the README. According to it, there are several crucial 
things not implemented yet (case and let come to my mind), and there are some 
fundamental bugs (which make it very easy to circumvent linearity checks, 
making the whole extension pointless). Is the situation still like this?

What are your honest expectations regarding the future development of the 
linear types feature and its integration into the official GHC? Is it realistic 
to hope for this feature to be available in a stable GHC version withing, say, 
the next 12 months? I would like to use linearity in some project of mine, but 
at the moment, I am unsure whether it is really a good idea to rely on this 
feature becoming available.

All the best,
Wolfgang

Am Mittwoch, den 19.07.2017, 08:52 + schrieb Edvard Hübinette:
Hi Wolfgang,

the updated README is live and can be found 
here!

Cheers,
Edvard

On Thu, 13 Jul 2017 at 17:54 Spiwack, Arnaud 
> wrote:
I think the answer to both questions can be the same: the github issue of 
Tweag's ghc repo: 
https://github.com/tweag/ghc/issues
 .
Regarding this particular bug: it is a known bug indeed. I'll be fixing it 
soon. We're expanding the README to include known bugs and usage instruction.
Thanks a lot for your time and interest,
Arnaud

On Thu, Jul 13, 2017 at 12:14 AM, Wolfgang Jeltsch 
> wrote:

Hi!

Another question is where to submit bugs. I already found the first one :


GHCi> let dup :: a -> (a, a); dup x = (x, x)

GHCi> let unsafeDup :: a ⊸ (a, a); unsafeDup = dup

GHCi> :type unsafeDup

unsafeDup :: a ⊸ (a, a)

GHCi> unsafeDup True

(True,True)

All the best,
Wolfgang

Am Mittwoch, den 12.07.2017, 23:15 +0300 schrieb Wolfgang Jeltsch:
Hi!

I think I will have several questions about the linear types extension when 
trying to use it in the near future. Furthermore, I also want to give feedback 
on the 

RE: Alex install failure

[Simon Peyton Jones via ghc-devs]

| Hmm. Here's a shot in the dark: is home home directory mounted via NFS by
| any chance?

Direct hit!  (for the shot in the dark).  Yes it's NFS mounted I think.  So 
what?

Simon

| -Original Message-
| From: Ben Gamari [mailto:b...@smart-cactus.org]
| Sent: 18 August 2017 13:05
| To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs 
| Subject: Re: Alex install failure
| 
| Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
| 
| > Friends
| > I'm trying to update my installation of alex, on Unix (Ubuntu).  But I
| > get the dump below It's complaining about a lock file being an invalid
| argument (see highlight below).
| > If I manually remove the file I get past that, it successfully
| > installs tf-random, but the same thing happens on the next package. So
| > I can install packages one at a time, but that's silly.
| 
| Hmm. Here's a shot in the dark: is home home directory mounted via NFS by
| any chance?
| 
| Cheers,
| 
| - Ben

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

RE: Alex install failure

[Simon Peyton Jones via ghc-devs]

That's what I did.   It then succeeds in installing one package, and fails in 
the same way on the next one.  So I can install packages one at a time, by 
deleting the lock file manually each time.  Bizarre.

Simon

| -Original Message-
| From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
| Sent: 18 August 2017 11:59
| To: Simon Peyton Jones <simo...@microsoft.com>
| Subject: Re: Alex install failure
| 
| Try removing
| 
| /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock
| 
| 
| 
| On Fri, Aug 18, 2017 at 12:25 PM, Simon Peyton Jones via ghc-devs  wrote:
| > Friends
| >
| > I’m trying to update my installation of alex, on Unix (Ubuntu).  But I
| > get the dump below
| >
| > It’s complaining about a lock file being an invalid argument (see
| > highlight below).
| >
| > If I manually remove the file I get past that, it successfully
| > installs tf-random, but the same thing happens on the next package.
| > So I can install packages one at a time, but that’s silly.
| >
| > Any ideas?
| >
| > Simon
| >
| >
| >
| > cabal install alex
| >
| > Resolving dependencies...
| >
| > Configuring tf-random-0.5...
| >
| > Building tf-random-0.5...
| >
| > Failed to install tf-random-0.5
| >
| > Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ):
| >
| > cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5'
| >
| > Configuring tf-random-0.5...
| >
| > Building tf-random-0.5...
| >
| > Preprocessing library tf-random-0.5...
| >
| > [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs,
| > dist/build/System/Random/TF/Gen.o )
| >
| > [2 of 4] Compiling System.Random.TF.Init (
| > src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o )
| >
| >
| >
| > src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations]
| >
| > In the use of ‘bitSize’ (imported from Data.Bits):
| >
| > Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"
| >
| >|
| >
| > 94 |   | bitSize n > 64 = error "mkTFGen: case where size of Int > 64
| not
| > implemented"
| >
| >| ^^^
| >
| > [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs,
| > dist/build/System/Random/TF.o )
| >
| > [4 of 4] Compiling System.Random.TF.Instances (
| > src/System/Random/TF/Instances.hs,
| > dist/build/System/Random/TF/Instances.o )
| >
| > Creating package registration file:
| >
| > /tmp/pkgConf-tf-random-05965166491189641421.5
| >
| > Installing library in
| >
| > /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3m
| > XYlHUEE5hzgewx
| >
| > Registering tf-random-0.5...
| >
| > cabal: '/usr/local/bin/ghc-pkg' exited with an error:
| >
| > ghc-pkg: Couldn't open database
| >
| > /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification:
| >
| > {handle:
| >
| > /home/simonpj/.ghc/x86_64-linux-
| 8.2.1/package.conf.d/package.cache.lock}:
| >
| > hLock: invalid argument (Bad file descriptor)
| >
| > cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5'
| >
| > cabal: Error: some packages failed to install:
| >
| > QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install.
| >
| > alex-3.2.1 depends on tf-random-0.5 which failed to install.
| >
| > tf-random-0.5 failed during the final install step. The exception was:
| >
| > ExitFailure 1
| >
| > simonpj@cam-05-unx:~/code/HEAD$
| >
| >
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
| > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=02%7C01%7Csimonpj%40microsoft.com%7C3f6ad797e3454147fa5e08d4e62
| 821e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636386507413664213
| ta=ex4vc7sfwhYQsoTNUKSrtdKZtIkDxDWor0CEKN0M4Wk%3D=0
| >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Stg-lint and bootstrapping (fails?)

[Simon Peyton Jones via ghc-devs]

| WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|   OccurAnal failed to rediscover join point(s): [go58_akKa]

That shouldn't happen!  If you can make a repro case, please open a ticket.

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
| Greif
| Sent: 17 August 2017 09:49
| To: Ben Gamari 
| Cc: ghc-devs 
| Subject: Re: Stg-lint and bootstrapping (fails?)
| 
| [You don't often get email from ggr...@gmail.com. Learn why this is
| important at http://aka.ms/LearnAboutSenderIdentification.]
| 
| Hi Ben,
| 
| thanks for also looking into the issue! I am in the process of debugging
| a miscompilation related to #13861 (self-inflicted, hahahar), but without
| a working linter I am pretty much toast... I'll wait a bit more until
| your fixed hit master.
| 
| Unrelated to linting, but seemingly related to "-g" I get a ton of
| warnings like this:
| 
| WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
|   OccurAnal failed to rediscover join point(s): [go58_akKa]
| 
| Is this perhaps covered by your fixes?
| 
| Cheers,
| 
| Gabor
| 
| On 8/16/17, Ben Gamari  wrote:
| > Gabor Greif  writes:
| >
| >> Hi all,
| >>
| >> I tried an stg-lint build thus:
| >>
| > How timely; just yesterday I looked at a number of stg lint issues
| > after having noticed a number of issues with it over the past few
| months.
| > I pushed patches for a number of issues (#14116, #14117, #14118) to
| > Phabricator, but the bigger problem is #14120, which I don't yet have
| > a compelling solution for (other than the "give up on catching all but
| > the most trivial type errors" approach).
| >
| > Cheers,
| >
| > - Ben
| >
| >
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=02%7C01%7Csimonpj%40microsoft.com%7C057084a514e548c9642c08d4e54
| cd776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636385565585443027
| ta=2NNSmwZJv0czL4BykKENAWW38sUhYHF7IYyXscAfHdw%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Alex install failure

[Simon Peyton Jones via ghc-devs]

Friends
I'm trying to update my installation of alex, on Unix (Ubuntu).  But I get the 
dump below
It's complaining about a lock file being an invalid argument (see highlight 
below).
If I manually remove the file I get past that, it successfully installs 
tf-random, but the same thing happens on the next package.  So I can install 
packages one at a time, but that's silly.
Any ideas?
Simon


cabal install alex

Resolving dependencies...

Configuring tf-random-0.5...

Building tf-random-0.5...

Failed to install tf-random-0.5

Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ):

cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5'

Configuring tf-random-0.5...

Building tf-random-0.5...

Preprocessing library tf-random-0.5...

[1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, 
dist/build/System/Random/TF/Gen.o )

[2 of 4] Compiling System.Random.TF.Init ( src/System/Random/TF/Init.hs, 
dist/build/System/Random/TF/Init.o )



src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations]

In the use of 'bitSize' (imported from Data.Bits):

Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"

   |

94 |   | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not 
implemented"

   | ^^^

[3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, 
dist/build/System/Random/TF.o )

[4 of 4] Compiling System.Random.TF.Instances ( 
src/System/Random/TF/Instances.hs, dist/build/System/Random/TF/Instances.o )

Creating package registration file:

/tmp/pkgConf-tf-random-05965166491189641421.5

Installing library in

/home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3mXYlHUEE5hzgewx

Registering tf-random-0.5...

cabal: '/usr/local/bin/ghc-pkg' exited with an error:

ghc-pkg: Couldn't open database

/home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification:

{handle:

/home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock}:

hLock: invalid argument (Bad file descriptor)

cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5'

cabal: Error: some packages failed to install:

QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install.

alex-3.2.1 depends on tf-random-0.5 which failed to install.

tf-random-0.5 failed during the final install step. The exception was:

ExitFailure 1

simonpj@cam-05-unx:~/code/HEAD$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Occurrence info on binders and STG

[Simon Peyton Jones via ghc-devs]

Can you be more specific?  I don’t think occurrence info is used at all in STG.

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
| Greif
| Sent: 01 August 2017 16:02
| To: ghc-devs 
| Subject: Occurrence info on binders and STG
| 
| Hi devs!
| 
| I just had a short exchange with Joachim, he sent me to this place.
| 
| Can anybody explain how occurrence info is used in STG?
| 
| Cheers and thanks,
| 
| Gabor
| 
| -- Forwarded message --
| From: Joachim Breitner 
| Date: Tue, 01 Aug 2017 10:47:48 -0400
| Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders
| (b311096)
| To: Gabor Greif 
| 
| Hi,
| 
| feel free to CC the mailing list on such questions. I often don’t know
| things perfectly either.
| 
| Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif:
| 
| >
| > Loosely related question:
| 
| Very loosely :-)
| 
| 
| >  - when doing STG Cse, the occurrence info is not updated when a
| > wild(card)-binder is used. Is there a recommended way to re-run
| > occ-analysis on STG? (I fear there is not.)
| 
| I fear that too. It the occ info used past that stage?
| 
| >  - I noticed that "wild"-binders sometimes do not appear at their
| > binding site (after "of" and "{") in STG dumps. Dumping gets
| > suppressed when they are deemed dead. Should STG consider occ-info at
| > all?
| 
| Good questions. I remember that Simon commented on that before, but I
| don’t remember where…
| 
| 
| > oachim
| --
| Joachim “nomeata” Breitner
|   m...@joachim-breitner.de •
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joac
| him-
| breitner.de%2F=04%7C01%7Csimonpj%40microsoft.com%7Cf811a87d003a4dd67
| ae908d4d8ee5b7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636371965641
| 220522%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
| oiT3RoZXIifQ%3D%3D%7C-
| 1=cKuY1cGPJnfqqaV1wwGU5qCORpiquDNbDeA0ppgKH%2Bc%3D=0
|   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
|   Debian Developer: nome...@debian.org
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=04%7C01%7Csimonpj%40microsoft.com%7Cf811a87d003a4dd67ae908d4d8e
| e5b7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636371965641220522%7CU
| nknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT3RoZXIi
| fQ%3D%3D%7C-
| 1=IZBnhS28yxzjesQY%2B6j8%2B330rL1Vx2WO60r9nxPnOU0%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Restructuring hsSyn

[Simon Peyton Jones via ghc-devs]

I don’t object.   (They’d be orphan instances, so the interface file will 
always be loaded; but that’s probably ok.

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 02 August 2017 11:50
To: ghc-devs@haskell.org
Cc: Simon Peyton Jones ; Alan & Kim Zimmerman 

Subject: Restructuring hsSyn

Currently AST declarations, their relate utilities, and `Outputable` instances 
are defined in the same files.
Does anyone object to moving `Outputable` instances to separate files?
The purpose is to gradually identify reusable functionalities, group them 
together, polish them (e.g., remove some unnecessary dependencies), and expose 
them to the end-users.
At this stage, I don't expect any changes outside hsSyn.

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

RE: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy (6a50466)

[Simon Peyton Jones via ghc-devs]

Joachim

Aha!  I think my comment on Phab is redundant.  You are simply avoiding name 
capture, which is obviously right; you are not restricting the applicability of 
the transformation.

Needless to say, a Note would help in due course.

S

|  -Original Message-
|  From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf
|  Of g...@git.haskell.org
|  Sent: 02 August 2017 04:07
|  To: ghc-comm...@haskell.org
|  Subject: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy
|  (6a50466)
|  
|  Repository : ssh://g...@git.haskell.org/ghc
|  
|  On branch  : wip/T14068
|  Link   :
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha
|  skell.org%2Ftrac%2Fghc%2Fchangeset%2F6a5046684f93f1870663119b447fff6ba
|  eb7a7c4%2Fghc=04%7C01%7Csimonpj%40microsoft.com%7Cc45ce3f4deea476
|  9222b08d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724
|  00832017356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
|  IsIkFOIjoiT3RoZXIifQ%3D%3D%7C-
|  1=29Iajm6oTE3Zm%2Bdl5ocMav7MPw%2FniO9%2BVeuQm38qWXQ%3D=
|  0
|  
|  >---
|  
|  commit 6a5046684f93f1870663119b447fff6baeb7a7c4
|  Author: Joachim Breitner 
|  Date:   Tue Aug 1 22:48:26 2017 -0400
|  
|  Avoid name capture in setJoinResTy
|  
|  
|  >---
|  
|  6a5046684f93f1870663119b447fff6baeb7a7c4
|   compiler/types/Type.hs | 22 --
|   1 file changed, 16 insertions(+), 6 deletions(-)
|  
|  diff --git a/compiler/types/Type.hs b/compiler/types/Type.hs index
|  50a35b0..c69d4ff 100644
|  --- a/compiler/types/Type.hs
|  +++ b/compiler/types/Type.hs
|  @@ -2445,11 +2445,21 @@ setJoinResTy :: Int  -- Number of binders to
|  skip
|-> Type -- New type
|   -- INVARIANT: If any of the first n binders are foralls, those tyvars
|  cannot
|   -- appear in the original result type. See isValidJoinPointType.
|  +--
|  +-- When we set the return type under a forall, avoid capture!
|   setJoinResTy orig_ar new_res_ty orig_ty
|  -  = go orig_ar orig_ty
|  +  = go init_subst orig_ar orig_ty
| where
|  -go 0 _  = new_res_ty
|  -go n ty | Just (arg_bndr, res_ty) <- splitPiTy_maybe ty
|  -= mkPiTy arg_bndr (go (n-1) res_ty)
|  -| otherwise
|  -= pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty)
|  +init_subst :: TCvSubst
|  +init_subst = mkEmptyTCvSubst (mkInScopeSet (tyCoVarsOfType
|  + new_res_ty))
|  +
|  +go _ 0 _  = new_res_ty
|  +go subst n ty
|  +| Just (t, ty') <- splitForAllTy_maybe ty
|  +, let (subst', t') = substTyVarBndr subst t
|  += mkForAllTy t' Inferred (go subst' (n-1) ty')
|  +| Just (arg_ty, ty') <- splitFunTy_maybe ty
|  +, let arg_ty' = substTy subst arg_ty
|  += mkFunTy arg_ty' (go subst (n-1) ty')
|  +| otherwise
|  += pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty)
|  
|  ___
|  ghc-commits mailing list
|  ghc-comm...@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  commits=04%7C01%7Csimonpj%40microsoft.com%7Cc45ce3f4deea4769222b0
|  8d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724008320
|  17356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO
|  IjoiT3RoZXIifQ%3D%3D%7C-
|  1=7%2FAY0EcihvMkjGOHdYdpOog2Roahk0XD%2BunNg54pKFc%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: dataToTag# documentation

[Simon Peyton Jones via ghc-devs]

Based on memory rather that investigation:

- yes it works on any data type

- The reason that the primop dataToTag# is dangerous is that it does
  not evaluate its argument; it relies on the wrapper getTag to do
  so.Caveat emptor!  It would be good to document this.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  David Feuer
|  Sent: 02 August 2017 03:04
|  To: ghc-devs@haskell.org
|  Subject: dataToTag# documentation
|  
|  dataToTag# is documented as getting the tag number of an enumeration,
|  which is perfectly reasonable because it's designed to support
|  deriving Enum.
|  But it *appears* to work also for non-enumeration datatypes:
|  
|  dataToTag# Nothing = 0#
|  dataToTag# (Just 3) = 1#
|  
|  Does this actually always work? If so, should that be documented, or
|  is there a realistic possibility that its behavior will change in the
|  future?
|  
|  Additionally: the documentation for dataToTag# urges readers to use
|  GHC.Base.getTag instead. But dataToTag# is exported from the "public"
|  GHC.Exts, whereas getTag is not. Should we add getTag to GHC.Exts, or
|  change the documentation for dataToTag#?
|  
|  David
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=04%7C01%7Csimonpj%40microsoft.com%7C769c2a45735642edd36508d4
|  d94a767e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363723612191322
|  18%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
|  iT3RoZXIifQ%3D%3D%7C-
|  1=585d0E3YyeKBk3DYqpvWR8ePnMR6bJ6%2Bu6dAGYk%2BNxo%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: GHC 8.2 generated code faster than 8.0 but slower than 7.10

[Simon Peyton Jones via ghc-devs]

Thanks.  Could you open a Trac ticket, and explain carefully how to reproduce 
your results?

Surely 8.4 should be faster than 7.10!

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Harendra Kumar
Sent: 01 August 2017 10:46
To: ghc-devs@haskell.org
Subject: GHC 8.2 generated code faster than 8.0 but slower than 7.10

Unicode normalization library 
(https://github.com/harendra-kumar/unicode-transforms)
 shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across 
most benchmarks. However, it is still somewhat slower when compared to GHC 
7.10.3. Here are some results:

GHC 7.10.3:

benchmarking unicode-transforms-text/NFD/English
time 4.823 ms   (4.765 ms .. 4.902 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time 16.46 ms   (16.24 ms .. 16.78 ms)


GHC 8.0.1


benchmarking unicode-transforms-text/NFD/English
time 6.330 ms   (6.232 ms .. 6.439 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time 18.02 ms   (17.77 ms .. 18.22 ms)

GHC 8.2.1


benchmarking unicode-transforms-text/NFD/English
time 5.659 ms   (5.594 ms .. 5.740 ms)

benchmarking unicode-transforms-text/NFD/Devanagari
time 16.48 ms   (16.30 ms .. 16.69 ms)

This library has been optimized with an objective to match or better (in some 
cases it is better) the performance of the equivalent ICU C++ library (compare 
only decompose normalization). Some of the last hurdles to match the best case 
of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated 
code is significantly faster than GHC native, I have not yet tested LLVM 
backend with 8.2.1 so not sure if that too has improved correspondingly.

I just wanted to share these results with the GHC devs. Thanks for all the good 
work. Also wondering which specific changes might have caused this improvement.

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

RE: Operating on HsSyn

[Simon Peyton Jones via ghc-devs]

Am I far off?
I don’t think you are far off.  All I’m after is the debug-printer use-case: I 
want to be able to see the contents of the tree, including the PostRn 
annotations.  I don’t care about round-tripping it.

Simon

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 28 July 2017 15:32
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman ; Jacques 
Carette 
Subject: Re: Operating on HsSyn

On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see 
what the renamer has done?

Right. So if I understand correctly, with this semantics, `Outputable` is 
somewhere between pretty printing as often used in program manipulation 
libraries (like Haskell-Src-Exts (HSE)) which is closer to syntax, and `Show` 
which is closer to Haskell representation.
(There are also "exact printers" (as in HSE) that are even closer to syntax in 
some sense.)
Often, pretty printers generate only grammatically valid terms, not the ones 
polluted with extra annotations (hence grammatically invalid), e.g., what is 
the grammatically valid form of `OpApp` printed via `Outputable` that includes 
the fixity annotation.

If I recall correctly, we have briefly studied these in the past summer, we 
came up with some roundtrip correctness criteria, like the following (bar error 
handling; assume valid input):

 (parser . prettyPrint . parser) = id

[paging in Jacques]

The reason I am trying to flesh out the semantics is the /big/ gains on code 
reuse later on in the process: one does not need to define a separate pretty 
printing library for Haskell syntax, and can reuse the well-tested and 
well-maintained one in GHC.

Reformulating part of your concern, based on my understanding (if I may), the 
questions is: what is the proper design of an "outputer" (debug-printer?) where 
/annotated/ terms can be pretty-printed including any printable 
(pretty?showable?) annotations.
In particular, we may want to take advantage of extensibility of data types for 
this.
Am I far off?

Note: with proper design, an extensible debug-printer can still subsume 
corresponding pretty-printers.


On Fri, Jul 28, 2017 at 2:36 PM, Simon Peyton Jones 
> wrote:
I have been under the impression that we don't even want to print those.
On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see 
what the renamer has done?

Simon

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 28 July 2017 12:20
To: Simon Peyton Jones >
Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman 
>
Subject: Re: Operating on HsSyn

Before all this, we may need to discuss a bit about the intended semantics of
`Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out`
suffixed constructors?  If not, then we only need to write a set of instances
for the base growable AST, once and for all.  Such instances will be polymorphic
on the extension descriptor `p`, and do not need to mention the constraints like
`(PostRn p (IdP p)`, since these are just extensions and not part of the base
growable AST.  Or, am I missing something about the intended semantics of
`Outputable`?

You write

So today we never print these annotations, to avoid bloating the instance 
contexts, which can be painful.

I have been under the impression that we don't even want to print those.

Of course, there are scenarios (like `Show` instances) where we do want to write
compositional / generic functions that take into account the extensions.
Here is my abstract overview of the scenario, that may help the discussion.
Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler 
phase) that
 are defined as extensions to a base datatype `T`:

> A = T XA
> B = T XB
> C = T XC

where `X*`s are extension descriptors.
Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, `B`, 
and `C`.
We have two main alternatives:
(a) either we write these  (manually or using the deriving mechanism) separately
(b) or we write a generic / parametric function `g` over `T`, and reuse that to 
define `f_*`s

Of course, (b) is preferable in theory , but not always possible or preferable 
in practice.
In which case, we can always resort to (a).
The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more 
parametric should
`g` get, as this is the case for any generic function.

With a correct design, I believe, these are all independent of Trees that Grow 
story itself:
we are now not only trying to reuse data types, and functions agnostic towards 
extensions
(pretty printers in my view of their semantics), but also reuse functions with 
parametric /
varying behaviour with respect to extensions.

/Shayan



On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones 

RE: Operating on HsSyn

[Simon Peyton Jones via ghc-devs]

I have been under the impression that we don't even want to print those.
On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see 
what the renamer has done?

Simon

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 28 July 2017 12:20
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman 
Subject: Re: Operating on HsSyn

Before all this, we may need to discuss a bit about the intended semantics of
`Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out`
suffixed constructors?  If not, then we only need to write a set of instances
for the base growable AST, once and for all.  Such instances will be polymorphic
on the extension descriptor `p`, and do not need to mention the constraints like
`(PostRn p (IdP p)`, since these are just extensions and not part of the base
growable AST.  Or, am I missing something about the intended semantics of
`Outputable`?

You write

So today we never print these annotations, to avoid bloating the instance 
contexts, which can be painful.

I have been under the impression that we don't even want to print those.

Of course, there are scenarios (like `Show` instances) where we do want to write
compositional / generic functions that take into account the extensions.
Here is my abstract overview of the scenario, that may help the discussion.
Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler 
phase) that
 are defined as extensions to a base datatype `T`:

> A = T XA
> B = T XB
> C = T XC

where `X*`s are extension descriptors.
Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, `B`, 
and `C`.
We have two main alternatives:
(a) either we write these  (manually or using the deriving mechanism) separately
(b) or we write a generic / parametric function `g` over `T`, and reuse that to 
define `f_*`s

Of course, (b) is preferable in theory , but not always possible or preferable 
in practice.
In which case, we can always resort to (a).
The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more 
parametric should
`g` get, as this is the case for any generic function.

With a correct design, I believe, these are all independent of Trees that Grow 
story itself:
we are now not only trying to reuse data types, and functions agnostic towards 
extensions
(pretty printers in my view of their semantics), but also reuse functions with 
parametric /
varying behaviour with respect to extensions.

/Shayan



On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones 
> wrote:
Devs,

Shayan is working away on “Trees that grow”… do keep it on your radar:

To: ghc-devs
Sent: 25 May 2017 23:49
Do take a look at this:


• We propose to re-engineer HsSyn itself.  This will touch a lot of 
code.

• But it’s very neat, and will bring big long-term advantages

• And we can do it a bit at a time

The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow 
has the details.  It’s entirely an internal change, not a change to GHC’s 
specification, so it’s independent of the GHC proposals process.  But I’d value 
the opinion of other GHC devs

Meanwhile I have a question. When pretty-printing HsSyn we often have a 
situation like this:


  data Pass = Parsed | Renamed | Typechecked



  data HsExpr (p :: Pass) = HsVar (IdP p) | 



  type famliy IdP p where

 IdP Parsed  = RdrName

 IdP Renamed = Name

 IdP Typechecked = Id



  instance (Outputable (IdP p)) => Outputable (HsExpr p) where

 ppr (HsVar v) = ppr v

The (ppr v) requires (Outputable (IdP p)), hence the context.

Moreover, and more seriously, there are things we just can't pretty-print
right now.  For example, HsExpr has this data constructor:


  data HsExpr p = ...

| OpApp   (LHsExpr p)

  (LHsExpr p)

  (PostRn p Fixity)

  (LHsExpr p)

To pretty-print the third argument, we'd need to add


  instance (Outputable (IdP p),

Outputable (PostRn p Fixity))   -- New

=> Outputable (HsExpr p) where

 ppr (HsVar v) = ppr v


and that gets onerous.  So today we never print these annotations, to avoid 
bloating the instance contexts, which can be painful.  It bit me yesterday.

We have bitten that bullet for the Data class: look at HsExtension.DataId, 
which abbreviates the long list of dictionaries:


  type DataId p =

( Data p

, ForallX Data p

, Data (NameOrRdrName (IdP p))

, Data (IdP p)

, Data (PostRn p (IdP p))

, Data (PostRn p (Located Name))

, Data (PostRn p Bool)

, Data (PostRn p Fixity)

 ,..and nine more... )

Let me note in passing that 
[wiki:QuantifiedContexts]
 would make this somewhat shorter


  type DataId p =

( Data p

, ForallX Data p

, Data (NameOrRdrName (IdP p))

, 

Operating on HsSyn

[Simon Peyton Jones via ghc-devs]

Devs,

Shayan is working away on "Trees that grow"... do keep it on your radar:

To: ghc-devs
Sent: 25 May 2017 23:49

Do take a look at this:


* We propose to re-engineer HsSyn itself.  This will touch a lot of 
code.

* But it's very neat, and will bring big long-term advantages

* And we can do it a bit at a time

The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow 
has the details.  It's entirely an internal change, not a change to GHC's 
specification, so it's independent of the GHC proposals process.  But I'd value 
the opinion of other GHC devs

Meanwhile I have a question. When pretty-printing HsSyn we often have a 
situation like this:


  data Pass = Parsed | Renamed | Typechecked



  data HsExpr (p :: Pass) = HsVar (IdP p) | 



  type famliy IdP p where

 IdP Parsed  = RdrName

 IdP Renamed = Name

 IdP Typechecked = Id



  instance (Outputable (IdP p)) => Outputable (HsExpr p) where

 ppr (HsVar v) = ppr v

The (ppr v) requires (Outputable (IdP p)), hence the context.

Moreover, and more seriously, there are things we just can't pretty-print
right now.  For example, HsExpr has this data constructor:


  data HsExpr p = ...

| OpApp   (LHsExpr p)

  (LHsExpr p)

  (PostRn p Fixity)

  (LHsExpr p)

To pretty-print the third argument, we'd need to add


  instance (Outputable (IdP p),

Outputable (PostRn p Fixity))   -- New

=> Outputable (HsExpr p) where

 ppr (HsVar v) = ppr v


and that gets onerous.  So today we never print these annotations, to avoid 
bloating the instance contexts, which can be painful.  It bit me yesterday.

We have bitten that bullet for the Data class: look at HsExtension.DataId, 
which abbreviates the long list of dictionaries:


  type DataId p =

( Data p

, ForallX Data p

, Data (NameOrRdrName (IdP p))

, Data (IdP p)

, Data (PostRn p (IdP p))

, Data (PostRn p (Located Name))

, Data (PostRn p Bool)

, Data (PostRn p Fixity)

 ,..and nine more... )

Let me note in passing that 
[wiki:QuantifiedContexts]
 would make this somewhat shorter


  type DataId p =

( Data p

, ForallX Data p

, Data (NameOrRdrName (IdP p))

, Data (IdP p)

, forall t. Data t => Data (PostRn p t))

But we still need one item in this list for each type function,
and I am worried about how this scales to the
[wiki:ImplementingTreesThatGrow]
 story, when we have a type
function for each data constructor -- and there are a lot of data
constructors.

So I have four questions


  1.  I think we should probably use a superclass instead of a type synonym


class (Data p, ForallX Data p, ) => DataId p where {}


Why?  Only one argument to pass, and to pass on to successive calls.  I see no 
downside.


  1.  Shall we treat Outputable like Data?  (I.e. make an abbreviation for a 
long list of Outputable instances and use it everywhere)

  2.  I thought of another way to do it (pass a token); see below


  1.  Are there any other ways?


Token passing idea.

Perhaps instead of passing lots of functions, we pass a singleton token
that encodes the pass, like this:


  instance (PassC p) => Outputable (HsExpr p) where

 ppr (HsVar v) = case getPass :: IsPass p of

   IsParsed  -> ppr v

   IsRenamed -> ppr v

   IsTypechecked -> ppr v

The three ppr's are at different types, of course; that's the point.
The infrastructure is something like


  class PassC p where

getPass :: IsPass p



  data IsPass p where

IsParsed  :: IsPass Parsed

IsRenamed :: IsParsed Renamed

IsTypechecked :: IsParsed Typechecked



  instance PassC Parsed where getPass = IsParsed

...etc...

Now we could sweep away all those OutputableX classes,
replacing them with dynamic tests on the singletons IsParsed etc.
This would have advantages:

- Probably faster: there's a dynamic test, but many fewer dictionary
  arguments and higher-order function dispatch

- Only one dictionary to pass; programming is easier.

The big downside is that it's not extensible: it works only because
we know the three cases.  But the "Trees that Grow" story really doesn't
scale well to pretty-printing: so maybe we should just give up on that?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: Improve error messages around kind mismatches. (8e15e3d)

[Simon Peyton Jones via ghc-devs]

|  typecheck/should_fail/T7368) Solution: track the provenance of
|  Derived constraints and refuse to float out a constraint that has
|  an insoluble Derived.

For the record, that's not the solution that the patch implements.  Instead we 
just don’t float heterogeneous equalities.

I think Richard just forgot to update the commit message.

Simon



|  -Original Message-
|  From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf
|  Of g...@git.haskell.org
|  Sent: 27 July 2017 12:50
|  To: ghc-comm...@haskell.org
|  Subject: [commit: ghc] master: Improve error messages around kind
|  mismatches. (8e15e3d)
|  
|  Repository : ssh://g...@git.haskell.org/ghc
|  
|  On branch  : master
|  Link   :
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha
|  skell.org%2Ftrac%2Fghc%2Fchangeset%2F8e15e3d370e9c253ae0dbb330e25b72cb
|  00cdb76%2Fghc=02%7C01%7Csimonpj%40microsoft.com%7C9993301a429e467
|  e29b008d4d4e6350f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363675
|  32584262688=bY%2Bruj0hhXfC23hfMA1ivuAs2Av2%2BY4%2BJK2yyCoPzbA%3D
|  =0
|  
|  >---
|  
|  commit 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76
|  Author: Richard Eisenberg 
|  Date:   Thu Jun 1 17:27:14 2017 -0400
|  
|  Improve error messages around kind mismatches.
|  
|  Previously, when canonicalizing (or unifying, in uType) a
|  heterogeneous equality, we emitted a kind equality and used the
|  resulting coercion to cast one side of the heterogeneous equality.
|  
|  While sound, this led to terrible error messages. (See the bugs
|  listed below.) The problem is that using the coercion built from
|  the emitted kind equality is a bit like a wanted rewriting a
|  wanted.
|  The solution is to keep heterogeneous equalities as irreducible.
|  
|  See Note [Equalities with incompatible kinds] in TcCanonical.
|  
|  This commit also removes a highly suspicious switch to
|  FM_SubstOnly
|  when flattening in the kinds of a type variable. I have no idea
|  why this was there, other than as a holdover from pre-TypeInType.
|  I've not left a Note because there is simply no reason I can
|  conceive
|  of that the FM_SubstOnly should be there.
|  
|  One challenge with this patch is that the emitted derived
|  equalities
|  might get emitted several times: when a heterogeneous equality is
|  in an implication and then gets floated out from the implication,
|  the Derived is present both in and out of the implication. This
|  causes a duplicate error message. (Test case:
|  typecheck/should_fail/T7368) Solution: track the provenance of
|  Derived constraints and refuse to float out a constraint that has
|  an insoluble Derived.
|  
|  Lastly, this labels one test (dependent/should_fail/RAE_T32a)
|  as expect_broken, because the problem is really #12919. The
|  different handling of constraints in this patch exposes the error.
|  
|  This fixes bugs #11198, #12373, #13530, and #13610.
|  
|  test cases:
|  typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}
|  
|  
|  >---
|  
|  8e15e3d370e9c253ae0dbb330e25b72cb00cdb76
|   compiler/typecheck/TcCanonical.hs  | 296
|  -
|   compiler/typecheck/TcErrors.hs |  75 --
|   compiler/typecheck/TcEvidence.hs   |   8 +-
|   compiler/typecheck/TcFlatten.hs|  31 ++-
|   compiler/typecheck/TcRnTypes.hs|  30 ++-
|   compiler/typecheck/TcSimplify.hs   |  34 ++-
|   compiler/typecheck/TcType.hs   |  10 +-
|   compiler/typecheck/TcUnify.hs  |  28 +-
|   compiler/types/Type.hs |   4 +-
|   testsuite/tests/dependent/should_fail/T11471.hs|   2 +-
|   .../tests/dependent/should_fail/T11471.stderr  |  11 +-
|   testsuite/tests/dependent/should_fail/all.T|   2 +-
|   testsuite/tests/gadt/gadt7.stderr  |   6 +-
|   .../tests/ghci.debugger/scripts/break012.stdout|  14 +-
|   .../indexed-types/should_fail/ExtraTcsUntch.stderr |   6 +-
|   .../tests/indexed-types/should_fail/T5934.stderr   |  13 -
|   testsuite/tests/polykinds/T12593.stderr|  56 
|   testsuite/tests/polykinds/T13555.stderr|  21 +-
|   testsuite/tests/polykinds/T7438.stderr |   6 +-
|   testsuite/tests/polykinds/T8566.stderr |   2 +-
|   testsuite/tests/polykinds/T9017.stderr |  10 +-
|   testsuite/tests/typecheck/should_fail/T12373.hs|  10 +
|   .../tests/typecheck/should_fail/T12373.stderr  |   8 +
|   testsuite/tests/typecheck/should_fail/T13530.hs|  11 +
|   .../tests/typecheck/should_fail/T13530.stderr  |   7 +
|   

RE: D3754: Refactor uo_thing

[Simon Peyton Jones via ghc-devs]

Richard

I'm on a train, so can't look at the detail.  But the following thought occurs 
to me.

uo_thing is a Maybe SDoc attached to a constraint.   But a constraint also has 
a stack of [ErrCtxt], captured in the CtLoc.  That's what produces the "In the 
declaration for ..." stuff.

Idea: instead of uo_thing, could we just push an extra ErrCtxt onto the stack, 
in the CtLoc for this constraint?  (Or not, in the Nothing case.)

Simon

From: nore...@phabricator.haskell.org [mailto:nore...@phabricator.haskell.org]
Sent: 18 July 2017 19:39
To: Simon Peyton Jones 
Subject: [Differential] [Request, 533 lines] D3754: Refactor uo_thing

goldfire created this revision.
Herald added subscribers: thomie, rwbarton.
Herald added a reviewer: hvr.
View Revision


REVISION SUMMARY

The uo_thing field of TypeEqOrigin is used to track the
"thing" (either term or type) that has the type (kind) stored
in the TypeEqOrigin fields. Previously, this was sometimes a
proper Core Type, which needed zonking and tidying. Now, it
is only HsSyn: much simpler, and the error messages now use
the user-written syntax.

But this aspect of uo_thing didn't cause Trac 
#13819; it was the
sibling field uo_arity that did. uo_arity stored the number
of arguments of uo_thing, useful when reporting something
like "should have written 2 fewer arguments". We wouldn't want
to say that if the thing didn't have two arguments. However,
in practice, GHC was getting this wrong, and this message
didn't seem all that helpful. Furthermore, the calculation
of the number of arguments is what caused Trac 
#13819 to fall over.
This patch just removes uo_arity. In my opinion, the change
to error messages is a nudge in the right direction.

Test case: typecheck/should_fail/T13819

TEST PLAN

./validate

REPOSITORY
rGHC Glasgow Haskell Compiler

BRANCH
wip/rae

REVISION DETAIL
https://phabricator.haskell.org/D3754

AFFECTED FILES
compiler/ghci/RtClosureInspect.hs
compiler/typecheck/Inst.hs
compiler/typecheck/TcArrows.hs
compiler/typecheck/TcErrors.hs
compiler/typecheck/TcExpr.hs
compiler/typecheck/TcHsType.hs
compiler/typecheck/TcMType.hs
compiler/typecheck/TcPat.hs
compiler/typecheck/TcRnTypes.hs
compiler/typecheck/TcSigs.hs
compiler/typecheck/TcSplice.hs
compiler/typecheck/TcSplice.hs-boot
compiler/typecheck/TcTyClsDecls.hs
compiler/typecheck/TcType.hs
compiler/typecheck/TcUnify.hs
compiler/typecheck/TcUnify.hs-boot
compiler/types/Type.hs
testsuite/tests/indexed-types/should_fail/T12867.stderr
testsuite/tests/polykinds/T12593.stderr
testsuite/tests/polykinds/T6039.stderr
testsuite/tests/polykinds/T7278.stderr
testsuite/tests/polykinds/T8616.stderr
testsuite/tests/polykinds/T9200b.stderr
testsuite/tests/rename/should_fail/rnfail026.stderr
testsuite/tests/th/T3177a.stderr
testsuite/tests/typecheck/should_fail/T11356.stderr
testsuite/tests/typecheck/should_fail/T11672.stderr
testsuite/tests/typecheck/should_fail/T12785b.stderr
testsuite/tests/typecheck/should_fail/T13819.hs
testsuite/tests/typecheck/should_fail/T13819.stderr
testsuite/tests/typecheck/should_fail/T2994.stderr
testsuite/tests/typecheck/should_fail/T3540.stderr
testsuite/tests/typecheck/should_fail/T4875.stderr
testsuite/tests/typecheck/should_fail/T7609.stderr
testsuite/tests/typecheck/should_fail/T7778.stderr
testsuite/tests/typecheck/should_fail/all.T
testsuite/tests/typecheck/should_fail/tcfail070.stderr
testsuite/tests/typecheck/should_fail/tcfail078.stderr
testsuite/tests/typecheck/should_fail/tcfail113.stderr
testsuite/tests/typecheck/should_fail/tcfail123.stderr
testsuite/tests/typecheck/should_fail/tcfail132.stderr

EMAIL PREFERENCES
https://phabricator.haskell.org/settings/panel/emailpreferences/

To: goldfire, simonpj, austin, bgamari, hvr
Cc: rwbarton, thomie, Mikolaj, fryguybob, carter, mpickering, adamgundry
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Repeated computations under a lambda

[Simon Peyton Jones via ghc-devs]

I opened a ticket and replied:

https://ghc.haskell.org/trac/ghc/ticket/13996#comment:1

Simon



From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Conal Elliott
Sent: 19 July 2017 01:01
To: David Feuer 
Cc: ghc-devs@haskell.org
Subject: Re: Repeated computations under a lambda

Here's the code in question, slightly rephrased:

> exampleC t = \ x -> x + s where s = sin t

I wrote it this way so that `sin t` would be computed once per `t` and reused 
for each value of `x`. The intermediate result `s` has type `Double`---not a 
function. Without `-fno-do-lambda-eta-expansion`, phase 2 of `ghc -O` causes 
the `s = sin t` binding to be moved under the `\ x -> ...`. I've been using 
this programming style for this purpose for longer than I can remember, and 
apparently I've been mistaken about its effectiveness at least part of that 
time.

-- Conal

On Tue, Jul 18, 2017 at 4:52 PM, David Feuer 
> wrote:
On Tuesday, July 18, 2017 3:55:28 PM EDT Conal Elliott wrote:
> Hi Sebastian,
>
> Thanks for the reply. It's that I don't want `exampleC` to be eta-expanded.
> Apparently GHC does by default even when doing so moves computation under
> lambda. I've thought otherwise for a very long time.

GHC really likes to eta-expand, because that can be very good for allocation,
unboxing, and I don't know what else. Do you really need to represent the
intermediate result by a *function*? Would it work just to save the Double
itself? I suspect you could likely convince GHC to leave it alone.

David

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

RE: Proposed: Language.Haskell.TH.Internal

[Simon Peyton Jones via ghc-devs]

OK with me, provided we document the thinking so that users understand the 
architecture.

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard
| Eisenberg
| Sent: 18 July 2017 13:27
| To: GHC developers 
| Cc: Ryan Scott 
| Subject: Proposed: Language.Haskell.TH.Internal
| 
| Hi devs,
| 
| This is a brief proposal for an internal, non-user-facing restructuring
| of the implementation of Template Haskell. It's here (instead of at ghc-
| proposals) because it's not user-facing.
| 
| When a user writes a TH quote [| foo bar baz |], GHC must desugar that
| into some Core code that builds a Q Exp. This is currently done by
| calling functions in Language.Haskell.TH.Lib, which is capable of
| building all the TH abstract syntax. However, many end-users of TH *also*
| import Language.Haskell.TH.Lib and use its functions. This means that, as
| the Haskell AST evolves, we can't reasonably evolve this Lib module, as
| it breaks user code. (There is a requisite amount of churn in TH, but we
| try to avoid gratuitous changes in Lib.) This has bitten in the past when
| we have, say, changed the representation of type families to accommodate
| closed type families, and it's biting now as we (ahem, Ryan Scott) are
| trying to merge types and kinds in TH.
| 
| I thus propose a new module Language.Haskell.TH.Internal. This will start
| out as a slimmed-down copy of Lib (slimmed-down because Lib already has a
| bunch of now-disused functions) but may evolve independently. Desugaring
| quotes will go via this new Internal module, and we will have no qualms
| about changing its interface, as it's Internal.
| 
| What do we think? Ryan has already implemented this idea in D3751.
| 
| Pros:
|  - Flexibility
|  - Separation between user-facing interface and internal interface
| 
| Cons:
|  - More stuff
|  - We already break the TH API with every release; maybe it's not so bad
| to break more of it.
| 
| Thanks,
| Richard
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=02%7C01%7Csimonpj%40microsoft.com%7Cc77c4285ceef48c4783608d4cdd
| 8ab70%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636359777860344686
| ta=TxVVdCy2qEpZnbWDiaPOajm14EivqRDTZdIDVVIax3M%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Simon's (lack of) input

[Simon Peyton Jones via ghc-devs]

Friends
My GHC inbox has grown to alarming proportions.  I try to keep abreast of 
tickets where I think I have something substantial contribute, and generally 
succeed, but I've been failing badly in the last few weeks because of a storm 
of other commitments.
I'll get back to it, but probably not before my summer holiday 3-17 August.   
Meanwhile if you are stalled awaiting input from me, please feel free to ping 
me about it.
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Compilation time

[Simon Peyton Jones via ghc-devs]

Thanks Gael.

As you may know, we’ve focused a lot on compile time in the last year or so, 
and 8.4 is a lot faster.  I think there are still plenty of bad cases, but 
things are better.

Our compile-time perf page is here: 
https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler

It links to a list of open perf tickets: 
https://ghc.haskell.org/trac/ghc/query?status=!closed=Compile-time+performance+bug

What helps above all are reproducible test cases.  Package X compiles much more 
slowly with 8.2 than with 7.10, say.   You did exactly that, thank you – can 
you open a ticket explaining exactly how to reproduce it, and what measurements 
you took.  (Matthew’s numbers seemed two orders of magnitude different; I 
wonder why?)

Another thing that is really helpful is people who characterise what the 
problem is:

  *   Is GHC generating a lot more code?   -dshow-passes can reveal this.
  *   Is it GHC at all, or is it link-times, or some other part of the tool 
chain?
  *   If it is GHC, and the output of compilation is no bigger than before, 
where is the time going?  -dshow-passes gives a rough idea of that too.
  *   Is there a particular characteristic of the program that seems to trigger 
the poor behaviour?  Can you accentuate that characteristic to make it behave 
wildly badly?

Everyone: GHC is your compiler!  We need your help.

Simon


From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Deest, Gaël
Sent: 04 July 2017 08:17
To: ghc-devs@haskell.org
Cc: Manuel Chakravarty 
Subject: Compilation time

Hi all,
As you are probably well aware, GHC performance has been a growing concern over 
the last few years. Many Haskell programmers complain that build time has 
significantly increased over the last few releases. However, to our knowledge, 
there isn't much data available to substantiate this claim and the severity of 
these problems is not well known.
That's why we would like to bring some anecdotal evidence to your attention 
that seems to indicate really major performance regressions. We stumbled upon 
the CI of the data-reify package, which is built against all GHC releases since 
2010 :

https://travis-ci.org/ku-fpg/data-reify
tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC 8.2. 
The 8.2 release alone seems to have increased compilation time by almost 2 
minutes, with the current development branch bringing only minor performance 
improvements.
Of course, this single data point is not sufficient to establish how severe and 
widespread these problems are. More data could probably be gathered from other 
packages. However, it certainly matches our (subjective) experience and we felt 
important to report it to you.
Regards,

--
Gaël Deest
Tweag I/O
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Which stable GHC release is expected to have support for linear types?

[Simon Peyton Jones via ghc-devs]

Wolfgang

It'd be very interesting to know more about your use-case.  Why do you want 
linear types?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Wolfgang Jeltsch
|  Sent: 30 June 2017 14:49
|  To: ghc-devs@haskell.org
|  Subject: Which stable GHC release is expected to have support for
|  linear types?
|  
|  Hi!
|  
|  The blog post on http://blog.tweag.io/posts/2017-03-13-linear-
|  types.html
|  says, “We are targeting a merge by the time of the 8.4 release of
|  GHC.”
|  Does this mean that GHC 8.4 is expected to have support for linear
|  types, or does it mean that the merge should happen after a GHC 8.4
|  branch has been forked off from the HEAD branch, so that only GHC 8.6
|  will have support for linear types?
|  
|  All the best,
|  Wolfgang
|  ___
|  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: Which stable GHC release is expected to have support for linear types?

[Simon Peyton Jones via ghc-devs]

And, just to be clear, while I think the design is coming along nicely, we have 
not yet made a clear proposal to the ghc-devs community, via the ghc-proposals 
mechanism, for a change to GHC.   Until we have an adopted propsoal we can't 
say "it'll be in GHC by date X".

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Boespflug, Mathieu
|  Sent: 30 June 2017 15:02
|  To: Wolfgang Jeltsch 
|  Cc: Arnaud Spiwack ; ghc-devs 
|  Subject: Re: Which stable GHC release is expected to have support for
|  linear types?
|  
|  Hi Wolfgang,
|  
|  8.4 is the next release after the (by now imminent) 8.2 release. But
|  no support for linear types has of yet been merged into the master
|  branch that will eventually form the basis of the 8.4 release. This
|  support is under active development at the moment on a side branch.
|  Some of us are giving ourselves the 8.4 release as a *tentative*
|  target, so don't count on it. It may well end up happening much
|  further in the future. It's a research effort at this point and the
|  design is likely to change a bunch.
|  
|  In the meantime, you can play around with this Docker image:
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhub.d
|  ocker.com%2Fr%2Ftweag%2Flinear-
|  types%2F=02%7C01%7Csimonpj%40microsoft.com%7C0f0fa7d2181b498882bd
|  08d4bfc0b5c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636344281789
|  392239=aWCyABYfJdvkxZAVk4wD5IuErCPTYGvdFO22nbT8gYw%3D=0
|  
|  It contains a pre-built fork of GHC with the current state of the
|  linear types implementation. You can see the development as it's
|  happening here:
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Ftweag%2Fghc%2Ftree%2Flinear-
|  types=02%7C01%7Csimonpj%40microsoft.com%7C0f0fa7d2181b498882bd08d
|  4bfc0b5c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636344281789392
|  239=IGDxDD1q%2BxTRK%2FFwS0C%2BsDEpwFzbzHja4sF3twlF55c%3D
|  d=0
|  
|  Best,
|  --
|  Mathieu Boespflug
|  Founder at
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftweag.
|  io=02%7C01%7Csimonpj%40microsoft.com%7C0f0fa7d2181b498882bd08d4bf
|  c0b5c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636344281789392239
|  =qXdzC81GzESKMHKCykOyM75XrPRbFL8edpsxKKv5VVQ%3D=0.
|  
|  
|  On 30 June 2017 at 15:49, Wolfgang Jeltsch 
|  wrote:
|  > Hi!
|  >
|  > The blog post on
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.t
|  > weag.io%2Fposts%2F2017-03-13-linear-
|  types.html=02%7C01%7Csimonpj%
|  >
|  40microsoft.com%7C0f0fa7d2181b498882bd08d4bfc0b5c1%7C72f988bf86f141af9
|  >
|  1ab2d7cd011db47%7C1%7C0%7C636344281789392239=i8wFqX5an5LyuBKQ5Jk
|  > 2q8jUQdb62l72wOj9OX1OoK0%3D=0
|  > says, “We are targeting a merge by the time of the 8.4 release of
|  GHC.”
|  > Does this mean that GHC 8.4 is expected to have support for linear
|  > types, or does it mean that the merge should happen after a GHC 8.4
|  > branch has been forked off from the HEAD branch, so that only GHC
|  8.6
|  > will have support for linear types?
|  >
|  > All the best,
|  > Wolfgang
|  > ___
|  > ghc-devs mailing list
|  > ghc-devs@haskell.org
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csi
|  >
|  monpj%40microsoft.com%7C0f0fa7d2181b498882bd08d4bfc0b5c1%7C72f988bf86f
|  >
|  141af91ab2d7cd011db47%7C1%7C0%7C636344281789392239=5MKuM59nRrrjm
|  > MPMY9%2BPvsR1%2BBAPHDExiCbU%2FlckuGg%3D=0
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7C0f0fa7d2181b498882bd08d4
|  bfc0b5c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363442817893922
|  39=5MKuM59nRrrjmMPMY9%2BPvsR1%2BBAPHDExiCbU%2FlckuGg%3D
|  =0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows broken

[Simon Peyton Jones via ghc-devs]

cc/x86_64-w64-mingw32/6.3.0/include

C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed

C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../include

C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include

End of search list.

GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32)

  compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 
3.1.5-p2, MPC version 1.0.3, isl version 0.15

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: bdbc00c2d895b1ff93d4c2cb4c58b5b1


From: loneti...@gmail.com<mailto:loneti...@gmail.com> 
[mailto:loneti...@gmail.com]
Sent: 29 June 2017 02:38
To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>>; 
ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>>
Subject: RE: Windows broken

Hi Simon,

What happens when you try to compile that simple test with the bundled gcc?

Could you also run it through strace, this will force msys2 not to swallow 
errors from the OS.

Should you get an exception dialog then rm -rf inplace/mingw and rerun 
configure (I assume you’re on a recent revision).

If none of the above give a clue, you could try ./configure 
--enable-distro-toolchain, this will have it skip the bundled GCC
And use any installed by msys2. If this work then try rm’ing the GHC-tarballs 
folder and the inplace/mingw folder and try again
With –enable-tarballs-autodownloads.

Tamar.

From: Simon Peyton Jones via ghc-devs<mailto:ghc-devs@haskell.org>
Sent: Thursday, June 29, 2017 00:35
To: ghc-devs<mailto:ghc-devs@haskell.org>
Subject: Windows broken

Help please!
Suddenly my Windows build has stopped working.   See below.  What should I do?  
I’m totally stuck.
This has never happened before.
I get this:

GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc

checking build system type... x86_64-pc-msys

checking host system type... x86_64-pc-msys

checking target system type... x86_64-pc-msys

Build platform inferred as: x86_64-unknown-mingw32

Host platform inferred as: x86_64-unknown-mingw32

Target platform inferred as: x86_64-unknown-mingw32

GHC build  : x86_64-unknown-mingw32

GHC host   : x86_64-unknown-mingw32

GHC target : x86_64-unknown-mingw32

LLVM target: x86_64-unknown-mingw32

checking for path to top of build tree... C:/code/HEAD

configure: Checking for Windows toolchain tarballs...

configure: Extracting Windows toolchain from archives (may take a while)...

configure: In-tree MingW-w64 tree created

configure: Making in-tree perl tree

configure: In-tree perl tree created

checking whether the C compiler works... no

configure: error: in `/c/code/HEAD':

configure: error: C compiler cannot create executables

See `config.log' for more details
Something wrong with the gcc.exe?  Config.log has this

gcc version 6.3.0 (Rev2, Built by MSYS2 project)

configure:4950: $? = 0

configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5

gcc.exe: error: unrecognized command line option '-V'

gcc.exe: fatal error: no input files

compilation terminated.

configure:4950: $? = 1

configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -qversion >&5

gcc.exe: error: unrecognized command line option '-qversion'; did you mean 
'--version'?

gcc.exe: fatal error: no input files

compilation terminated.

configure:4950: $? = 1

configure:4970: checking whether the C compiler works

configure:4992: C:/code/HEAD/inplace/mingw/bin/gcc.execonftest.c  >&5

configure:4996: $? = 1

configure:5034: result: no

configure: failed program was:

| /* confdefs.h */

| #define PACKAGE_NAME "The Glorious Glasgow Haskell Compilation System"

| #define PACKAGE_TARNAME "ghc-8.3"

| #define PACKAGE_VERSION "8.3"

| #define PACKAGE_STRING "The Glorious Glasgow Haskell Compilation System 8.3"

| #define PACKAGE_BUGREPORT 
"glasgow-haskell-b...@haskell.org<mailto:glasgow-haskell-b...@haskell.org>"

| #define PACKAGE_URL ""

| /* end confdefs.h.  */

|

| int

| main ()

| {

|

|   ;

|   return 0;

| }

configure:5039: error: in `/c/code/HEAD':

configure:5041: error: C compiler cannot create executables


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

RE: Windows broken

[Simon Peyton Jones via ghc-devs]

If I compile a test foo.c I get this

C:/code/HEAD/inplace/mingw/bin/gcc.exe -v foo.c

Using built-in specs.

COLLECT_GCC=C:\code\HEAD\inplace\mingw\bin\gcc.exe

COLLECT_LTO_WRAPPER=C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe

Target: x86_64-w64-mingw32

Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include 
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada 
--enable-shared --enable-static --enable-libatomic --enable-threads=posix 
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes 
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check 
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release 
--disable-rpath --disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 
--with-pkgversion='Rev2, Built by MSYS2 project' 
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld

Thread model: posix

gcc version 6.3.0 (Rev2, Built by MSYS2 project)

COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'

C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe 
-quiet -v -iprefix 
C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ 
-D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase 
foo -version -o C:\Users\simonpj\AppData\Local\Temp\ccHvaSrL.s

/c/tmp$

So apparently the last line fails.  Running that by itself I get

C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe  -v 
-iprefix C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ 
-D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase 
foo -version -o foo.s

C:/code/HEAD/inplace/mingw/lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe: error 
while loading shared libraries: libwinpthread-1.dll: cannot open shared object 
file: No such file or directory

/c/tmp$
So it can’t find that DLL.  But it exists all right

/c/code/HEAD$ find inplace/mingw -name 'libwinpthread-1.dll'

inplace/mingw/bin/libwinpthread-1.dll

The same thing happens, but with a popup alert window, if I use ‘strace gcc …’.

What now?

Simon

From: loneti...@gmail.com [mailto:loneti...@gmail.com]
Sent: 29 June 2017 02:38
To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs <ghc-devs@haskell.org>
Subject: RE: Windows broken

Hi Simon,

What happens when you try to compile that simple test with the bundled gcc?

Could you also run it through strace, this will force msys2 not to swallow 
errors from the OS.

Should you get an exception dialog then rm -rf inplace/mingw and rerun 
configure (I assume you’re on a recent revision).

If none of the above give a clue, you could try ./configure 
--enable-distro-toolchain, this will have it skip the bundled GCC
And use any installed by msys2. If this work then try rm’ing the GHC-tarballs 
folder and the inplace/mingw folder and try again
With –enable-tarballs-autodownloads.

Tamar.

From: Simon Peyton Jones via ghc-devs<mailto:ghc-devs@haskell.org>
Sent: Thursday, June 29, 2017 00:35
To: ghc-devs<mailto:ghc-devs@haskell.org>
Subject: Windows broken

Help please!
Suddenly my Windows build has stopped working.   See below.  What should I do?  
I’m totally stuck.
This has never happened before.
I get this:

GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc

checking build system type... x86_64-pc-msys

checking host system type... x86_64-pc-msys

checking target system type... x86_64-pc-msys

Build platform inferred as: x86_64-unknown-mingw32

Host platform inferred as: x86_64-unknown-mingw32

Target platform inferred as: x86_64-unknown-mingw32

GHC build  : x86_64-unknown-mingw32

GHC host   : x86_64-unknown-mingw32

GHC target : x86_64-unknown-mingw32

LLVM target: x86_64-unknown-mingw32

checking for path to top of build tree... C:/code/HEAD

configure: Checking for Windows toolchain tarballs...

configure: Extracting Windows toolchain from archives (may take a while)...

configure: In-tree MingW-w64 tree created

configure: Making in-tree perl tree

configure: In-tree perl tree created

checking whether the C compiler works... no

configure: error: in `/c/code/HEAD':

configure: error: C compiler cannot create executables

See `config.log' for more details
Something wrong with the gcc.exe?  Config.log has this

gcc version 6.3.0 (Rev2, Built by MSYS2 project)

configure:4950: $? = 0

configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5

gcc.exe: error: unrecognized command line option '-V'

gcc.exe: fatal error: no input files

compilation term

Windows broken

[Simon Peyton Jones via ghc-devs]

Help please!
Suddenly my Windows build has stopped working.   See below.  What should I do?  
I'm totally stuck.
This has never happened before.
I get this:

GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc

checking build system type... x86_64-pc-msys

checking host system type... x86_64-pc-msys

checking target system type... x86_64-pc-msys

Build platform inferred as: x86_64-unknown-mingw32

Host platform inferred as: x86_64-unknown-mingw32

Target platform inferred as: x86_64-unknown-mingw32

GHC build  : x86_64-unknown-mingw32

GHC host   : x86_64-unknown-mingw32

GHC target : x86_64-unknown-mingw32

LLVM target: x86_64-unknown-mingw32

checking for path to top of build tree... C:/code/HEAD

configure: Checking for Windows toolchain tarballs...

configure: Extracting Windows toolchain from archives (may take a while)...

configure: In-tree MingW-w64 tree created

configure: Making in-tree perl tree

configure: In-tree perl tree created

checking whether the C compiler works... no

configure: error: in `/c/code/HEAD':

configure: error: C compiler cannot create executables

See `config.log' for more details
Something wrong with the gcc.exe?  Config.log has this

gcc version 6.3.0 (Rev2, Built by MSYS2 project)

configure:4950: $? = 0

configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5

gcc.exe: error: unrecognized command line option '-V'

gcc.exe: fatal error: no input files

compilation terminated.

configure:4950: $? = 1

configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -qversion >&5

gcc.exe: error: unrecognized command line option '-qversion'; did you mean 
'--version'?

gcc.exe: fatal error: no input files

compilation terminated.

configure:4950: $? = 1

configure:4970: checking whether the C compiler works

configure:4992: C:/code/HEAD/inplace/mingw/bin/gcc.execonftest.c  >&5

configure:4996: $? = 1

configure:5034: result: no

configure: failed program was:

| /* confdefs.h */

| #define PACKAGE_NAME "The Glorious Glasgow Haskell Compilation System"

| #define PACKAGE_TARNAME "ghc-8.3"

| #define PACKAGE_VERSION "8.3"

| #define PACKAGE_STRING "The Glorious Glasgow Haskell Compilation System 8.3"

| #define PACKAGE_BUGREPORT "glasgow-haskell-b...@haskell.org"

| #define PACKAGE_URL ""

| /* end confdefs.h.  */

|

| int

| main ()

| {

|

|   ;

|   return 0;

| }

configure:5039: error: in `/c/code/HEAD':

configure:5041: error: C compiler cannot create executables
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thank you

[Simon Peyton Jones via ghc-devs]

Ryan
I wanted to thank you for all the work you are putting into GHC at the moment.

  *   You often produce nice small repro cases from other people's bug reports
  *   you often bisect to the patch caused the bug;
  *   your analysis is usually spot on;
  *   you are actively maintaining the generics stuff
  *   you contribute fixes
In short, terrific.  Thank you!
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

hoopl dependency

[Simon Peyton Jones via ghc-devs]

Devs,
Matko (an intern here at MSR) says
Matko Bosnjak 19:02:
Hi Simon,
There's a 'bug' in some of the latest commits of ghc on git. When running
./build

I get:

Error: libraries/hoopl/LICENSE doesn't exist.
Maybe you haven't done 'git submodule update --init'? at ./boot line 112, 
 line 54.

Someone removed the dependency on hoopl library, but hasn't removed it from the 
'packages' file.

What should he do?
Simon

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

#13804

[Simon Peyton Jones via ghc-devs]

Ben
I've just pushed a fix to Trac #13804.  It may belong on the 8.2 branch too 
because it fixes a regression wrt 8.0.
I can't test on my Unix box, because I'm away from it for a few days, but I've 
validated on windows.  Can you just check it's ok, and fix up or revert if not?
Thanks
SImon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC's module hierarchy

[Simon Peyton Jones via ghc-devs]

Dear ghc-devs
hsyl20 proposes a radical overhaul of the module structure of GHC itself.  He 
or she suggested it six months ago in
 https://ghc.haskell.org/trac/ghc/ticket/13009
and has now offered a monster patch
   https://phabricator.haskell.org/D3647
It's clearly the result of a lot of work, but I was the only one who responded 
on the original ticket, and it'll affect all of your lives in a very immediate 
way.
So, would you like to

*consider the idea

*look at the actual re-mapping of modules hsyl20 proposals

*express an opinion about whether to go ahead
Probably the ticket, rather than Phab, is the best place to comment on the 
general idea.
I'd like to thank hsyl20.  GHC's rather flat module structure has grown 
incrementally over years.
But still, there are pros and cons.
Simon
___
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]

Speaking of which, what policies are there on bringing in new dependencies to 
GHC, both compile-time and run-time (e.g. possible SMT solver support)?

We don’t have a formal policy, but we are generally reluctant to take on new 
dependencies.   For SMT solvers, Iavor is using one via a typechecker plugin.

Simon

From: Sophie Taylor [mailto:sop...@traumapony.org]
Sent: 12 June 2017 09:50
To: Simon Peyton Jones ; Michal Terepeta 
; ghc-devs 
Cc: Kavon Farvardin 
Subject: Re: Removing Hoopl dependency?

I don't see why not, other than possible duplication of effort when it comes to 
some of the basic algorithms.

Speaking of which, what policies are there on bringing in new dependencies to 
GHC, both compile-time and run-time (e.g. possible SMT solver support)?



On Mon, 12 Jun 2017 at 17:07 Simon Peyton Jones 
> wrote:
Interesting!

Maybe there are a couple of different alternatives:


A.  A rewrite of Hoopl, with all the same basic ideas and data structures, 
but with a better API (I’m not sure exactly in what way, but Michael has some 
idea, as does Sophie), and a more efficient implementation.

B.  A more radical change to use hypergraphs, type-level lists etc.   This 
sounds interesting, but it’s a more substantial change and before using it for 
GHC we’d need to discuss the new proposed API in some detail

There’s no reason we couldn’t do (A) and (B) in parallel.

Michael is suggesting doing (A) in GHC’s tree, but with a clearly-declared 
intent to bring it out as a separate library.   (I’d advocate making it a 
separate library in GHC’s tree; we already have a number of those.

That would leave Sophie free to do (B) free of the constraints of GHC depending 
on it; but we could always use it later.

Does that sound plausible?  Do we know of any other Hoopl users?

Simon

From: Sophie Taylor [mailto:sop...@traumapony.org]
Sent: 11 June 2017 14:09
To: Michal Terepeta 
>; Simon Peyton 
Jones >; ghc-devs 
>

Cc: Kavon Farvardin >
Subject: Re: Removing Hoopl dependency?

Hello, fellow workers!

So, I'll pop in here with my thoughts.

I'm writing an independent intermediate language library for functional 
languages, and I looked at using Hoopl. I would use it, but there are several 
reasons why I'm not currently doing so:

1) Combining facts from different domains through fancy lattice algorithms. 
This is fairly straightforward to add to Hoopl with minimal extra API change.

2) I wanted to write my data facts as a type-level list, `freer-effects` style, 
in order to be more explicit in my types about dependencies between analyses. 
This would require significantly altering the API.

3) Its own custom graph code. This is the biggest reason why I decided not to. 
Some problems:
  * It seems impossible to change the topology of the graph in a rewriting step.
  * I wanted to use term hypergraphs/hyperjungles due to some pretty nifty 
properties
  * The intermediate language I'm implementing, a derivative of Graph Reduction 
Intermediate Notation, aka GRIN from UHC, is, as its name implies, 
intrinsically graph-based. Thus, graph manipulation has to be pretty easy to do.

So instead, I've decided to optimise another hypergraph library 
(`graph-rewriting` - I'm going to be rewriting it to use an inductive 
representation a la FGL)  and implement a generic, Hoopl-esque analysis library 
on top of that. (Or more accurately, that is my plan for the next six months - 
I've been sidetracked getting parsing to work nice with an effect-based stack!)

So, if Hoopl2 does become a thing, I'd be very keen on working on it, but if I 
were to actually use it myself, it'd probably require a complete rewrite. 
Fortunately, it's a pretty small library; and for GHC, its current usage is a 
pretty straightforward usecase which shouldn't be affected too much. That being 
said, if GHC were to better use Hoopl (e.g. moving some of the optimisations on 
Core to be Hoopl-based passes) then it would be a different story.

So I guess I'm volunteering to do the rewrite for a potential Hoopl2 if it's 
wanted, as I'm about to do pretty much that anyway.

Cheers,
Sophie



On Fri, 9 Jun 2017 at 22:31 Michal Terepeta 
> wrote:
> On Fri, Jun 9, 2017 at 9:50 AM Simon Peyton Jones 
> > wrote:
> > Maybe this is the core of our disagreement - why is it a good idea to have 
> > Hoopl as a separate package in the first place?
>
>
> One reason only: because it makes Hoopl usable by compilers other than GHC.  
> And, dually, efforts by others to 

RE: Removing Hoopl dependency?

[Simon Peyton Jones via ghc-devs]

Interesting!

Maybe there are a couple of different alternatives:


A.  A rewrite of Hoopl, with all the same basic ideas and data structures, 
but with a better API (I’m not sure exactly in what way, but Michael has some 
idea, as does Sophie), and a more efficient implementation.

B.  A more radical change to use hypergraphs, type-level lists etc.   This 
sounds interesting, but it’s a more substantial change and before using it for 
GHC we’d need to discuss the new proposed API in some detail

There’s no reason we couldn’t do (A) and (B) in parallel.

Michael is suggesting doing (A) in GHC’s tree, but with a clearly-declared 
intent to bring it out as a separate library.   (I’d advocate making it a 
separate library in GHC’s tree; we already have a number of those.

That would leave Sophie free to do (B) free of the constraints of GHC depending 
on it; but we could always use it later.

Does that sound plausible?  Do we know of any other Hoopl users?

Simon

From: Sophie Taylor [mailto:sop...@traumapony.org]
Sent: 11 June 2017 14:09
To: Michal Terepeta ; Simon Peyton Jones 
; ghc-devs 
Cc: Kavon Farvardin 
Subject: Re: Removing Hoopl dependency?

Hello, fellow workers!

So, I'll pop in here with my thoughts.

I'm writing an independent intermediate language library for functional 
languages, and I looked at using Hoopl. I would use it, but there are several 
reasons why I'm not currently doing so:

1) Combining facts from different domains through fancy lattice algorithms. 
This is fairly straightforward to add to Hoopl with minimal extra API change.

2) I wanted to write my data facts as a type-level list, `freer-effects` style, 
in order to be more explicit in my types about dependencies between analyses. 
This would require significantly altering the API.

3) Its own custom graph code. This is the biggest reason why I decided not to. 
Some problems:
  * It seems impossible to change the topology of the graph in a rewriting step.
  * I wanted to use term hypergraphs/hyperjungles due to some pretty nifty 
properties
  * The intermediate language I'm implementing, a derivative of Graph Reduction 
Intermediate Notation, aka GRIN from UHC, is, as its name implies, 
intrinsically graph-based. Thus, graph manipulation has to be pretty easy to do.

So instead, I've decided to optimise another hypergraph library 
(`graph-rewriting` - I'm going to be rewriting it to use an inductive 
representation a la FGL)  and implement a generic, Hoopl-esque analysis library 
on top of that. (Or more accurately, that is my plan for the next six months - 
I've been sidetracked getting parsing to work nice with an effect-based stack!)

So, if Hoopl2 does become a thing, I'd be very keen on working on it, but if I 
were to actually use it myself, it'd probably require a complete rewrite. 
Fortunately, it's a pretty small library; and for GHC, its current usage is a 
pretty straightforward usecase which shouldn't be affected too much. That being 
said, if GHC were to better use Hoopl (e.g. moving some of the optimisations on 
Core to be Hoopl-based passes) then it would be a different story.

So I guess I'm volunteering to do the rewrite for a potential Hoopl2 if it's 
wanted, as I'm about to do pretty much that anyway.

Cheers,
Sophie



On Fri, 9 Jun 2017 at 22:31 Michal Terepeta 
> wrote:
> On Fri, Jun 9, 2017 at 9:50 AM Simon Peyton Jones 
> > wrote:
> > Maybe this is the core of our disagreement - why is it a good idea to have 
> > Hoopl as a separate package in the first place?
>
>
> One reason only: because it makes Hoopl usable by compilers other than GHC.  
> And, dually, efforts by others to improve Hoopl will benefit GHC.
>
> > If I proposed extracting parts of Core optimizer to a separate package, 
> > wouldn't you expect some really good reasons for doing this?
>
>
> A re-usable library should be
> a)  a significant chunk of code,
> b)  that can plausibly be re-purposed by others
> c)  and that has an explicable API
>
> I think the Core optimiser is so big, and so GHC specific, that (b) and (c) 
> are unlikely to hold.  But we carefully designed Hoopl from the ground up so 
> that it was agnostic about the node types, and so can be re-used for control 
> flow graphs of many kinds.  It’s designed to be re-usable.  Whether it is 
> actually re-used is another matter, of course.  But if it’s part of GHC, it 
> can’t be.

I agree with your characterization of a re-usable library and that
Core optimizer would not be a good fit. But I do think that Hoopl also
has some problems with b) and c) (although smaller):
- Using an optimizer-as-a-library is not really common (I'm not aware
  of any compilers doing this, LLVM is to some degree close but it
  exposes the whole language as the interface so 

RE: 8.2.1-rc2 upgrade report

[Simon Peyton Jones via ghc-devs]

Great.   Could you put all this into a Trac ticket?

Thanks!

Simon

From: Alberto Valverde [mailto:albe...@toscat.net]
Sent: 08 June 2017 13:57
To: Simon Peyton Jones 
Cc: GHC users 
Subject: Re: 8.2.1-rc2 upgrade report

Hi Simon,

Thanks for the pointer. I re-did both builds with -dshow-passes and made a 
small script to plot the results of the lines which summarize the elapsed time 
and allocated memory per phase and module. I've uploaded the raw logs, a plot 
of the results and the script I wrote to generate it to 
https://gist.githubusercontent.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e.

The plotted results live here 
https://gist.githubusercontent.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e/raw/8996644707fc5c18c1d42ad43ee31b1817509384/bench.png

Apparently, the biggest slowdown in respect to 8.0.2 seems to occur in the 
SpecConstr and Simplifier passes in the Propag (where the "main" function is) 
and the Sigym4.Propag.Engine (where the main algorithm lives) modules.

Any other tests that would be helpful for me to run? I'm not sure where to 
start to create a reproducible case but I'll see if I can come up with 
something soon...

Alberto

On Tue, Jun 6, 2017 at 1:58 PM, Simon Peyton Jones 
> wrote:
Thanks for the report.

Going from 67G to 56G allocation is a very worthwhile improvement in runtime!  
Hurrah.

However, trebling compile time is very bad.  It is (I think) far from typical: 
generally 8.2 is faster at compiling than 8.0 so you must be hitting something 
weird.  Anything you can do to make a reproducible case would be helpful.  
-dshow-passes shows the size of each intermediate form, which at least 
sometimes shows where the big changes are.

Simon

From: Glasgow-haskell-users 
[mailto:glasgow-haskell-users-boun...@haskell.org]
 On Behalf Of Alberto Valverde
Sent: 06 June 2017 12:39
To: GHC users 
>
Subject: 8.2.1-rc2 upgrade report

Hi,

I've finally managed to upgrade all the dependencies of the proprietary app I 
mentioned some days ago in this list and there are good and bad differences 
I've noticed between 8.0.2 that I'd like to share.

The bad
---

* An optimized cold build (-O2)  is about 3 times slower (~53s vs. ~2m55s) and 
consumes more memory (~2Gb vs. ~7Gb) at it's peak.

The good
-

* An un-optimized cold build (-O0) takes about the same time (~21s, phew! :) 
It's maybe even slightly faster with 8.2 (too few and badly taken measurements 
to really know, though)
* The optimized executable is slightly faster and allocates less memory. For 
this app it makes up for the performance regression of the optimized build 
(which is almost always done by CI), IMHO.

I did only a couple of runs and only wrote down [1] the last run results (which 
were similar to the previous results) so take these observations with a grain 
of salt (except maybe the optimized build slowdown, which doesn't have much 
margin for variance to be skewing the results). I also measured the peak memory 
usage by observing "top".

In case gives a clue: The app is a multi-threaded 2D spread simulator which 
deals with many mmapped Storable mutable vectors and has been pretty optimized 
for countless hours (I mean by this that it has (too) many INLINE pragmas. 
Mostly on polymorphic functions to aid in their specialization). I think some 
of this information can be deduced from the results I'm linking at the footer. 
I believe the INLINEs are playing a big part of the slowdown since the slowest 
modules to compile are the "Main" ones which put everything together, along 
with the typical lens-th-heavy "Types" ones.

I'd like to help by producing a reproducible and isolated benchmark or a better 
analysis or ... so someone more knowledgeable than me on GHC internals can 
someday hopefully attack the regression. Any pointers on what would help and 
where can I learn to do it?

Thanks!


[1] 

RE: Removing Hoopl dependency?

[Simon Peyton Jones via ghc-devs]

Maybe this is the core of our disagreement - why is it a good idea to have 
Hoopl as a separate package in the first place?

One reason only: because it makes Hoopl usable by compilers other than GHC.  
And, dually, efforts by others to improve Hoopl will benefit GHC.

If I proposed extracting parts of Core optimizer to a separate package, 
wouldn't you expect some really good reasons for doing this?

A re-usable library should be

a)  a significant chunk of code,

b)  that can plausibly be re-purposed by others

c)  and that has an explicable API

I think the Core optimiser is so big, and so GHC specific, that (b) and (c) are 
unlikely to hold.  But we carefully designed Hoopl from the ground up so that 
it was agnostic about the node types, and so can be re-used for control flow 
graphs of many kinds.  It’s designed to be re-usable.  Whether it is actually 
re-used is another matter, of course.  But if it’s part of GHC, it can’t be.

Stackage only allows one version of each package

I didn’t know that, but I can see it makes sense.  That makes a strong case for 
re-doing it as a new package hoopl2, if the API needs to change substantially 
(something we have yet to discuss).

I've pointed multiple reasons why I think it has a significant cost.
Can you just summarise them again briefly for me?  If we are free to choose 
nomenclature and API for hoopl2, I’m not yet seeing why making it a separate 
package is harder than not doing so. E.g. template-haskell is a separate 
package.

Thanks!

Simon



From: Michal Terepeta [mailto:michal.terep...@gmail.com]
Sent: 08 June 2017 19:59
To: Simon Peyton Jones ; ghc-devs 
Cc: Kavon Farvardin 
Subject: Re: Removing Hoopl dependency?

> On Wed, Jun 7, 2017 at 7:05 PM Simon Peyton Jones 
> > wrote:
> Michael
>
> Sorry to be slow.
>
> > Note that what I’m actually advocating is to *finish* forking Hoopl. The
> > fork really started in ~2012 when the “new Cmm backend” was being
> > finished.
>
> Yes, I know.  But what I’m suggesting is to revisit the reasons for that 
> fork, and re-join if possible.  Eg if Hoopl is too slow, can’t we make it 
> faster?  Why is GHC’s version faster?
>
> > apart from the performance
> > (as noted above), there’s the issue of Hoopl’s interface. IMHO the
> > node-oriented approach taken by Hoopl is both not flexible enough and it
> > makes it harder to optimize it. That’s why I’ve already changed GHC’s
> > `Hoopl.Dataflow` module to operate “block-at-a-time”
>
> Well that sounds like an argument to re-engineer Hoopl’s API, rather an 
> argument to fork it.  If it’s a better API, can’t we make it better for 
> everyone?  I don’t yet understand what the “block-oriented” API is, or how it 
> differs, but let’s have the conversation.

Sure, but re-engineering the API of a publicly use package has significant
cost for everyone involved:
- GHC: we might need to wait longer for any improvements and spend
  more time discussing various options (and compromises - what makes
  sense for GHC might not make sense for other people)
- Hoopl users: will need to migrate to the new APIs potentially
  multiple times
- Hoopl maintainers: might need to maintain more than one branches of
  Hoopl for a while

And note that just bumping a version number might not be enough.  IIRC
Stackage only allows one version of each package and since Hoopl is a
boot package for GHC, the new version will move to Stackage along with
GHC. So any users of Hoopl that want to use the old package, will not
be able to use that version of Stackage.

> > When you say
> > that we should “just fix Hoopl”, it sounds to me that we’d really need
> > to rewrite it from scratch. And it’s much easier to do that if we can
> > just experiment within GHC without worrying about breaking other
> > existing Hoopl users
>
> Fine.  But then let’s call it hoopl2, make it a separate package (perhaps 
> with GHC as its only client for now), and declare that it’s intended to 
> supersede hoopl.

Maybe this is the core of our disagreement - why is it a good idea to
have Hoopl as a separate package in the first place?

I've pointed multiple reasons why I think it has a significant cost.
But I don't really see any major benefits. Looking at the commit
history of Hoopl there hasn't been much development on it since 2012
when Simon M was trying to get the new GHC backend working (since
then, it's mostly maintenance patches to keep up with changes in
`base`, etc).
Extracting a core part of any project to a shared library has some
real costs, so there should be equally real benefits that outweigh
that cost. (If I proposed extracting parts of Core optimizer to a
separate package, wouldn't you expect some really good reasons for
doing this?)
I also do think this is quite different than a dependency on, say,
`binary`, `containers` or `pretty`, where the API of the library is
smaller 

RE: Removing Hoopl dependency?

[Simon Peyton Jones via ghc-devs]

Michael

Sorry to be slow.

Note that what I’m actually advocating is to *finish* forking Hoopl. The
fork really started in ~2012 when the “new Cmm backend” was being
finished.

Yes, I know.  But what I’m suggesting is to revisit the reasons for that fork, 
and re-join if possible.  Eg if Hoopl is too slow, can’t we make it faster?  
Why is GHC’s version faster?

apart from the performance
(as noted above), there’s the issue of Hoopl’s interface. IMHO the
node-oriented approach taken by Hoopl is both not flexible enough and it
makes it harder to optimize it. That’s why I’ve already changed GHC’s
`Hoopl.Dataflow` module to operate “block-at-a-time”

Well that sounds like an argument to re-engineer Hoopl’s API, rather an 
argument to fork it.  If it’s a better API, can’t we make it better for 
everyone?  I don’t yet understand what the “block-oriented” API is, or how it 
differs, but let’s have the conversation.

When you say
that we should “just fix Hoopl”, it sounds to me that we’d really need
to rewrite it from scratch. And it’s much easier to do that if we can
just experiment within GHC without worrying about breaking other
existing Hoopl users

Fine.  But then let’s call it hoopl2, make it a separate package (perhaps with 
GHC as its only client for now), and declare that it’s intended to supersede 
hoopl.

But do we even need to do that much?  After all, a major version bump on a 
package is allowed to introduce breaking changes to the API.  Anyone who wants 
the old API can use the old package.

I wonder if you could start a wiki page somewhere (eg on the GHC wiki) listing 
all the changes you’d like to make in a “rewrite from scratch” story?   That 
would help to “ground”  the conversation.

Thanks

Simon


From: Michal Terepeta [mailto:michal.terep...@gmail.com]
Sent: 29 May 2017 12:53
To: Simon Peyton Jones ; ghc-devs 
Subject: Re: Removing Hoopl dependency?

On Sun, May 28, 2017 at 11:30 PM Simon Peyton Jones 
> wrote:
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

Hi Simon,

Thanks for chiming in! Let me try to clarify the current situation and
the motivation for my changes.

1) Initial fork of Hoopl

Note that what I’m actually advocating is to *finish* forking Hoopl. The
fork really started in ~2012 when the “new Cmm backend” was being
finished.
IIRC the main reason was the unacceptable performance and it seems that
even Simon Marlow had trouble making it run fast enough:
https://plus.google.com/107890464054636586545/posts/dBbewpRfw6R
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance
The end result is pretty sad: GHC has its own forked/specialized
`Hoopl.Dataflow` module and is using Hoopl only for definitions of
`Block`/`Graph` and maps/sets (if you look at my commit, it’s pretty
clear what I’m copying). In particular it’s not using *any* of dataflow
analysis or rewriting capabilities of the Hoopl package.

2) Reasons to finish forking

The reasons I listed in my previous email already assumed the we have
the forked `Hoopl.Dataflow` module in GHC. But if we want to discuss
what are reasons for forking in general, then apart from the 

RE: Trees that Grow in the hsSyn AST

[Simon Peyton Jones via ghc-devs]

| just wondering what led to the decision to start with HsSyn. Are you
| suggesting that Core wouldn't benefit from these ideas? I surely don't

Core, unlike HsSyn, is heavily optimised and transformed.  It's hard to see how 
the transformations could soundly maintain arbitrary auxiliary information.  
Also unlike HsSyn, Core is a very small language, so it's no big deal to 
transform it into something else.


| All right; I figured it wouldn't hurt to ask. May I ask what sorts of
| scaling problems you mean?

Simply maintaining a finite map from binders to another binder, or arbitrary 
other info (eg strictness) can be challenging.  Try it!

Simon

| -Original Message-
| From: David Feuer [mailto:da...@well-typed.com]
| Sent: 30 May 2017 22:06
| To: Simon Peyton Jones 
| Cc: Alan & Kim Zimmerman ; ghc-devs@haskell.org
| Subject: Re: Trees that Grow in the hsSyn AST
| 
| On Friday, May 26, 2017 9:03:15 AM EDT Simon Peyton Jones wrote:
| > 1. Which is better to start with: HsSyn or Core? Intuition suggests
| this sort of thing could be very helpful for making zapping more reliable
| and ensuring its efficiency, but there may be better reasons to start
| with HsSyn.
| >
| > Definitely HsSyn.  It’s big, riddled with extra info, and has many
| purposes for different people.  Core is small, tight, nailed down.  I
| don’t want to mess with it.
| 
| Don't get me wrong. I wasn't suggesting that Core should come first; I
| have absolutely no basis to make any suggestion in that regard. I was
| just wondering what led to the decision to start with HsSyn. Are you
| suggesting that Core wouldn't benefit from these ideas? I surely don't
| see why not. Information about arity and strictness, at least, is
| introduced in specific compiler phases. I believe that some information
| needed for join points is only valid/available between certain phases.
| Making such things explicit in the types seems like it can only help.
| 
| > 2. If we're making intrusive changes to representations, would now be a
| sensible era to consider switching to a different variable representation
| (unbound, bound, abt, etc)?
| >
| > I don’t think so.  The issues are quite orthogonal, and no one (to my
| knowledge) has proposed any vaguely plausible change to variable bindings
| that would scale to what GHC does.   In contrast, this stuff is “just”
| re-engineering.
| 
| All right; I figured it wouldn't hurt to ask. May I ask what sorts of
| scaling problems you mean?
| 
| David
___
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: HsParTy

[Simon Peyton Jones via ghc-devs]

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.

Simon

From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 26 May 2017 12:14
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Re: HsParTy

When I was working through the ppr to use HsParTy everywhere it was not clear 
whether there were any usages that required maybeParen, so I left it in.
I can try to strip then all out and see what happens.
Alan

On 26 May 2017 at 10:54, Simon Peyton Jones 
> wrote:
Alan
Do you know why HsTypes.ppr_mono_ty contains any uses of ‘maybeParen’?  
Shouldn’t the parens all be put in by HsParTy?
I tripped over this when I mistakenly added what I thought were missing 
maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error by 
a test in tests/printer.
So why are there /any/ maybeParen calls?
Simon

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

RE: Trees that Grow in the hsSyn AST

[Simon Peyton Jones via ghc-devs]

1. Which is better to start with: HsSyn or Core? Intuition suggests this sort 
of thing could be very helpful for making zapping more reliable and ensuring 
its efficiency, but there may be better reasons to start with HsSyn.

Definitely HsSyn.  It’s big, riddled with extra info, and has many purposes for 
different people.  Core is small, tight, nailed down.  I don’t want to mess 
with it.

2. If we're making intrusive changes to representations, would now be a 
sensible era to consider switching to a different variable representation 
(unbound, bound, abt, etc)?

I don’t think so.  The issues are quite orthogonal, and no one (to my 
knowledge) has proposed any vaguely plausible change to variable bindings that 
would scale to what GHC does.   In contrast, this stuff is “just” 
re-engineering.

Simon

From: David Feuer [mailto:da...@well-typed.com]
Sent: 26 May 2017 01:11
To: Simon Peyton Jones <simo...@microsoft.com>; Alan & Kim Zimmerman 
<alan.z...@gmail.com>; ghc-devs@haskell.org
Subject: RE: Trees that Grow in the hsSyn AST

I haven't looked in detail yet, but there seem to be good ideas. I have two 
questions:

1. Which is better to start with: HsSyn or Core? Intuition suggests this sort 
of thing could be very helpful for making zapping more reliable and ensuring 
its efficiency, but there may be better reasons to start with HsSyn.

2. If we're making intrusive changes to representations, would now be a 
sensible era to consider switching to a different variable representation 
(unbound, bound, abt, etc)?


David Feuer
Well-Typed, LLP

 Original message ----
From: Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>>
Date: 5/25/17 6:48 PM (GMT-05:00)
To: Alan & Kim Zimmerman <alan.z...@gmail.com<mailto:alan.z...@gmail.com>>, 
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
Subject: RE: Trees that Grow in the hsSyn AST

Folks

Do take a look at this:


·We propose to re-engineer HsSyn itself.  This will touch a lot of code.

·But it’s very neat, and will bring big long-term advantages

·And we can do it a bit at a time

The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow 
has the details.

It’s entirely an internal change, not a change to GHC’s specification, so it’s 
independent of the GHC proposals process.  But I’d value the opinion of other 
GHC devs.

Alan has done a prototype first step, which worked out rather well.  Rather 
than having
   HsExpr Id
(which we all know means “HsExpr after the typechecker” but tha’s a bit 
inexplicit, we have
   HsExpr GhcTc
meaning “HsExpr after GHC’s Tc pass”.   In some ways this is quite superficial, 
but it unlocks the Trees That Grow machiney.

Please ask questions etc.  Alan and Shayan can record the answers in the wiki.  
I’m inclined to go ahead with this, so yell soon if you disagree.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim 
Zimmerman
Sent: 24 May 2017 22:52
To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
Subject: Trees that Grow in the hsSyn AST

Hi all

You may be aware that Shayan Najd presented the paper  "Trees that Grow"[1] at 
HIW last year.
Based on the following mandate
> As in my previous email to Shayan (attached).  Wiki page, describe goals, 
> design,
> approach.  Point to prototype implementation.  Seek comments.   You can say 
> that
>I am supportive!
>
> Simon

We have set up a Wiki page at [2] describing a prototype implementation of the 
first stage of this for the hsSyn AST, which is to change the polymorphic 
variable from one of RdrName / Name / Id to an index type. This is presented as 
a fabricator diff at [3].
Please take a look and provide feedback.
Regards
  Alan


[1] 
http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jucs.org%2Fjucs_23_1%2Ftrees_that_grow%2Fjucs_23_01_0042_0062_najd.pdf=02%7C01%7Csimonpj%40microsoft.com%7C5faccc0d2d534c42c23e08d4a2ef36d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636312595690311243=fbLJdJqSyXgacCEJwVH880aLsHDgDY46hrc%2FtDXv4VQ%3D=0<http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf%3chttps:/na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jucs.org%2Fjucs_23_1%2Ftrees_that_grow%2Fjucs_23_01_0042_0062_najd.pdf=02%7C01%7Csimonpj%40microsoft.com%7C5faccc0d2d534c42c23e08d4a2ef36d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636312595690311243=fbLJdJqSyXgacCEJwVH880aLsHDgDY46hrc%2FtDXv4VQ%3D=0>>
[2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
[3] https://phabricator.haskell.org/D3609
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs