Re: Stop holding hadrian back with backwards compatibility

[Richard Eisenberg]

> On Feb 10, 2021, at 8:50 AM, Simon Peyton Jones  wrote:
> 
> build with hadrian, and then continue using make with the artifacts 
> (partially) built by Hadrian

I almost suggested that this had to be the reason for the back-compat design, 
but I assumed I had to be wrong. I also agree this is a non-goal; I'm quite 
happy to be forced to pick one or the other and stick with that choice until 
blasting away all build products.

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

Re: Newtype over (~#)

[Richard Eisenberg]

> On Feb 10, 2021, at 5:43 AM, Igor Popov  wrote:
> 
> That's a really interesting quirk. That kind of explains why an
> argument to a cast has to be a CoVar, we want all casts to be guarded
> by a case-of. But do we still need the restriction that an Id cannot
> have a coercion type?

No, we wouldn't need the restriction if GHC were implemented correctly -- that 
is, without the mkLocalIdOrCoVar abomination that looks at the type of a binder 
to determine whether it's a CoVar.

> 
> Either case it seems like we need to be extremely careful with how the
> wrapper and the matcher works for such a constructor. I was hoping a
> sledgehammer approach would work where we kind of just force (a ~# b)
> as a field into a newtype, and the existing machinery magically works
> with it.
> 
> The construction is then chock full of questions:
> 
>axiom N::~:# :: forall k. (:~:#) @k ~R (~#) @k
> 
> Is this valid? mkPrimEqPred says it doesn't like equalities on either
> side (I'm assuming this applies to eta-contracted equalities as well).

I don't see any equalities on either side here. Instead, this is a relationship 
between equality *types*. That should be just fine; GHC even produces such 
things already from time to time. I do think you'll need two `@k`s on the 
right, though. The rule you're worried about forbids constructions like (cv1 ~R 
cv2), where cv1 and cv2 have been injected into types via CoercionTy.

> mkReprPrimEqPred doesn't. Who to believe and what are the pitfalls?

mkReprPrimEqPred has the same properties here; the comments should be better.

> 
>Refl# :: forall k (a b :: k). a ~# b -> a :~:# b
>Refl# = \@k @a @b v -> v `cast` Sym (N::~:# k)  
> 
> Is this valid? You say that v has to be bound as a CoVar (current
> newtype machinery will not do this). Can a CoVar appear in the LHS of
> a cast?

No, it can't. This may be a real blocker. I hadn't thought about this part of 
the problem.
> 
> 
> `cast` Sym (N::~:# k)  
> 
> Is this valid?

No, for the same reasons.

This is unfortunate, as I thought this was a good idea. Yet I'm not hopeful 
that there's an easy way out of this particular trap.

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

Re: Plan for GHC 9.2

[Ben Gamari]

Roland Senn  writes:

> I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi
> debugger it adds the possibility to set ignore counts to breakpoints.
> The next  times the break point is reached the program's
> execution does not stop. This feature is available in nearly every
> debugger, but until now not yet in the GHCi debugger.
> Merge request !4839 is ready for review  (and it's NOT rocket
> science...) 
>
Indeed, this seems quite reasonable. I don't see any reason why we
shouldn't be able to get it in to 9.2.1.

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: Plan for GHC 9.2

[Roland Senn]

I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi
debugger it adds the possibility to set ignore counts to breakpoints.
The next  times the break point is reached the program's
execution does not stop. This feature is available in nearly every
debugger, but until now not yet in the GHCi debugger.
Merge request !4839 is ready for review  (and it's NOT rocket
science...) 

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

Re: Find the ghc binary path from libdir

[Daniel Gröber]

Hi Fendor,

On Mon, Feb 08, 2021 at 08:08:45PM +0100, Fendor wrote:
> Basically, we want to know which `ghc` version `cabal-install` is going to
> pick for compiling the project in a platform independent way without
> resorting to linking to `Cabal`.

For v2-build this can be found out by looking at plan.json for which you
only need to link to cabal-plan (or a json lib of your choice).

You do need to have logic run `cabal --dry-run` (IIRC) to generate
plan.json if it's not there. I have some code for that in cabal-helper,
it's not very tricky as long as you're assuming the cabal project isn't in
a broken state anyway.

> You can execute `cabal exec -- ghc` which launches the correct `ghc`
> version, but as far as we found out, there is no programmatic way of finding
> the path to the `ghc` executable itself (`cabal exec -- where ghc` or `cabal
> exec -- which ghc` fails on windows). 

Seems to me it would be relatively straightforward to add a "which" mode to 
whatever executable you're shipping (we're talking about hls, right?) so you 
can do something like:

cabal exec -- $path_to_hls which

which then just prints the path to GHC on PATH found using the appropriate
library function without running into the problem of not having `which` on
windows.

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

RE: Stop holding hadrian back with backwards compatibility

[Simon Peyton Jones via ghc-devs]

build with hadrian, and then continue using make with the artifacts (partially) 
built by Hadrian

I agree this is a non-goal.

Simon

From: ghc-devs  On Behalf Of Moritz Angermann
Sent: 10 February 2021 13:32
To: Richard Eisenberg 
Cc: ghc-devs 
Subject: Re: Stop holding hadrian back with backwards compatibility

My understanding of this backwards compat logic is that it's only there to 
allow you to do stuff like:
build with hadrian, and then continue using make with the artifacts (partially) 
built by hadrian.  I think
this is a horrible idea in and onto itself, even if I can somewhat see the 
appeal as a gateway drug; in
which you'd slowly have hadrian take over parts that make used to do, and use 
make for the stuff that
doesn't work (yet) in hadrian.

However, I don't think the benefit of constraining hadrian to work in the make 
framework makes much
sense. We should be permitted to explore new (and better) solutions, that do 
not align with how the
make based build system did things if it allows for a less complex build system 
or faster builds or ...

Cheers,
 Moritz

On Wed, Feb 10, 2021 at 9:28 PM Richard Eisenberg 
mailto:r...@richarde.dev>> wrote:
This sounds very reasonable on the surface, but I don't understand the 
consequences of this proposal. What are these consequences? Will this break 
`make`? (It sounds like it won't, given that the change is to Hadrian.) Does 
this mean horrible things will happen if I use `make` and `hadrian` in the same 
tree? (I have never done this, other than with hadrian/ghci, which seems to 
have its own working directory.) Basically: for someone who uses the build 
system but does not work on it, how does this affect me? (Maybe not at all!)

I would explicitly like to endorse the direction of travel toward Hadrian and 
away from `make`.

Richard

> On Feb 10, 2021, at 8:05 AM, Moritz Angermann 
> mailto:moritz.angerm...@gmail.com>> wrote:
>
> Hi,
>
> so we've finally run into a case where we need to bump the rts version.  This 
> has a great ripple effect.  There is some implicit assumption that rts-1.0 
> will always be true. Of course that was a lie, but a lie we lived with for a 
> long time.
>
> Now, hadrian tries *really* hard to replicate some of the Make based build 
> systems idiosyncrasies, this includes creating versionless symlinks for the 
> rts. E.g. libHSrts -> libHSrts-1.0. There is a great deal of logic just 
> to achieve this, and of course it all crumbles now.
>
> I'd therefore like to float and propose the idea that we agree to *not* 
> bother (too?) much with make based build systems backwards compatibility and 
> warts that grew over the years in the make based build system with hadrian 
> going forward.
>
> Yes, I can probably fix this, and add even more code to this burning pile of 
> complexity, but why?  The next person will assume libHSrts does not need to 
> be versioned and continue with this mess.
>
> Let's have Hadrian be a clean cut in some areas (it already is, it does away 
> with the horrible abomination that ghc-cabal is--which only serves the 
> purpose of translating cabal descriptions into make readable files), and not 
> be bogged down by backwards compatibility.
>
> This is thus my call for voicing concern or the upkeep of legacy support, or 
> I'll take silence as the collective support of making hadrian *not* be held 
> back by backwards compatibility. (This would mean in this case, that I'd just 
> delete the backwards compat code instead of adding even more to it).
>
> I hope we all still want Hadrian to replace Make, if not and we want to keep 
> Make, why are we concerning ourselves with Hadrian in the first place. If we 
> are intending to ditch Make, let's not be held back by it.
>
> Cheers,
>  Moritz
> ___
> 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: Stop holding hadrian back with backwards compatibility

[Moritz Angermann]

My understanding of this backwards compat logic is that it's only there to
allow you to do stuff like:
build with hadrian, and then continue using make with the artifacts
(partially) built by hadrian.  I think
this is a horrible idea in and onto itself, even if I can somewhat see the
appeal as a gateway drug; in
which you'd slowly have hadrian take over parts that make used to do, and
use make for the stuff that
doesn't work (yet) in hadrian.

However, I don't think the benefit of constraining hadrian to work in the
make framework makes much
sense. We should be permitted to explore new (and better) solutions, that
do not align with how the
make based build system did things if it allows for a less complex build
system or faster builds or ...

Cheers,
 Moritz

On Wed, Feb 10, 2021 at 9:28 PM Richard Eisenberg  wrote:

> This sounds very reasonable on the surface, but I don't understand the
> consequences of this proposal. What are these consequences? Will this break
> `make`? (It sounds like it won't, given that the change is to Hadrian.)
> Does this mean horrible things will happen if I use `make` and `hadrian` in
> the same tree? (I have never done this, other than with hadrian/ghci, which
> seems to have its own working directory.) Basically: for someone who uses
> the build system but does not work on it, how does this affect me? (Maybe
> not at all!)
>
> I would explicitly like to endorse the direction of travel toward Hadrian
> and away from `make`.
>
> Richard
>
> > On Feb 10, 2021, at 8:05 AM, Moritz Angermann <
> moritz.angerm...@gmail.com> wrote:
> >
> > Hi,
> >
> > so we've finally run into a case where we need to bump the rts version.
> This has a great ripple effect.  There is some implicit assumption that
> rts-1.0 will always be true. Of course that was a lie, but a lie we lived
> with for a long time.
> >
> > Now, hadrian tries *really* hard to replicate some of the Make based
> build systems idiosyncrasies, this includes creating versionless symlinks
> for the rts. E.g. libHSrts -> libHSrts-1.0. There is a great deal of
> logic just to achieve this, and of course it all crumbles now.
> >
> > I'd therefore like to float and propose the idea that we agree to *not*
> bother (too?) much with make based build systems backwards compatibility
> and warts that grew over the years in the make based build system with
> hadrian going forward.
> >
> > Yes, I can probably fix this, and add even more code to this burning
> pile of complexity, but why?  The next person will assume libHSrts does not
> need to be versioned and continue with this mess.
> >
> > Let's have Hadrian be a clean cut in some areas (it already is, it does
> away with the horrible abomination that ghc-cabal is--which only serves the
> purpose of translating cabal descriptions into make readable files), and
> not be bogged down by backwards compatibility.
> >
> > This is thus my call for voicing concern or the upkeep of legacy
> support, or I'll take silence as the collective support of making hadrian
> *not* be held back by backwards compatibility. (This would mean in this
> case, that I'd just delete the backwards compat code instead of adding even
> more to it).
> >
> > I hope we all still want Hadrian to replace Make, if not and we want to
> keep Make, why are we concerning ourselves with Hadrian in the first place.
> If we are intending to ditch Make, let's not be held back by it.
> >
> > Cheers,
> >  Moritz
> > ___
> > 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: Stop holding hadrian back with backwards compatibility

[Richard Eisenberg]

This sounds very reasonable on the surface, but I don't understand the 
consequences of this proposal. What are these consequences? Will this break 
`make`? (It sounds like it won't, given that the change is to Hadrian.) Does 
this mean horrible things will happen if I use `make` and `hadrian` in the same 
tree? (I have never done this, other than with hadrian/ghci, which seems to 
have its own working directory.) Basically: for someone who uses the build 
system but does not work on it, how does this affect me? (Maybe not at all!)

I would explicitly like to endorse the direction of travel toward Hadrian and 
away from `make`.

Richard

> On Feb 10, 2021, at 8:05 AM, Moritz Angermann  
> wrote:
> 
> Hi,
> 
> so we've finally run into a case where we need to bump the rts version.  This 
> has a great ripple effect.  There is some implicit assumption that rts-1.0 
> will always be true. Of course that was a lie, but a lie we lived with for a 
> long time.
> 
> Now, hadrian tries *really* hard to replicate some of the Make based build 
> systems idiosyncrasies, this includes creating versionless symlinks for the 
> rts. E.g. libHSrts -> libHSrts-1.0. There is a great deal of logic just 
> to achieve this, and of course it all crumbles now.
> 
> I'd therefore like to float and propose the idea that we agree to *not* 
> bother (too?) much with make based build systems backwards compatibility and 
> warts that grew over the years in the make based build system with hadrian 
> going forward.
> 
> Yes, I can probably fix this, and add even more code to this burning pile of 
> complexity, but why?  The next person will assume libHSrts does not need to 
> be versioned and continue with this mess.
> 
> Let's have Hadrian be a clean cut in some areas (it already is, it does away 
> with the horrible abomination that ghc-cabal is--which only serves the 
> purpose of translating cabal descriptions into make readable files), and not 
> be bogged down by backwards compatibility.
> 
> This is thus my call for voicing concern or the upkeep of legacy support, or 
> I'll take silence as the collective support of making hadrian *not* be held 
> back by backwards compatibility. (This would mean in this case, that I'd just 
> delete the backwards compat code instead of adding even more to it).
> 
> I hope we all still want Hadrian to replace Make, if not and we want to keep 
> Make, why are we concerning ourselves with Hadrian in the first place. If we 
> are intending to ditch Make, let's not be held back by it.
> 
> Cheers,
>  Moritz
> ___
> 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

Stop holding hadrian back with backwards compatibility

[Moritz Angermann]

Hi,

so we've finally run into a case where we need to bump the rts version.
This has a great ripple effect.  There is some implicit assumption that
rts-1.0 will always be true. Of course that was a lie, but a lie we lived
with for a long time.

Now, hadrian tries *really* hard to replicate some of the Make based build
systems idiosyncrasies, this includes creating versionless symlinks for the
rts. E.g. libHSrts -> libHSrts-1.0. There is a great deal of logic
just to achieve this, and of course it all crumbles now.

I'd therefore like to float and propose the idea that we agree to *not*
bother (too?) much with make based build systems backwards compatibility
and warts that grew over the years in the make based build system with
hadrian going forward.

Yes, I can probably fix this, and add even more code to this burning pile
of complexity, but why?  The next person will assume libHSrts does not need
to be versioned and continue with this mess.

Let's have Hadrian be a clean cut in some areas (it already is, it does
away with the horrible abomination that ghc-cabal is--which only serves the
purpose of translating cabal descriptions into make readable files), and
not be bogged down by backwards compatibility.

This is thus my call for voicing concern or the upkeep of legacy support,
or I'll take silence as the collective support of making hadrian *not* be
held back by backwards compatibility. (This would mean in this case, that
I'd just delete the backwards compat code instead of adding even more to
it).

I hope we all still want Hadrian to replace Make, if not and we want to
keep Make, why are we concerning ourselves with Hadrian in the first place.
If we are intending to ditch Make, let's not be held back by it.

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

Re: Newtype over (~#)

[Igor Popov]

That's a really interesting quirk. That kind of explains why an
argument to a cast has to be a CoVar, we want all casts to be guarded
by a case-of. But do we still need the restriction that an Id cannot
have a coercion type?

Either case it seems like we need to be extremely careful with how the
wrapper and the matcher works for such a constructor. I was hoping a
sledgehammer approach would work where we kind of just force (a ~# b)
as a field into a newtype, and the existing machinery magically works
with it.

The construction is then chock full of questions:

axiom N::~:# :: forall k. (:~:#) @k ~R (~#) @k

Is this valid? mkPrimEqPred says it doesn't like equalities on either
side (I'm assuming this applies to eta-contracted equalities as well).
mkReprPrimEqPred doesn't. Who to believe and what are the pitfalls?

Refl# :: forall k (a b :: k). a ~# b -> a :~:# b
Refl# = \@k @a @b v -> v `cast` Sym (N::~:# k)  

Is this valid? You say that v has to be bound as a CoVar (current
newtype machinery will not do this). Can a CoVar appear in the LHS of
a cast? The result is definitely a type and can be bound to an Id, I
guess.

$WRefl# :: forall k (a :: k). a :~:# a
$WRefl# = \@k @a -> Refl# @k @a @a 

Relatively tame, but however once we inline the definition of Refl#
(simpleOptExpr will do this when registering an unfolding), we get:

 `cast` Sym (N::~:# k)  

Is this valid?

The matcher/boxer (is that the word) has to be carefully constructed
as well: we have to desugar

case x of Refl# -> e

where (x :: a :~:# b) into:

case x `cast` N::~:# k   of
co -> e

where co is now a CoVar. Can a cast's result type be a coercion? Can a
coercion be the scrutinee of a case-of? (Judging by the code we
generate for eq_sel the answer is yes).

-- mniip


On Sun, Feb 7, 2021 at 7:41 PM Richard Eisenberg  wrote:
>
> We do need a separate category, though: otherwise, we could cast by `f x`, 
> where `f` is a non-terminating functions. We erase casts, so the function 
> would never get called. Maybe if we required that casts are always by 
> variables (essentially, A-normalize casts) we could avoid this? But then 
> would we require A-normalization to build coercions from pieces (as opposed 
> to calling functions)? It's unclear.
>
> I think the first versions of this idea didn't require the separate syntactic 
> category, but all work for the past decade has. I think there are other ways, 
> but the way GHC handles this now is somewhat poor, because of #17291.
>
> Richard
>
> > On Feb 5, 2021, at 7:56 PM, Igor Popov  wrote:
> >
> >> GHC cheats in this area. The problem is that (a ~# b) is a type, because 
> >> that is terribly, terribly convenient. But it really shouldn't be.
> >>
> >> The problem is that coercion variables are different from regular 
> >> variables. So, if we say (v :: a ~# b), we must always be careful: is v a 
> >> coercion variable or not? If it isn't, then v is useless. You cannot, for 
> >> instance, use v in a cast.
> >
> > I don't really see a problem here. The fact that only a "coercion
> > variable" can be used in a cast should be enforced by the typing rule
> > for cast. That doesn't require having a distinct "syntactic category"
> > of coercion variables, unless I'm missing something.
> >
> > -- mniip
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.10.4 released

[Jens Petersen]

On Sun, 7 Feb 2021 at 00:17, Ben Gamari  wrote:

> The GHC team is very pleased to announce the availability of GHC 8.10.4.
>

Thank you!

This is now already built for Fedora and can be tested/installed with:

dnf --enablerepo=updates-testing-modular module install ghc:8.10/default

It should go stable after one week (after which you don't need the
--enablerepo option).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs