Re: Birthday greetings

[raichoo]

Happy Birthday!

Thanks for all your work, I'm very happy with Haskell and GHC, especially
now that I
can use it at work :D.

I've been digging through GHC for months now, hoping to contribute
something back this year :)

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

Re: Birthday greetings

[Johan Tibell]

Happy birthday!

On Tue, Jan 19, 2016 at 9:31 AM, raichoo  wrote:

> Happy Birthday!
>
> Thanks for all your work, I'm very happy with Haskell and GHC, especially
> now that I
> can use it at work :D.
>
> I've been digging through GHC for months now, hoping to contribute
> something back this year :)
>
> Kind regards,
> raichoo
>
> ___
> 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: Improving trac notifications

[Matthew Pickering]

Have you had any chance to think about this yet Herbert?

Matt

On Wed, Jan 6, 2016 at 6:44 PM, Ben Gamari  wrote:
> Ben Gamari  writes:
>
>> Matthew Pickering  writes:
>>
>>> I subscribe to the ghc-tickets[1] mailing list which provides updates
>>> to all trac tickets. This is very useful, however when a ticket
>>> description is updated the whole description is included in the email
>>> which makes it hard to see what actually changed. The web interface
>>> shows a nice diff[2] of the changes, I think it would be good if
>>> emails could also include a diff rather than the current quite useless
>>> output.
>>>
>> I think this would be a great improvement. I, for one, am quite guilty
>> of incrementally editing ticket descriptions and the current email
>> notifications are nearly useless in this case.
>>
>>> After a bit of investigation, it appears that the easiest way to
>>> achieve this is apply a simple patch to our copy of trac. The current
>>> format is hard coded on line 558 in this module, it seems easy to
>>> modify this section to instead provide a diff.
>>>
>> Herbert, perhaps we could do something along these lines?
>>
> Ping.
>
> Cheers,
>
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fwd: Host-Oriented Template Haskell

[Edward Z. Yang]

Hello John

You may find this implementation ticket of interest:
https://ghc.haskell.org/trac/ghc/ticket/11378

Edward

Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
> Cross-posting this as was suggested on the Haskell-Cafe list. While I
> envision this as normal feature that anyone can use, in practice its
> biggest consumers would be GHC devs.
> 
> John
> 
> -- Forwarded message --
> From: Ericson, John 
> Date: Tue, Jan 19, 2016 at 1:17 PM
> Subject: Host-Oriented Template Haskell
> To: Haskell-Cafe 
> 
> 
> As is well known, TH and cross-compiling do not get along. There are
> various proposals on how to make this interaction less annoying, and I
> am not against them. But as I see it, the problem is largely inherent
> to the design of TH itself: since values can (usually) be lifted from
> compile-time to run-time, and normal definitions from upstream modules
> to downstream modules' TH, TH and normal code must "live in the same
> world".
> 
> Now this restriction in turn bequeaths TH with much expressive power,
> and I wouldn't advocate getting rid of it. But many tasks do not need
> it, and in some cases, say in bootstrapping compilers[1] themselves,
> it is impossible to use TH because of it, even were all the current
> proposals implemented.
> 
> For these reason, I propose a new TH variant which has much harsher
> phase separation. Normal definitions from upstream modules can not be
> used, lifting values is either not permitted or is allowed to fail
> (because of missing/incompatible definitions), and IO is defined to
> match the behavior of the host, not target, platform (in the cross
> compiling case). The only interaction between the two phases is that
> quoted syntax is resolved against the the run-time phase's definitions
> (just like today).
> 
> Some of you may find this a shoddy substitute for defining a subset of
> Haskell which behaves identically on all platforms, and optionally
> constraining TH to it. But the big feature that my proposal offers and
> that one doesn't is to be able to independently specify compile-time
> dependencies for the host-oriented TH---this is analogous to the
> newish `Setup.hs` dependencies. That in turns leads to what I think is
> the "killer app" for Host-Oriented TH: exposing the various
> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
> and side-stepping any need for "executable dependencies" in Cabal.
> Note also that at least hsc2hs additionally requires host-IO---there
> may not even exist a C compiler on the target platform at all.
> 
> Finally, forgive me if this has been brought up before. I've been
> thinking about this a while, and did a final pass over the GHC wiki to
> make sure it wasn't already proposed, but I could have missed
> something (this is also my first post to the list).
> 
> John
> 
> [1]: 
> https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fwd: Host-Oriented Template Haskell

[Ericson, John]

Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-}
imports is precisely equivalent to what I propose. I find a clean
separation with that and normal TH useful, however, precisely so the
stage2 compiler's source can include such a thing.

On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang  wrote:
> Hello John
>
> You may find this implementation ticket of interest:
> https://ghc.haskell.org/trac/ghc/ticket/11378
>
> Edward
>
> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
>> Cross-posting this as was suggested on the Haskell-Cafe list. While I
>> envision this as normal feature that anyone can use, in practice its
>> biggest consumers would be GHC devs.
>>
>> John
>>
>> -- Forwarded message --
>> From: Ericson, John 
>> Date: Tue, Jan 19, 2016 at 1:17 PM
>> Subject: Host-Oriented Template Haskell
>> To: Haskell-Cafe 
>>
>>
>> As is well known, TH and cross-compiling do not get along. There are
>> various proposals on how to make this interaction less annoying, and I
>> am not against them. But as I see it, the problem is largely inherent
>> to the design of TH itself: since values can (usually) be lifted from
>> compile-time to run-time, and normal definitions from upstream modules
>> to downstream modules' TH, TH and normal code must "live in the same
>> world".
>>
>> Now this restriction in turn bequeaths TH with much expressive power,
>> and I wouldn't advocate getting rid of it. But many tasks do not need
>> it, and in some cases, say in bootstrapping compilers[1] themselves,
>> it is impossible to use TH because of it, even were all the current
>> proposals implemented.
>>
>> For these reason, I propose a new TH variant which has much harsher
>> phase separation. Normal definitions from upstream modules can not be
>> used, lifting values is either not permitted or is allowed to fail
>> (because of missing/incompatible definitions), and IO is defined to
>> match the behavior of the host, not target, platform (in the cross
>> compiling case). The only interaction between the two phases is that
>> quoted syntax is resolved against the the run-time phase's definitions
>> (just like today).
>>
>> Some of you may find this a shoddy substitute for defining a subset of
>> Haskell which behaves identically on all platforms, and optionally
>> constraining TH to it. But the big feature that my proposal offers and
>> that one doesn't is to be able to independently specify compile-time
>> dependencies for the host-oriented TH---this is analogous to the
>> newish `Setup.hs` dependencies. That in turns leads to what I think is
>> the "killer app" for Host-Oriented TH: exposing the various
>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
>> and side-stepping any need for "executable dependencies" in Cabal.
>> Note also that at least hsc2hs additionally requires host-IO---there
>> may not even exist a C compiler on the target platform at all.
>>
>> Finally, forgive me if this has been brought up before. I've been
>> thinking about this a while, and did a final pass over the GHC wiki to
>> make sure it wasn't already proposed, but I could have missed
>> something (this is also my first post to the list).
>>
>> John
>>
>> [1]: 
>> https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
> ___
> 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: Fwd: Host-Oriented Template Haskell

[Ericson, John]

>From #11378:

> Can we actually link against the old version of ghc? Yes we can! All we need 
> is
> (1) for it to have been built with a different IPID, and
> (2) to use module renaming to rename the relevant modules to a different
> module name, so that we can import them without a conflict.


If I understand this, you are saying stage1 links stage0 (the normal,
non-cross-compiler used to build stage1), to build stage2? I agree
that should work, but if stage1 is multi-target isn't that level of
complexity not even needed? I'm not too familiar with GHC or its build
system, but a multi-target compiler that doesn't support normal TH
doesn't seem that hard to build in principle.

John

On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John  wrote:
> Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-}
> imports is precisely equivalent to what I propose. I find a clean
> separation with that and normal TH useful, however, precisely so the
> stage2 compiler's source can include such a thing.
>
> On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang  wrote:
>> Hello John
>>
>> You may find this implementation ticket of interest:
>> https://ghc.haskell.org/trac/ghc/ticket/11378
>>
>> Edward
>>
>> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
>>> Cross-posting this as was suggested on the Haskell-Cafe list. While I
>>> envision this as normal feature that anyone can use, in practice its
>>> biggest consumers would be GHC devs.
>>>
>>> John
>>>
>>> -- Forwarded message --
>>> From: Ericson, John 
>>> Date: Tue, Jan 19, 2016 at 1:17 PM
>>> Subject: Host-Oriented Template Haskell
>>> To: Haskell-Cafe 
>>>
>>>
>>> As is well known, TH and cross-compiling do not get along. There are
>>> various proposals on how to make this interaction less annoying, and I
>>> am not against them. But as I see it, the problem is largely inherent
>>> to the design of TH itself: since values can (usually) be lifted from
>>> compile-time to run-time, and normal definitions from upstream modules
>>> to downstream modules' TH, TH and normal code must "live in the same
>>> world".
>>>
>>> Now this restriction in turn bequeaths TH with much expressive power,
>>> and I wouldn't advocate getting rid of it. But many tasks do not need
>>> it, and in some cases, say in bootstrapping compilers[1] themselves,
>>> it is impossible to use TH because of it, even were all the current
>>> proposals implemented.
>>>
>>> For these reason, I propose a new TH variant which has much harsher
>>> phase separation. Normal definitions from upstream modules can not be
>>> used, lifting values is either not permitted or is allowed to fail
>>> (because of missing/incompatible definitions), and IO is defined to
>>> match the behavior of the host, not target, platform (in the cross
>>> compiling case). The only interaction between the two phases is that
>>> quoted syntax is resolved against the the run-time phase's definitions
>>> (just like today).
>>>
>>> Some of you may find this a shoddy substitute for defining a subset of
>>> Haskell which behaves identically on all platforms, and optionally
>>> constraining TH to it. But the big feature that my proposal offers and
>>> that one doesn't is to be able to independently specify compile-time
>>> dependencies for the host-oriented TH---this is analogous to the
>>> newish `Setup.hs` dependencies. That in turns leads to what I think is
>>> the "killer app" for Host-Oriented TH: exposing the various
>>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
>>> and side-stepping any need for "executable dependencies" in Cabal.
>>> Note also that at least hsc2hs additionally requires host-IO---there
>>> may not even exist a C compiler on the target platform at all.
>>>
>>> Finally, forgive me if this has been brought up before. I've been
>>> thinking about this a while, and did a final pass over the GHC wiki to
>>> make sure it wasn't already proposed, but I could have missed
>>> something (this is also my first post to the list).
>>>
>>> John
>>>
>>> [1]: 
>>> https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
>> ___
>> 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

CallStack naming

[Richard Eisenberg]

Hi devs,

I'm sure there's an easy answer to this, but I'm wondering: why is the 
CallStack feature implemented with implicit parameters instead of just a 
magical constraint? Whenever I use this feature, I don't want to have to enable 
-XImplicitParams and then make sure I get the name right. What would be wrong 
with, e.g.,

> undefined :: AppendsCallStack => a

Seems simpler. Is it problems with a nullary class?

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

Serialized module

[Simon Marlow]

As part of the recent Remote GHCi changes, I moved the module Serialized
from the ghc package to ghc-boot.  This is because it is shared by the ghci
package and ghc itself.  The only way to arrange that it was available to
both ghc in stage1 and the ghci package (which is not a dependency of the
stage1 ghc), was to put it in ghc-boot.

Unfortunately this introduces some breakage because some external code
import Serialized.  I just ran across hint which fails to compile.

I can fix this by re-introducing a Serialized module that re-exports module
GHC.Serialized.  But is that the right thing to do?  Serialized is also
re-exported by GhcPlugins.  Should we be asking people to import that
instead?

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

Re: ghci and unfoldings?

[Simon Marlow]

-fno-ignore-interface-pragmas might work.  However the problem is really
that the interpreter cannot compile the full intermediate language of GHC
(it can't handle arbitrary unboxed tuples), and we work around that in a
fairly fragile way by disabling -O.  By enabling unfoldings you might
expose the interpreter to some unboxed tuples which would cause it to
panic.  It's unlikely this will get fixed in the near term, if I recall
correctly it's pretty hard to fix.

So I think the best fix is probably to use -fobject-code.

Cheers,
Simon


On 18 January 2016 at 18:28, Conal Elliott  wrote:

> 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
>>> |  > >
>>> |  

Re: Birthday greetings

[Simon Marlow]

Happy Birthday Simon :)  And well done for keeping on top of things for so
long.

I reached the overload point quite a while ago and I no longer read all the
mailing lists.  So the same goes for me: I'm not going to see a ticket or a
diff unless you explicitly CC me on it - but please feel free to do that if
you think I ought to take a look.

Cheers
Simon

On 19 January 2016 at 00:22, 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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Fixing #11444 - OK-for-speculation check rejects valid program?

[Ömer Sinan Ağacan]

I found one of the problems with #11444, but I don't know how to fix it. The
problem is that the desugarer is generating this function:

ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool
[LclIdX, Str=DmdType]
ptrEq =
  \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) ->
case x_a1we of x_X1wq { __DEFAULT ->
case y_a1wf of y_X1ws { __DEFAULT ->
==
  @ Int
  GHC.Classes.$fEqInt
  (case reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws
   of wild_00 { __DEFAULT ->
   GHC.Types.I# wild_00
   })
  (GHC.Types.I# 1#)
}
}

Which is lint-safe. Then, the optimizer is transforming this into:

ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool
[LclIdX,
 Arity=2,
 Str=DmdType,
 Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True,
 WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 20] 71 0}]
ptrEq =
  \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) ->
case x_a1we of x_X1wq { __DEFAULT ->
case y_a1wf of y_X1ws { __DEFAULT ->
eqInt
  (I# (reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws)) (I# 1#)
}
}

The problem with this, according to the linter, is the argument of I# is not
OK-for-speculation (the expression `reallyUnsafePtrEquality# @ a_a1Ts x_X1wq
y_X1ws`). The reason is because arguments of `reallyUnsafePtrEquality#` are not
OK-for-speculation, because their types are polymorphic, and variables with
polymorphic types are not OK for speculation.

However, I think this expression should be OK-for-speculation, because it can't
fail, the primop is not out-of-line etc. I think all the requirements for being
OK for speculation hold here.

So my questions are:

- Does that look like a correct optimization transformation? (it looked OK to
  me, but wanted to make sure)

- Am I right that this expression should be OK for speculation?

- What's a good way to make this code lint-safe?

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

Fwd: Host-Oriented Template Haskell

[Ericson, John]

Cross-posting this as was suggested on the Haskell-Cafe list. While I
envision this as normal feature that anyone can use, in practice its
biggest consumers would be GHC devs.

John

-- Forwarded message --
From: Ericson, John 
Date: Tue, Jan 19, 2016 at 1:17 PM
Subject: Host-Oriented Template Haskell
To: Haskell-Cafe 


As is well known, TH and cross-compiling do not get along. There are
various proposals on how to make this interaction less annoying, and I
am not against them. But as I see it, the problem is largely inherent
to the design of TH itself: since values can (usually) be lifted from
compile-time to run-time, and normal definitions from upstream modules
to downstream modules' TH, TH and normal code must "live in the same
world".

Now this restriction in turn bequeaths TH with much expressive power,
and I wouldn't advocate getting rid of it. But many tasks do not need
it, and in some cases, say in bootstrapping compilers[1] themselves,
it is impossible to use TH because of it, even were all the current
proposals implemented.

For these reason, I propose a new TH variant which has much harsher
phase separation. Normal definitions from upstream modules can not be
used, lifting values is either not permitted or is allowed to fail
(because of missing/incompatible definitions), and IO is defined to
match the behavior of the host, not target, platform (in the cross
compiling case). The only interaction between the two phases is that
quoted syntax is resolved against the the run-time phase's definitions
(just like today).

Some of you may find this a shoddy substitute for defining a subset of
Haskell which behaves identically on all platforms, and optionally
constraining TH to it. But the big feature that my proposal offers and
that one doesn't is to be able to independently specify compile-time
dependencies for the host-oriented TH---this is analogous to the
newish `Setup.hs` dependencies. That in turns leads to what I think is
the "killer app" for Host-Oriented TH: exposing the various
prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
and side-stepping any need for "executable dependencies" in Cabal.
Note also that at least hsc2hs additionally requires host-IO---there
may not even exist a C compiler on the target platform at all.

Finally, forgive me if this has been brought up before. I've been
thinking about this a while, and did a final pass over the GHC wiki to
make sure it wasn't already proposed, but I could have missed
something (this is also my first post to the list).

John

[1]: 
https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to build profiled stage1?

[Ömer Sinan Ağacan]

An update: If I just clone from scratch, set the flavor "prof" and run
make, it doesn't work. But this is another problem, my original
problem is about building profiling stage1, rather than stage2.

2016-01-18 15:10 GMT-05:00 Ö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.
> < residency (2 samples), 46M in use, 0.000 INIT (0.001 elapsed), 0.003
> MUT (0.005 elapsed), 0.015 GC (0.019 elapsed) :ghc>>
>
> 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
>