Re: Birthday greetings

[Christopher Allen]

Happy Birthday! Haskell is all the better for your work and direction and
we've all benefited thereby. Your work has made computing more enjoyable
for many :)

On Mon, Jan 18, 2016 at 6:22 PM, Simon Peyton Jones 
wrote:

> Dear GHC devs (all 600+ of you),
>
> It’s my birthday (well it was a few minutes ago, but I became distracted
> by #11379).   I am 58.  GHC is alive and well and, happily, so am I.
>
> However, of late I have found that my GHC inbox, which I used to be able
> to keep under control, just grows and grows.  Mostly this is good; it
> reflects the fact that GHC has lots of users, that they vigorously expand
> up to (and often well beyond) the limits of what GHC can do, and that
> increasingly GHC a lot of developers contributing actively to its code
> base.
>
> But it has its downsides.   I used to be able to keep up with the Trac and
> email traffic.  Trusty techniques like “delete anything mentioning ‘dynamic
> linking’ or ‘Unicode’” would cut the traffic in half.   But that doesn’t
> work any more.   Too many interesting things are happening.
>
> So this email is to say three things:
>
> · First,* thank you* to the increasingly large number of you who
> are contributing actively to GHC’s development.   GHC is a big system, and
> no one person can be on top of all of it.   GHC no longer depends on one of
> two people: it depends on all of you.  You know who you are – thank you.
>
> · Second,* apologies* to anyone who is stuck waiting for me.
> Although there are large chunks of GHC that I know little about, there are
> other parts that are dear to my heart: the renamer, typechecker, Core,
> optimisation, and so on.  I write code most days and enjoy it.  So I do
> want to continue to play a very active supporting and reviewing role, as
> well as authoring, in these parts.  But I’m conscious that doing so puts me
> in a lot of critical paths.
>
> Here’s a suggestion: if you are blocked on something from me, email me
> directly.   By all means copy ghc-devs if you want others in the
> conversation, but make it clear that you need my input.  That’ll work
> better than putting up a Phab review, or a Trac comment, and hoping I’ll
> see it.  I probably will, but it won’t stick out from other 20 Phab reviews
> that I would like to do.  I don’t promise to turn everything around fast,
> but it’ll increase the chances!
>
> · Third, in a vain attempt to at least keep some kind of handle
> on the state of play, I keep an ill-organised *page of tickets that I’m
> interested in *.
> A cursory glance will confirm that there is zero chance that I will attend
> to them all.So please do pick up some of them and dig in.  Not many are
> trivial; most require some investigation, some design work, some discussion
> of alternatives, etc.  But most of them would benefit from love and
> attention.  If you are looking for suggestions for things to do, that might
> be a good place to start.
>
> Thanks!
>
> Simon
>
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Birthday greetings

[Manuel M T Chakravarty]

Dear Simon!

Happy Birthday!!! :)

Thank you so much for all the incredible work that you have done and the 
guidance that you have provided over the many years. I personally have profited 
enormously from your kindness, and I am very grateful for that. In addition, 
your unwavering enthusiasm for and work on GHC, in particular, and functional 
programming, in general, have always been a great inspiration.

Thank you very much and all the best for this and many more years!!
Manuel

PS: I have declared email defeat long ago. I am impressed that you could keep 
up with it for so long.

> Simon Peyton Jones :
> 
> Dear GHC devs (all 600+ of you),
> 
> It’s my birthday (well it was a few minutes ago, but I became distracted by 
> #11379).   I am 58.  GHC is alive and well and, happily, so am I.
> 
> However, of late I have found that my GHC inbox, which I used to be able to 
> keep under control, just grows and grows.  Mostly this is good; it reflects 
> the fact that GHC has lots of users, that they vigorously expand up to (and 
> often well beyond) the limits of what GHC can do, and that increasingly GHC a 
> lot of developers contributing actively to its code base. 
> 
> But it has its downsides.   I used to be able to keep up with the Trac and 
> email traffic.  Trusty techniques like “delete anything mentioning ‘dynamic 
> linking’ or ‘Unicode’” would cut the traffic in half.   But that doesn’t work 
> any more.   Too many interesting things are happening.
> 
> So this email is to say three things:
> 
> · First, thank you to the increasingly large number of you who are 
> contributing actively to GHC’s development.   GHC is a big system, and no one 
> person can be on top of all of it.   GHC no longer depends on one of two 
> people: it depends on all of you.  You know who you are – thank you.
> 
> · Second, apologies to anyone who is stuck waiting for me.   Although 
> there are large chunks of GHC that I know little about, there are other parts 
> that are dear to my heart: the renamer, typechecker, Core, optimisation, and 
> so on.  I write code most days and enjoy it.  So I do want to continue to 
> play a very active supporting and reviewing role, as well as authoring, in 
> these parts.  But I’m conscious that doing so puts me in a lot of critical 
> paths.
> 
> Here’s a suggestion: if you are blocked on something from me, email me 
> directly.   By all means copy ghc-devs if you want others in the 
> conversation, but make it clear that you need my input.  That’ll work better 
> than putting up a Phab review, or a Trac comment, and hoping I’ll see it.  I 
> probably will, but it won’t stick out from other 20 Phab reviews that I would 
> like to do.  I don’t promise to turn everything around fast, but it’ll 
> increase the chances!
> 
> · Third, in a vain attempt to at least keep some kind of handle on 
> the state of play, I keep an ill-organised page of tickets that I’m 
> interested in .  A 
> cursory glance will confirm that there is zero chance that I will attend to 
> them all.So please do pick up some of them and dig in.  Not many are 
> trivial; most require some investigation, some design work, some discussion 
> of alternatives, etc.  But most of them would benefit from love and 
> attention.  If you are looking for suggestions for things to do, that might 
> be a good place to start.
> 
> Thanks!
> 
> Simon
> 
>  
> 
>  
> 
> ___
> 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

Birthday greetings

[Simon Peyton Jones]

Dear GHC devs (all 600+ of you),
It’s my birthday (well it was a few minutes ago, but I became distracted by 
#11379).   I am 58.  GHC is alive and well and, happily, so am I.
However, of late I have found that my GHC inbox, which I used to be able to 
keep under control, just grows and grows.  Mostly this is good; it reflects the 
fact that GHC has lots of users, that they vigorously expand up to (and often 
well beyond) the limits of what GHC can do, and that increasingly GHC a lot of 
developers contributing actively to its code base.
But it has its downsides.   I used to be able to keep up with the Trac and 
email traffic.  Trusty techniques like “delete anything mentioning ‘dynamic 
linking’ or ‘Unicode’” would cut the traffic in half.   But that doesn’t work 
any more.   Too many interesting things are happening.
So this email is to say three things:

· First, thank you to the increasingly large number of you who are 
contributing actively to GHC’s development.   GHC is a big system, and no one 
person can be on top of all of it.   GHC no longer depends on one of two 
people: it depends on all of you.  You know who you are – thank you.

· Second, apologies to anyone who is stuck waiting for me.   Although 
there are large chunks of GHC that I know little about, there are other parts 
that are dear to my heart: the renamer, typechecker, Core, optimisation, and so 
on.  I write code most days and enjoy it.  So I do want to continue to play a 
very active supporting and reviewing role, as well as authoring, in these 
parts.  But I’m conscious that doing so puts me in a lot of critical paths.

Here’s a suggestion: if you are blocked on something from me, email me 
directly.   By all means copy ghc-devs if you want others in the conversation, 
but make it clear that you need my input.  That’ll work better than putting up 
a Phab review, or a Trac comment, and hoping I’ll see it.  I probably will, but 
it won’t stick out from other 20 Phab reviews that I would like to do.  I don’t 
promise to turn everything around fast, but it’ll increase the chances!

· Third, in a vain attempt to at least keep some kind of handle on the 
state of play, I keep an ill-organised page of tickets that I’m interested 
in.  A cursory 
glance will confirm that there is zero chance that I will attend to them all.   
 So please do pick up some of them and dig in.  Not many are trivial; most 
require some investigation, some design work, some discussion of alternatives, 
etc.  But most of them would benefit from love and attention.  If you are 
looking for suggestions for things to do, that might be a good place to start.
Thanks!
Simon



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

Re: equality relations: user-facing pretty-printing question

[David Fox]

It is better, but you still might write ~~ and see an error message with ~,
right?

On Mon, Jan 18, 2016 at 9:55 AM, Richard Eisenberg 
wrote:

> I like that idea. Do others?
>
> Yes, agreed about the difference between ~ and ~~.
>
> ~# is unlifted, and is now the type that the solver works on. ~~ is
> lifted. That's the only difference. But the fact that ~~ is lifted is what
> allows you to put it in a constraint, because all constraints are lifted.
> Users should never bother with ~#, but they might with ~~.
>
> Richard
>
> On Jan 18, 2016, at 12:52 PM, Iavor Diatchki 
> wrote:
>
> Hello,
>
> What's the difference between `~~` and `~#` (I assume `~#` is
> heterogeneous)?
>
> As for the rest, as far as I understand, `~` is a strict subset of `~~` in
> the sense that:
>   1. if `a ~ b`, then `a ~~ b`
>   2. if `not (a ~ b)`, then `not (a ~~ b)`
>   3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be
> different from the kind of `b`), then `not (a ~~ b)`
>
> So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`:
>
>   if kindOf a == kindOf b then `a ~ b` else `a ~~ b`
>
> -Iavor
>
>
>
>
>
>
>
> On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott 
> wrote:
>
>> In my ideal world, GHC would remember as much as what the user wrote
>> as possible in printing error messages. So if the user writes:
>>
>> f :: Int ~ Char => ...
>>
>> Then GHC would remember that the context was written with a single
>> tilde, and print out Int ~ Char in the error message explicitly
>> wherever the full type signature of f is printed.
>>
>> What it sounds like, though, is that deep in the guts of the type
>> inferencer, there's a chance that single-tilde equality might turn
>> into double-tilde or tilde-hash equality at some point. In those
>> cases, printing out the particular brand of tilde might get confusing.
>> In such cases, we might compromise and print out something neutral
>> like "is equal to". I suppose this would always be the case if you
>> didn't explicitly write a ~ b and had to infer it.
>>
>> I'm not sure about the technical details of this though, i.e., if GHC
>> actually remembers a ~ b all the way through the
>> typechecking/inferencing pipeline.
>>
>> Ryan S.
>> ___
>> 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
>
>
>
> ___
> 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

How to build profiled stage1?

[Ömer Sinan Ağacan]

I'm trying to debug my stage1 compiler and as a last resort I'm trying to build
stage1 compiler using `-prof -fprof-auto` to be able to do `+RTS -xc -RTS`
during the stage2 build.

I tried couple of things but they all failed in different ways.

As far as I understand, both SRC_HC_OPTS and GhcStage1HcOpts are passed to
system-wide installed ghc during the stage1 build and libraries. So I do one of
these changes:

SRC_HC_OPTS= -O -H64m -prof -fprof-auto
GhcStage1HcOpts= -O0 -DDEBUG -prof -fprof-auto

The second change I want to make is I want to pass `+RTS -xc -RTS` to
ghc-stage1, for that I'm making this change:

GhcLibHcOpts   = -O -dcore-lint -prof -fprof-auto

But, no matter what else I change, I can't get past this stage:

"/usr/local/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -O
-H64m  -Wall   -package-db libraries/bootstrapping.conf
-this-package-key ghc-8.1 -hide-all-packages -i -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/stage1/build
-icompiler/stage1/build/autogen -Icompiler/stage1/build
-Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser
-Icompiler/utils -Icompiler/stage1-optP-include
-optPcompiler/stage1/build/autogen/cabal_macros.h -package-id
array-0.5.1.0-960bf9ae8875cc30355e086f8853a049 -package-id
base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d -package-id
binary-0.8.0.0 -package-id
bytestring-0.10.6.0-9a873bcf33d6ce2fd2698ce69e2c1c66 -package-id
containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb -package-id
directory-1.2.2.0-660a7a83a753ed85c8a374c15dae2b97 -package-id
filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id
ghc-boot-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3
-package-id process-1.2.3.0-a22328103774f0499a990653944cbf99
-package-id template-haskell-2.11.0.0 -package-id
time-1.5.0.1-1b9a502bb07a3e6f4d6935fbf9db7181 -package-id
transformers-0.5.0.0 -package-id
unix-2.7.1.0-bb54ee8f9f6b2600aae7a748eb88a610 -Wall
-fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -DSTAGE=1
-Rghc-timing -O0 -DDEBUG -prof -fprof-auto  -no-user-package-db
-rtsopts   -odir compiler/stage1/build -hidir
compiler/stage1/build -stubdir compiler/stage1/build-c
compiler/utils/Exception.hs -o compiler/stage1/build/Exception.o

compiler/utils/Exception.hs:10:1:
Failed to load interface for ‘Control.Monad.IO.Class’
Perhaps you haven't installed the profiling libraries for
package ‘transformers-0.5.0.0’?
Use -v to see a list of the files searched for.
<>

I tried enabling library-profiling in my global Cabal config, but that didn't
help. Any ideas how to do this?

If it matters, I'm on Linux.

NOTE: If I pass -v to GHC, it lists this place in the list of
locations searched:


/home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/build/Control/Monad/IO/Class.p_hi

Indeed, the file is not there. When I look at all the command the build system
run at this point, I see lines like this:

"/usr/local/bin/ghc-pkg" update --force
--package-db=libraries/bootstrapping.conf
libraries/transformers/dist-boot/inplace-pkg-config
Reading package info from
"libraries/transformers/dist-boot/inplace-pkg-config" ... done.
transformers-0.5.0.0: Warning: Unrecognized field abi on line 47
transformers-0.5.0.0: Warning: haddock-interfaces:
/home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/doc/html/transformers/transformers.haddock
doesn't exist or isn't a file
transformers-0.5.0.0: cannot find any of
["Control/Applicative/Backwards.hi","Control/Applicative/Backwards.p_hi","Control/Applicative/Backwards.dyn_hi"]
(ignoring)
transformers-0.5.0.0: cannot find any of
["Control/Applicative/Lift.hi","Control/Applicative/Lift.p_hi","Control/Applicative/Lift.dyn_hi"]
(ignoring)
transformers-0.5.0.0: cannot find any of
["Control/Monad/Signatures.hi","Control/Monad/Signatures.p_hi","Control/Monad/Signatures.dyn_hi"]
(ignoring)
transformers-0.5.0.0: cannot find any of
["Control/Monad/Trans/Class.hi","Control/Monad/Trans/Class.p_hi","Control/Monad/Trans/Class.dyn_hi"]
(ignoring)
transformers-0.5.0.0: cannot find any of
["Control/Monad/Trans/Cont.hi","Control/Monad/Trans/Cont.p_hi","Control/Monad/Trans/Cont.dyn_hi"]
(ignoring)
transformers-0.5.0.0: cannot find any of
["Control/Monad/Trans/Except.hi","Control/Monad/Trans/Except.p_hi","Control/Monad/Trans/Except.dyn_hi"]
(ignoring)
transformers-0.5.0.0: cannot find any of
["Control/Monad/Trans/Error.hi","Control/Monad/Trans/Error.p_hi","Control/Monad/Trans/Error.dyn_hi"]
(ignoring)
trans

Re: Phab failing to apply patches

[Brandon Allbery]

On Mon, Jan 18, 2016 at 12:09 PM, Thomas Miedema 
wrote:

> * you validate locally (in a different build directory, so you can keep
> using build flavour = devel2 in your development directory)
> * fork the ghc github repository, push your branch there, and let Travis
> validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis
>
> * ask Austin for some special Phabricator syntax that you could add when
> you submit the patch, to request Harbormaster not to rebase onto HEAD
> before validating
>

Seems to me that, if Harbormaster is already overloaded, the second option
should be preferred. Offloading from one limited resource (local machine)
to another that is also shared seems like a lose for everyone.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: kind of type equalities (was: equality relations: user-facing pretty-printing question)

[Eric Seidel]

On Mon, Jan 18, 2016, at 10:26, Richard Eisenberg wrote:
> And lifted ones can exist at runtime, via deferred type errors. With
> deferred type errors, a lifted equality might be a thunk that evaluates
> to a type error.

Ah, fair point. 

> I also think that "because Core needs it" is a satisfying answer. That's
> why we have coercions. If we didn't care about type-checking Core, we
> could just omit very large swathes of GHC. But then we'd have a
> non-working compiler. :)

I should have elaborated on why I find it unsatisfying :) 

My point was not that type-checking Core is not desirable enough to
warrant tracking the kind of a type equality, rather that perhaps
there's a simpler way that doesn't include runtime concerns. For
example, perhaps type equalities could have their own kind. But it
sounds like we can't actually separate equalities from code-gen/runtime.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghci and unfoldings?

[Conal Elliott]

The minimum flags I've found to get ghci to provide unfoldings are -O and
-object-code. And it appears that both flags need to be present the first
time I load a module into GHCi. (I'm putting the flags in an OPTIONS_GHC
pragma.)

On Mon, Jan 18, 2016 at 9:46 AM, Conal Elliott  wrote:

> That's the flag I would expect. It doesn't seem to help or hinder
> availability of unfoldings in GHCi. Do you think it should?
>
> And Happy Birthday, Simon!
>
> Warmly, - Conal
>
>
> On Monday, January 18, 2016, Simon Peyton Jones 
> wrote:
>
>> Or -fexpose-all-unfoldings?
>>
>> Simon
>>
>> |  -Original Message-
>> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
>> |  Edward Z. Yang
>> |  Sent: 18 January 2016 06:37
>> |  To: Conal Elliott 
>> |  Cc: Andrew Farmer ; ghc-devs@haskell.org
>> |  Subject: Re: ghci and unfoldings?
>> |
>> |  Does passing -fobject-code solve your problem?
>> |
>> |  Edward
>> |
>> |  Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
>> |  > Hi Brandon. Thanks for the reply. I’m not sure that it addresses
>> |  what
>> |  > I was trying to ask. GHCi *does* invoke plugins and even reloads
>> |  those
>> |  > plugins dynamically when their source code changes. So in this sense
>> |  > ghci does enable optimization, even if it doesn’t perform much
>> |  > optimization on its own. And of course plugins and unfolding are not
>> |  just about optimization.
>> |  >
>> |  > I’m not looking for ghci to do optimization, but rather to enable me
>> |  > to more easily develop my GHC plugins. It’s *almost* there already.
>> |  I
>> |  > just need access to unfoldings from other modules for my plugin’s
>> |  use.
>> |  >
>> |  > For context, I’m rebuilding my Haskell-to-hardware compiler
>> |  > , which
>> |  relies
>> |  > on giving a non-standard but principled interpretation of Haskell
>> |  > programs via a conversion through the language of cartesian closed
>> |  categories (CCCs).
>> |  > The first back-end is hardware generation (e.g., via Verilog), and I
>> |  > have plans for several other CCC-based interpretations.
>> |  >
>> |  > In addition to facilitating my plugin development, hosting in ghci
>> |  > will make it much more pleasant for others to *use* the plugin
>> |  during
>> |  > exploratory programming, just as with ghci use in general. With
>> |  access
>> |  > to unfoldings, users will be able to generate circuit diagrams and
>> |  > Verilog like those in my compiler talk immediately and directly from
>> |  > within ghci. I also intend to make a GPU back-end for fast
>> |  interactive
>> |  > graphics etc, which would be much more fun in ghci than with batch
>> |  compilation.
>> |  > I hope this explanation clarifies my goals and motivation. I hope
>> |  > there’s a way to access unfoldings from ghci currently or with a
>> |  small
>> |  > amount of effort.
>> |  >
>> |  > Regards, - Conal
>> |  >
>> |  > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery
>> |  
>> |  > wrote:
>> |  >
>> |  > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott 
>> |  wrote:
>> |  > >
>> |  > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use
>> |  > >> ghci to speed up development. I'm able to do so, except that my
>> |  > >> plugin critically needs access to unfoldings, which appear to be
>> |  > >> unavailable in ghci. A little experimenting with ghc shows me
>> |  that
>> |  > >> "-O" is the key, but "-O" is incompatible with "--interactive"
>> |  (as
>> |  > >> in ghci). Is there any way to persuade ghci to make unfoldings
>> |  available?
>> |  > >
>> |  > >
>> |  > > I think unfoldings are only done as part of optimization, and the
>> |  > > bytecode backend doesn't support optimization at all.
>> |  > >
>> |  > > --
>> |  > > brandon s allbery kf8nh   sine nomine
>> |  > > associates
>> |  > > allber...@gmail.com
>> |  > > ballb...@sinenomine.net
>> |  > > unix, openafs, kerberos, infrastructure, xmonad
>> |  > >
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine
>> |  > >
>> |  nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5
>> |  > >
>> |  5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda
>> |  > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d
>> |  > >
>> |  ___
>> |  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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af
>> |  447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz
>> |  Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: kind of type equalities (was: equality relations: user-facing pretty-printing question)

[Richard Eisenberg]

And lifted ones can exist at runtime, via deferred type errors. With deferred 
type errors, a lifted equality might be a thunk that evaluates to a type error.

I also think that "because Core needs it" is a satisfying answer. That's why we 
have coercions. If we didn't care about type-checking Core, we could just omit 
very large swathes of GHC. But then we'd have a non-working compiler. :)

Richard

On Jan 18, 2016, at 1:12 PM, Eric Seidel  wrote:

> This is a bit tangential, but I find it odd that we care about whether a
> type equality has kind Lifted or Unlifted. 
> 
> As I understand, the Lifted/Unlifted distinction exists so that we know
> whether we have a thunk (and by extension a pointer of a constant size)
> or the thing itself (the size depends on the type). So Lifted/Unlifted
> is primarily important for code-gen and runtime purposes. Type
> equalities, on the other hand, shouldn't exist at runtime as the types
> are erased.
> 
> So why do we care whether a type equality is a thunk? My guess is that
> we only care because type equalities *do* exist in Core as proof terms,
> so they need to be well-kinded, but this isn't a very satisfying answer.
> 
> 
> On Mon, Jan 18, 2016, at 09:55, Richard Eisenberg wrote:
>> I like that idea. Do others?
>> 
>> Yes, agreed about the difference between ~ and ~~.
>> 
>> ~# is unlifted, and is now the type that the solver works on. ~~ is
>> lifted. That's the only difference. But the fact that ~~ is lifted is
>> what allows you to put it in a constraint, because all constraints are
>> lifted. Users should never bother with ~#, but they might with ~~.
>> 
>> Richard
>> 
>> On Jan 18, 2016, at 12:52 PM, Iavor Diatchki 
>> wrote:
>> 
>>> Hello,
>>> 
>>> What's the difference between `~~` and `~#` (I assume `~#` is 
>>> heterogeneous)? 
>>> 
>>> As for the rest, as far as I understand, `~` is a strict subset of `~~` in 
>>> the sense that:
>>>  1. if `a ~ b`, then `a ~~ b`
>>>  2. if `not (a ~ b)`, then `not (a ~~ b)`
>>>  3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be 
>>> different from the kind of `b`), then `not (a ~~ b)`
>>> 
>>> So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`:
>>> 
>>>  if kindOf a == kindOf b then `a ~ b` else `a ~~ b`
>>> 
>>> -Iavor
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott  wrote:
>>> In my ideal world, GHC would remember as much as what the user wrote
>>> as possible in printing error messages. So if the user writes:
>>> 
>>>f :: Int ~ Char => ...
>>> 
>>> Then GHC would remember that the context was written with a single
>>> tilde, and print out Int ~ Char in the error message explicitly
>>> wherever the full type signature of f is printed.
>>> 
>>> What it sounds like, though, is that deep in the guts of the type
>>> inferencer, there's a chance that single-tilde equality might turn
>>> into double-tilde or tilde-hash equality at some point. In those
>>> cases, printing out the particular brand of tilde might get confusing.
>>> In such cases, we might compromise and print out something neutral
>>> like "is equal to". I suppose this would always be the case if you
>>> didn't explicitly write a ~ b and had to infer it.
>>> 
>>> I'm not sure about the technical details of this though, i.e., if GHC
>>> actually remembers a ~ b all the way through the
>>> typechecking/inferencing pipeline.
>>> 
>>> Ryan S.
>>> ___
>>> 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
>> 
>> ___
>> 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

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

kind of type equalities (was: equality relations: user-facing pretty-printing question)

[Eric Seidel]

This is a bit tangential, but I find it odd that we care about whether a
type equality has kind Lifted or Unlifted. 

As I understand, the Lifted/Unlifted distinction exists so that we know
whether we have a thunk (and by extension a pointer of a constant size)
or the thing itself (the size depends on the type). So Lifted/Unlifted
is primarily important for code-gen and runtime purposes. Type
equalities, on the other hand, shouldn't exist at runtime as the types
are erased.

So why do we care whether a type equality is a thunk? My guess is that
we only care because type equalities *do* exist in Core as proof terms,
so they need to be well-kinded, but this isn't a very satisfying answer.


On Mon, Jan 18, 2016, at 09:55, Richard Eisenberg wrote:
> I like that idea. Do others?
> 
> Yes, agreed about the difference between ~ and ~~.
> 
> ~# is unlifted, and is now the type that the solver works on. ~~ is
> lifted. That's the only difference. But the fact that ~~ is lifted is
> what allows you to put it in a constraint, because all constraints are
> lifted. Users should never bother with ~#, but they might with ~~.
> 
> Richard
> 
> On Jan 18, 2016, at 12:52 PM, Iavor Diatchki 
> wrote:
> 
> > Hello,
> > 
> > What's the difference between `~~` and `~#` (I assume `~#` is 
> > heterogeneous)? 
> > 
> > As for the rest, as far as I understand, `~` is a strict subset of `~~` in 
> > the sense that:
> >   1. if `a ~ b`, then `a ~~ b`
> >   2. if `not (a ~ b)`, then `not (a ~~ b)`
> >   3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be 
> > different from the kind of `b`), then `not (a ~~ b)`
> > 
> > So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`:
> > 
> >   if kindOf a == kindOf b then `a ~ b` else `a ~~ b`
> > 
> > -Iavor
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott  wrote:
> > In my ideal world, GHC would remember as much as what the user wrote
> > as possible in printing error messages. So if the user writes:
> > 
> > f :: Int ~ Char => ...
> > 
> > Then GHC would remember that the context was written with a single
> > tilde, and print out Int ~ Char in the error message explicitly
> > wherever the full type signature of f is printed.
> > 
> > What it sounds like, though, is that deep in the guts of the type
> > inferencer, there's a chance that single-tilde equality might turn
> > into double-tilde or tilde-hash equality at some point. In those
> > cases, printing out the particular brand of tilde might get confusing.
> > In such cases, we might compromise and print out something neutral
> > like "is equal to". I suppose this would always be the case if you
> > didn't explicitly write a ~ b and had to infer it.
> > 
> > I'm not sure about the technical details of this though, i.e., if GHC
> > actually remembers a ~ b all the way through the
> > typechecking/inferencing pipeline.
> > 
> > Ryan S.
> > ___
> > 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
> 
> ___
> 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: equality relations: user-facing pretty-printing question

[Ryan Scott]

That sounds like a great idea to me.

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

Re: equality relations: user-facing pretty-printing question

[David Kraeutmann]

If ~# is hidden from the user, I think it's reasonable to hide it as an 
implementation detail.
The idea Iavor had sounds good, but we can get (potentially) confusing error 
messages when writing `Int ~~ Char => ...` -- the smart pretty printer would 
print `Int ~ Char`. Might get a bit messy.
On 1/18/2016 6:55 PM, Richard Eisenberg wrote:
> I like that idea. Do others?
>
> Yes, agreed about the difference between ~ and ~~.
>
> ~# is unlifted, and is now the type that the solver works on. ~~ is lifted. 
> That's the only difference. But the fact that ~~ is lifted is what allows you 
> to put it in a constraint, because all constraints are lifted. Users should 
> never bother with ~#, but they might with ~~.
>
> Richard
>
> On Jan 18, 2016, at 12:52 PM, Iavor Diatchki  wrote:
>
> > Hello,
> >
> > What's the difference between `~~` and `~#` (I assume `~#` is 
> > heterogeneous)?
> >
> > As for the rest, as far as I understand, `~` is a strict subset of `~~` in 
> > the sense that:
> >   1. if `a ~ b`, then `a ~~ b`
> >   2. if `not (a ~ b)`, then `not (a ~~ b)`
> >   3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be 
> > different from the kind of `b`), then `not (a ~~ b)`
> >
> > So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`:
> >
> >   if kindOf a == kindOf b then `a ~ b` else `a ~~ b`
> >
> > -Iavor
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott  wrote:
> > In my ideal world, GHC would remember as much as what the user wrote
> > as possible in printing error messages. So if the user writes:
> >
> > f :: Int ~ Char => ...
> >
> > Then GHC would remember that the context was written with a single
> > tilde, and print out Int ~ Char in the error message explicitly
> > wherever the full type signature of f is printed.
> >
> > What it sounds like, though, is that deep in the guts of the type
> > inferencer, there's a chance that single-tilde equality might turn
> > into double-tilde or tilde-hash equality at some point. In those
> > cases, printing out the particular brand of tilde might get confusing.
> > In such cases, we might compromise and print out something neutral
> > like "is equal to". I suppose this would always be the case if you
> > didn't explicitly write a ~ b and had to infer it.
> >
> > I'm not sure about the technical details of this though, i.e., if GHC
> > actually remembers a ~ b all the way through the
> > typechecking/inferencing pipeline.
> >
> > Ryan S.
> > ___
> > 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
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: equality relations: user-facing pretty-printing question

[Richard Eisenberg]

I like that idea. Do others?

Yes, agreed about the difference between ~ and ~~.

~# is unlifted, and is now the type that the solver works on. ~~ is lifted. 
That's the only difference. But the fact that ~~ is lifted is what allows you 
to put it in a constraint, because all constraints are lifted. Users should 
never bother with ~#, but they might with ~~.

Richard

On Jan 18, 2016, at 12:52 PM, Iavor Diatchki  wrote:

> Hello,
> 
> What's the difference between `~~` and `~#` (I assume `~#` is heterogeneous)? 
> 
> As for the rest, as far as I understand, `~` is a strict subset of `~~` in 
> the sense that:
>   1. if `a ~ b`, then `a ~~ b`
>   2. if `not (a ~ b)`, then `not (a ~~ b)`
>   3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be 
> different from the kind of `b`), then `not (a ~~ b)`
> 
> So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`:
> 
>   if kindOf a == kindOf b then `a ~ b` else `a ~~ b`
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott  wrote:
> In my ideal world, GHC would remember as much as what the user wrote
> as possible in printing error messages. So if the user writes:
> 
> f :: Int ~ Char => ...
> 
> Then GHC would remember that the context was written with a single
> tilde, and print out Int ~ Char in the error message explicitly
> wherever the full type signature of f is printed.
> 
> What it sounds like, though, is that deep in the guts of the type
> inferencer, there's a chance that single-tilde equality might turn
> into double-tilde or tilde-hash equality at some point. In those
> cases, printing out the particular brand of tilde might get confusing.
> In such cases, we might compromise and print out something neutral
> like "is equal to". I suppose this would always be the case if you
> didn't explicitly write a ~ b and had to infer it.
> 
> I'm not sure about the technical details of this though, i.e., if GHC
> actually remembers a ~ b all the way through the
> typechecking/inferencing pipeline.
> 
> Ryan S.
> ___
> 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

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

Re: equality relations: user-facing pretty-printing question

[Iavor Diatchki]

Hello,

What's the difference between `~~` and `~#` (I assume `~#` is
heterogeneous)?

As for the rest, as far as I understand, `~` is a strict subset of `~~` in
the sense that:
  1. if `a ~ b`, then `a ~~ b`
  2. if `not (a ~ b)`, then `not (a ~~ b)`
  3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be
different from the kind of `b`), then `not (a ~~ b)`

So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`:

  if kindOf a == kindOf b then `a ~ b` else `a ~~ b`

-Iavor







On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott  wrote:

> In my ideal world, GHC would remember as much as what the user wrote
> as possible in printing error messages. So if the user writes:
>
> f :: Int ~ Char => ...
>
> Then GHC would remember that the context was written with a single
> tilde, and print out Int ~ Char in the error message explicitly
> wherever the full type signature of f is printed.
>
> What it sounds like, though, is that deep in the guts of the type
> inferencer, there's a chance that single-tilde equality might turn
> into double-tilde or tilde-hash equality at some point. In those
> cases, printing out the particular brand of tilde might get confusing.
> In such cases, we might compromise and print out something neutral
> like "is equal to". I suppose this would always be the case if you
> didn't explicitly write a ~ b and had to infer it.
>
> I'm not sure about the technical details of this though, i.e., if GHC
> actually remembers a ~ b all the way through the
> typechecking/inferencing pipeline.
>
> Ryan S.
> ___
> 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: ghci and unfoldings?

[Conal Elliott]

That's the flag I would expect. It doesn't seem to help or hinder
availability of unfoldings in GHCi. Do you think it should?

And Happy Birthday, Simon!

Warmly, - Conal

On Monday, January 18, 2016, Simon Peyton Jones 
wrote:

> Or -fexpose-all-unfoldings?
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Edward Z. Yang
> |  Sent: 18 January 2016 06:37
> |  To: Conal Elliott 
> |  Cc: Andrew Farmer ; ghc-devs@haskell.org
> |  Subject: Re: ghci and unfoldings?
> |
> |  Does passing -fobject-code solve your problem?
> |
> |  Edward
> |
> |  Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
> |  > Hi Brandon. Thanks for the reply. I’m not sure that it addresses
> |  what
> |  > I was trying to ask. GHCi *does* invoke plugins and even reloads
> |  those
> |  > plugins dynamically when their source code changes. So in this sense
> |  > ghci does enable optimization, even if it doesn’t perform much
> |  > optimization on its own. And of course plugins and unfolding are not
> |  just about optimization.
> |  >
> |  > I’m not looking for ghci to do optimization, but rather to enable me
> |  > to more easily develop my GHC plugins. It’s *almost* there already.
> |  I
> |  > just need access to unfoldings from other modules for my plugin’s
> |  use.
> |  >
> |  > For context, I’m rebuilding my Haskell-to-hardware compiler
> |  > , which
> |  relies
> |  > on giving a non-standard but principled interpretation of Haskell
> |  > programs via a conversion through the language of cartesian closed
> |  categories (CCCs).
> |  > The first back-end is hardware generation (e.g., via Verilog), and I
> |  > have plans for several other CCC-based interpretations.
> |  >
> |  > In addition to facilitating my plugin development, hosting in ghci
> |  > will make it much more pleasant for others to *use* the plugin
> |  during
> |  > exploratory programming, just as with ghci use in general. With
> |  access
> |  > to unfoldings, users will be able to generate circuit diagrams and
> |  > Verilog like those in my compiler talk immediately and directly from
> |  > within ghci. I also intend to make a GPU back-end for fast
> |  interactive
> |  > graphics etc, which would be much more fun in ghci than with batch
> |  compilation.
> |  > I hope this explanation clarifies my goals and motivation. I hope
> |  > there’s a way to access unfoldings from ghci currently or with a
> |  small
> |  > amount of effort.
> |  >
> |  > Regards, - Conal
> |  >
> |  > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery
> |  
> |  > wrote:
> |  >
> |  > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott 
> |  wrote:
> |  > >
> |  > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use
> |  > >> ghci to speed up development. I'm able to do so, except that my
> |  > >> plugin critically needs access to unfoldings, which appear to be
> |  > >> unavailable in ghci. A little experimenting with ghc shows me
> |  that
> |  > >> "-O" is the key, but "-O" is incompatible with "--interactive"
> |  (as
> |  > >> in ghci). Is there any way to persuade ghci to make unfoldings
> |  available?
> |  > >
> |  > >
> |  > > I think unfoldings are only done as part of optimization, and the
> |  > > bytecode backend doesn't support optimization at all.
> |  > >
> |  > > --
> |  > > brandon s allbery kf8nh   sine nomine
> |  > > associates
> |  > > allber...@gmail.com
> |  > > ballb...@sinenomine.net
> |  > > unix, openafs, kerberos, infrastructure, xmonad
> |  > >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine
> |  > >
> |  nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5
> |  > >
> |  5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda
> |  > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d
> |  > >
> |  ___
> |  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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af
> |  447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz
> |  Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: equality relations: user-facing pretty-printing question

[Ryan Scott]

In my ideal world, GHC would remember as much as what the user wrote
as possible in printing error messages. So if the user writes:

f :: Int ~ Char => ...

Then GHC would remember that the context was written with a single
tilde, and print out Int ~ Char in the error message explicitly
wherever the full type signature of f is printed.

What it sounds like, though, is that deep in the guts of the type
inferencer, there's a chance that single-tilde equality might turn
into double-tilde or tilde-hash equality at some point. In those
cases, printing out the particular brand of tilde might get confusing.
In such cases, we might compromise and print out something neutral
like "is equal to". I suppose this would always be the case if you
didn't explicitly write a ~ b and had to infer it.

I'm not sure about the technical details of this though, i.e., if GHC
actually remembers a ~ b all the way through the
typechecking/inferencing pipeline.

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

Re: Phab failing to apply patches

[Jan Stolarek]

I agree with everything Richard said.

Janek

Dnia poniedziałek, 18 stycznia 2016, Richard Eisenberg napisał:
> Just to chime in here: I agree with Janek that the current requirement that
> Phab always cherry-picks changes against master is annoying. I have a
> limited amount of computing power available locally, and it's much easier
> to push to Phab than to slow down my primary dev machine for 2+ hours.
> (Yes, it takes my machine 2+ hours to validate.) And rebasing a big patch
> frequently is even more annoying, even though it inevitably must be done in
> the end.
>
> That said, I also agree that we wish to accept patches that validate only
> when compared against HEAD.
>
> So, I wonder if a diff in Phab can have a new state, WIP. A WIP patch
> doesn't show up in the review queue and validates against its own base
> commit. When the author is ready for a full review, the author changes the
> state to Please Review, which then shows up in queues and validates only
> against master.
>
> Thomas's suggestion is essentially "don't post WIP patches". But posting a
> WIP patch is very helpful, serving two needs: 1) Validation that doesn't
> tie up a local machine.
>  2) Allows for early feedback on a patch. Several times, I've had some
> work-in-progress that has benefitted from an early review. And I've
> provided early reviews that saved the author time from burrowing down the
> wrong hole.
>
> Is this possible? Is this desirable to others, too?
>
> Thanks,
> Richard
>
> On Jan 18, 2016, at 12:09 PM, Thomas Miedema  wrote:
> > On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek  
> > wrote:
> > > If you are working from an old base commit, either rebase your patch
> > > before submitting to Phabricator (painful? you will have to do it
> > > before pushing anyway, might as well do it now), or ignore the
> > > Harbormaster validate result.
> >
> > I am typically working on some non-trivial features (ie. rebases tend to
> > be painful). Having Harbormaster build results is a useful way of telling
> > whether I broke something or not. Even if it is for some older commit.
> > Rebases take time and if I know my feature will not be finished in the
> > next couple of weeks I want to save myself from unnecessary rebasing. Why
> > rebase all the time if I can do it just once at the end?
> >
> > There are a few options:
> >
> > * you validate locally (in a different build directory, so you can keep
> > using build flavour = devel2 in your development directory) * fork the
> > ghc github repository, push your branch there, and let Travis validate
> > it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis * ask
> > Austin for some special Phabricator syntax that you could add when you
> > submit the patch, to request Harbormaster not to rebase onto HEAD before
> > validating
> >
> >
> > Side note: I think we should go back to using Phabricator for finished
> > patches only. It slows the review process down, when there are 50 patches
> > in the queue waiting-for-review-but-not-really:
> > https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/
> > Sometimes it leads to finished patches actually getting ignored for a
> > long time, because the reviewers still think the author is working on
> > them. But other might think differently, and maybe it's not a big deal.
> >
> >
> >
> >
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed. If you are not the intended recipient
> > or if you have received this message in error, please notify the sender
> > and delete it from your system.
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

> * you validate locally (in a different build directory, so you can keep
> using build flavour = devel2 in your development directory)
> * fork the ghc github repository, push your branch there, and let Travis
> validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis
> * ask Austin for some special Phabricator syntax that you could add when
> you submit the patch, to request Harbormaster not to rebase onto HEAD
> before validating
Second option is an acceptable workaround for me, but having the third one 
would be even better. I 
definitely want to avoid the first one - computing power of my machine is 
limited.

> Side note: I think we should go back to using Phabricator for finished
> patches only.
What if we could set the default state of upload patch to "planned changes"? 
This way patches 
would end up in the review queue only when someone explicitly sets them to 
"Request Review". 
Wouldn't that solve the problem?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Richard Eisenberg]

Just to chime in here: I agree with Janek that the current requirement that 
Phab always cherry-picks changes against master is annoying. I have a limited 
amount of computing power available locally, and it's much easier to push to 
Phab than to slow down my primary dev machine for 2+ hours. (Yes, it takes my 
machine 2+ hours to validate.) And rebasing a big patch frequently is even more 
annoying, even though it inevitably must be done in the end.

That said, I also agree that we wish to accept patches that validate only when 
compared against HEAD.

So, I wonder if a diff in Phab can have a new state, WIP. A WIP patch doesn't 
show up in the review queue and validates against its own base commit. When the 
author is ready for a full review, the author changes the state to Please 
Review, which then shows up in queues and validates only against master.

Thomas's suggestion is essentially "don't post WIP patches". But posting a WIP 
patch is very helpful, serving two needs:
 1) Validation that doesn't tie up a local machine.
 2) Allows for early feedback on a patch. Several times, I've had some 
work-in-progress that has benefitted from an early review. And I've provided 
early reviews that saved the author time from burrowing down the wrong hole.

Is this possible? Is this desirable to others, too?

Thanks,
Richard

On Jan 18, 2016, at 12:09 PM, Thomas Miedema  wrote:

> 
> 
> On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek  wrote:
> > If you are working from an old base commit, either rebase your patch before
> > submitting to Phabricator (painful? you will have to do it before pushing
> > anyway, might as well do it now), or ignore the Harbormaster validate
> > result.
> I am typically working on some non-trivial features (ie. rebases tend to be 
> painful). Having
> Harbormaster build results is a useful way of telling whether I broke 
> something or not. Even if
> it is for some older commit. Rebases take time and if I know my feature will 
> not be finished in
> the next couple of weeks I want to save myself from unnecessary rebasing. Why 
> rebase all the time
> if I can do it just once at the end?
> 
> There are a few options:
> 
> * you validate locally (in a different build directory, so you can keep using 
> build flavour = devel2 in your development directory)
> * fork the ghc github repository, push your branch there, and let Travis 
> validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis
> * ask Austin for some special Phabricator syntax that you could add when you 
> submit the patch, to request Harbormaster not to rebase onto HEAD before 
> validating 
> 
> 
> Side note: I think we should go back to using Phabricator for finished 
> patches only. It slows the review process down, when there are 50 patches in 
> the queue waiting-for-review-but-not-really: 
> https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/ Sometimes it 
> leads to finished patches actually getting ignored for a long time, because 
> the reviewers still think the author is working on them. But other might 
> think differently, and maybe it's not a big deal.
> 
> 
> 
>  
> 
> Janek
> 
> ---
> Politechnika Łódzka
> Lodz University of Technology
> 
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> 
> This email contains information intended solely for the use of the individual 
> to whom it is addressed.
> If you are not the intended recipient or if you have received this message in 
> error,
> please notify the sender and delete it from your system.
> 
> ___
> 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: Phab failing to apply patches

[Thomas Miedema]

On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek 
wrote:

> > If you are working from an old base commit, either rebase your patch
> before
> > submitting to Phabricator (painful? you will have to do it before pushing
> > anyway, might as well do it now), or ignore the Harbormaster validate
> > result.
> I am typically working on some non-trivial features (ie. rebases tend to
> be painful). Having
> Harbormaster build results is a useful way of telling whether I broke
> something or not. Even if
> it is for some older commit. Rebases take time and if I know my feature
> will not be finished in
> the next couple of weeks I want to save myself from unnecessary rebasing.
> Why rebase all the time
> if I can do it just once at the end?
>

There are a few options:

* you validate locally (in a different build directory, so you can keep
using build flavour = devel2 in your development directory)
* fork the ghc github repository, push your branch there, and let Travis
validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis
* ask Austin for some special Phabricator syntax that you could add when
you submit the patch, to request Harbormaster not to rebase onto HEAD
before validating


Side note: I think we should go back to using Phabricator for finished
patches only. It slows the review process down, when there are 50 patches
in the queue waiting-for-review-but-not-really:
https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/ Sometimes
it leads to finished patches actually getting ignored for a long time,
because the reviewers still think the author is working on them. But other
might think differently, and maybe it's not a big deal.





>
> Janek
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message
> in error,
> please notify the sender and delete it from your system.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

> If you are working from an old base commit, either rebase your patch before
> submitting to Phabricator (painful? you will have to do it before pushing
> anyway, might as well do it now), or ignore the Harbormaster validate
> result.
I am typically working on some non-trivial features (ie. rebases tend to be 
painful). Having 
Harbormaster build results is a useful way of telling whether I broke something 
or not. Even if 
it is for some older commit. Rebases take time and if I know my feature will 
not be finished in 
the next couple of weeks I want to save myself from unnecessary rebasing. Why 
rebase all the time 
if I can do it just once at the end?

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Thomas Miedema]

On Sun, Jan 17, 2016 at 4:24 PM, Jan Stolarek 
wrote:

> Can we somehow force Phab to apply a patch against a base commit from
> which the patch was created?
>

I don't know about "somehow", maybe Austin knows a way.

The current default should not be changed though, in my opinion. We expect
contributors to make their patches against HEAD, and we want to review them
against HEAD. So Harbormaster should also try to build them against HEAD.

If you are working from an old base commit, either rebase your patch before
submitting to Phabricator (painful? you will have to do it before pushing
anyway, might as well do it now), or ignore the Harbormaster validate
result.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

equality relations: user-facing pretty-printing question

[Richard Eisenberg]

Hi devs,

I've recently made a design decision for GHC 8.0 that I may wish to revisit, 
and I'd love some feedback.

GHC 7.x has but one user-visible type equality relation, ~. The constraint (ty1 
~ ty2) is well-kinded only when ty1 and ty2 have the same kinds. And the solver 
works in terms of this very same equality, so error messages simply talk about 
~.

GHC 8.0, on the other hand, has three equality relations that might potentially 
appear to users. It retains ~. But it also has ~~, which is heterogeneous type 
equality, meaning that (ty1 ~~ ty2) is well-kinded even when ty1 and ty2 have 
different kinds. And it has ~#, which is the unlifted equality used in the 
solver. It turns out that ~~ and ~ are just wrappers around ~#. Because of all 
of this, GHC sometimes ends up thinking about ~~ or ~# even when the user has 
said ~. (See the definition of ~ in Data.Type.Equality, for example.) And it 
naively would print ~# a bunch in error messages. So, I put a little 
pretty-printing magic in that prints ~, ~~, and ~# all as ~ in user-facing 
output, unless the user writes -fprint-equality-relations.

This design decision has kept error messages pretty. But it will be awfully 
confusing when someone intentionally uses ~~ and sees ~ in their output. And 
there's nothing to suggest -fprint-equality-relations. These sorts "hide the 
scary plumbing!" decisions irk me to no end when I find them in my operating 
system. But now I've done the same thing in GHC... which is why I want to 
re-examine this.

What do you think? Do you see a better way to handle this?

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

Re: Multiple GHC sessions

[Simon Marlow]

On 18 January 2016 at 11:18, Alan & Kim Zimmerman 
wrote:

> From a tool writer perspective I would be happy to have GHC/Linker
> sessions be completely separate from each other. But I guess in
> practical terms a shared address space needs to be managed, making
> this impossible.
>
> The external interpreter for GHCI effectively solves the actual
> loading problem, the other things needing a GHC session are loading a
> module as far as type checking, for error reporting. I know this gets
> complicated if there is FFI involved and the loading has to go via
> object file generation.
>

Yes, I think -fexternal-interpreter is the basis of the right solution
here.  You do also need to move the PersistentLinkerState to HscEnv, but
that should be a fairly straightforward refactoring.  (actually I almost
did this as part of the remote GHCi work, but some of the comments next to
PersistentLinkerState suggested that there might be some real use cases for
having the linker state be shared between multiple sessions, so I decided
not to attack that problem right away.)

Cheers,
Simon

Alan
>
> On Mon, Jan 18, 2016 at 12:53 PM, Ben Gamari  wrote:
> > Simon Peyton Jones  writes:
> >
> >> I don't think the state-hack tail should wag the dog here. The nub of
> >> the problem in practice is the shared linker state isn't it?
> >>
> > I'm not sure; it's not clear to me what would break if the linker were
> > used by more than one session at a time, even with the current
> > GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all
> > sessions to use the same linker state given that they are also sharing
> > an address space.
> >
> > The only issue that may require a bit of care is code unloading.
> > Consider that you have two sessions A and B,
> >
> >   1. A loads MyModule
> >   2. B loads MyModule
> >   3. They both use MyModule for a while
> >   4. A unloads MyModule
> >   5. B continues
> >   6. B unloads MyModule
> >
> > I suspect that things will work fine up to step 6 since we don't
> > actually unload code until the garbage collector has marked the it as
> > dead. That being said, I suspect you would see an error from unloadObj
> > upon attempting to unload the object the second time (and even then, the
> > error is merely a message on stderr). Note, however, that the above
> > conclusions have not been tested.
> >
> > Otherwise, it appears that things should behave fair well as the
> > PersistentLinkerState is already wrapped in an MVar which should
> > serve to serialize linker calls.
> >
> > Cheers,
> >
> > - Ben
> >
> ___
> 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: Multiple GHC sessions

[Alan & Kim Zimmerman]

>From a tool writer perspective I would be happy to have GHC/Linker
sessions be completely separate from each other. But I guess in
practical terms a shared address space needs to be managed, making
this impossible.

The external interpreter for GHCI effectively solves the actual
loading problem, the other things needing a GHC session are loading a
module as far as type checking, for error reporting. I know this gets
complicated if there is FFI involved and the loading has to go via
object file generation.

Alan

On Mon, Jan 18, 2016 at 12:53 PM, Ben Gamari  wrote:
> Simon Peyton Jones  writes:
>
>> I don't think the state-hack tail should wag the dog here. The nub of
>> the problem in practice is the shared linker state isn't it?
>>
> I'm not sure; it's not clear to me what would break if the linker were
> used by more than one session at a time, even with the current
> GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all
> sessions to use the same linker state given that they are also sharing
> an address space.
>
> The only issue that may require a bit of care is code unloading.
> Consider that you have two sessions A and B,
>
>   1. A loads MyModule
>   2. B loads MyModule
>   3. They both use MyModule for a while
>   4. A unloads MyModule
>   5. B continues
>   6. B unloads MyModule
>
> I suspect that things will work fine up to step 6 since we don't
> actually unload code until the garbage collector has marked the it as
> dead. That being said, I suspect you would see an error from unloadObj
> upon attempting to unload the object the second time (and even then, the
> error is merely a message on stderr). Note, however, that the above
> conclusions have not been tested.
>
> Otherwise, it appears that things should behave fair well as the
> PersistentLinkerState is already wrapped in an MVar which should
> serve to serialize linker calls.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Multiple GHC sessions

[Ben Gamari]

Simon Peyton Jones  writes:

> I don't think the state-hack tail should wag the dog here. The nub of
> the problem in practice is the shared linker state isn't it?
>
I'm not sure; it's not clear to me what would break if the linker were
used by more than one session at a time, even with the current
GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all
sessions to use the same linker state given that they are also sharing
an address space.

The only issue that may require a bit of care is code unloading.
Consider that you have two sessions A and B,

  1. A loads MyModule 
  2. B loads MyModule
  3. They both use MyModule for a while
  4. A unloads MyModule
  5. B continues 
  6. B unloads MyModule

I suspect that things will work fine up to step 6 since we don't
actually unload code until the garbage collector has marked the it as
dead. That being said, I suspect you would see an error from unloadObj
upon attempting to unload the object the second time (and even then, the
error is merely a message on stderr). Note, however, that the above
conclusions have not been tested.

Otherwise, it appears that things should behave fair well as the
PersistentLinkerState is already wrapped in an MVar which should
serve to serialize linker calls.

Cheers,

- Ben



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

RE: ghci and unfoldings?

[Simon Peyton Jones]

Or -fexpose-all-unfoldings?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Edward Z. Yang
|  Sent: 18 January 2016 06:37
|  To: Conal Elliott 
|  Cc: Andrew Farmer ; ghc-devs@haskell.org
|  Subject: Re: ghci and unfoldings?
|  
|  Does passing -fobject-code solve your problem?
|  
|  Edward
|  
|  Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
|  > Hi Brandon. Thanks for the reply. I’m not sure that it addresses
|  what
|  > I was trying to ask. GHCi *does* invoke plugins and even reloads
|  those
|  > plugins dynamically when their source code changes. So in this sense
|  > ghci does enable optimization, even if it doesn’t perform much
|  > optimization on its own. And of course plugins and unfolding are not
|  just about optimization.
|  >
|  > I’m not looking for ghci to do optimization, but rather to enable me
|  > to more easily develop my GHC plugins. It’s *almost* there already.
|  I
|  > just need access to unfoldings from other modules for my plugin’s
|  use.
|  >
|  > For context, I’m rebuilding my Haskell-to-hardware compiler
|  > , which
|  relies
|  > on giving a non-standard but principled interpretation of Haskell
|  > programs via a conversion through the language of cartesian closed
|  categories (CCCs).
|  > The first back-end is hardware generation (e.g., via Verilog), and I
|  > have plans for several other CCC-based interpretations.
|  >
|  > In addition to facilitating my plugin development, hosting in ghci
|  > will make it much more pleasant for others to *use* the plugin
|  during
|  > exploratory programming, just as with ghci use in general. With
|  access
|  > to unfoldings, users will be able to generate circuit diagrams and
|  > Verilog like those in my compiler talk immediately and directly from
|  > within ghci. I also intend to make a GPU back-end for fast
|  interactive
|  > graphics etc, which would be much more fun in ghci than with batch
|  compilation.
|  > I hope this explanation clarifies my goals and motivation. I hope
|  > there’s a way to access unfoldings from ghci currently or with a
|  small
|  > amount of effort.
|  >
|  > Regards, - Conal
|  >
|  > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery
|  
|  > wrote:
|  >
|  > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott 
|  wrote:
|  > >
|  > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use
|  > >> ghci to speed up development. I'm able to do so, except that my
|  > >> plugin critically needs access to unfoldings, which appear to be
|  > >> unavailable in ghci. A little experimenting with ghc shows me
|  that
|  > >> "-O" is the key, but "-O" is incompatible with "--interactive"
|  (as
|  > >> in ghci). Is there any way to persuade ghci to make unfoldings
|  available?
|  > >
|  > >
|  > > I think unfoldings are only done as part of optimization, and the
|  > > bytecode backend doesn't support optimization at all.
|  > >
|  > > --
|  > > brandon s allbery kf8nh   sine nomine
|  > > associates
|  > > allber...@gmail.com
|  > > ballb...@sinenomine.net
|  > > unix, openafs, kerberos, infrastructure, xmonad
|  > >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine
|  > >
|  nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5
|  > >
|  5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda
|  > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d
|  > >
|  ___
|  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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af
|  447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz
|  Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Multiple GHC sessions

[Simon Peyton Jones]

I don't think the state-hack tail should wag the dog here.  The nub of the 
problem in practice is the shared linker state isn't it?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben
|  Gamari
|  Sent: 17 January 2016 19:55
|  To: Alan & Kim Zimmerman ; ghc-devs@haskell.org
|  Subject: Re: Multiple GHC sessions
|  
|  Alan & Kim Zimmerman  writes:
|  
|  > At the moment there are issues with having multiple GHC API sessions
|  > in a single executable, which boil down to GHC having global
|  > variables.
|  >
|  > A quick grep over the GHC sources shows the following instances
|  >
|  > compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ...
|  > compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, 
|  >
|  This isn't the only global state had by the linker; have a look at
|  rts/Linker.c. Unfortunately this would take a fair amount of work to
|  resolve. The easiest solution here would probably be to put a lock
|  around the linker and have all sessions in a process use the same
|  linker.
|  
|  > compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, 
|  > compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, 
|  >
|  We've been meaning to get rid of the remaining static flags for quite
|  some time.
|  
|  I was a bit surprised to find that opt_NoStateHack is static. This is
|  a bit of an ugly one: the only user is a test in Id.isStateHackType
|  which is buried inside several layers [1] of pure predicates that have
|  no DynFlags. It would be a shame to pass a DynFlags through all of
|  these calls just to support the state hack (which we threaten drop
|  about once every six months).
|  
|  One option, of course, would be to merge all of the static flags into
|  DynFlags and rework their users to use unsafeGlobalDynFlags.
|  
|  [1] One particular callpath is,
|  
|  Id.isStateHackType
|  Id.typeOneShot
|  CoreArity.typeArity
|  CoreArity.exprArity
|  CorePrep.rhsToBody
|  CorePrep.cpeBody
|  
|  
|  >
|  compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,
|  >
|  The principle user of this is Outputable, which uses it to provide
|  DynFlags for pprTrace and friends. As you say, these are rather
|  special cases and it's probably fine if they behave a bit funky in the
|  case of more than one session in a process.
|  
|  > ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,
|  >
|  It is completely unclear why this is global at all. It seems like it
|  would fit just fine in the GHCi monad. I've opened D1789 doing exactly
|  this.
|  
|  There may be other global state that I'm not thinking of, but if this
|  is everything then it seems quite possible to fix this up for 8.2.
|  
|  Cheers,
|  
|  - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs