In D4777#151783, @andrewthad wrote:

Also, concerning the panicing example that Ryan gave:

newtype Foo rep = MkFoo (forall (a :: TYPE rep). a)
-- Commenting out the instance below makes the panic go away
deriving stock instance Eq (Foo LiftedRep)

The definition of Foo should never be accepted to begin with. GHC rejects newtypes with existentially quantified type variables. Consider that the following would be rejected:

newtype Bar = Bar (forall (a :: TYPE 'LiftedRep). a)

Foo should be no different, especially since Foo is just a generalization of Bar.

Yes, I would like to finish this.

What I'm suggesting is that after type checking, we should be able to
translate a rule with coerce on its LHS into a rule using coerce#
instead. Then it'll match anyway.

I didn't think about RULES. Whoops. We already have some special magic for coerce on rule LHSs. We presumably want to apply the same magic to both coerce# and coerce there.

I would put it in Data.Coerce rather than GHC.Exts. It fits there
perfectly, and the module has no troublesome dependencies. You can
re-export it from GHC.Exts.

I could easily see myself using type application with coerce (and I may
well have done so in the past). Making the common case (Type) more
verbose seems a bit unfortunate. And having that asymmetry between coerce
and unsafeCoerce seems a bit weird.

To avoid a breaking change, why leave the type of coerce alone and make a levity-polymorphic coerce#?

You seem to have accidentally reverted everything.

Thanks for taking care of this!

In D5315#146815, @sgraf wrote:

Of course. I realised that we ''might'' want to consider sticking to brackets instead of braces, but on the other hand this would severely clash with how lists are formatted.

We still support i386? Intel stopped manufacturing those in 2007, and
many/most/all embedded system manufacturers stopped using them once stocks
ran out. I believe the same is true of the 486.

The small type optimization is low priority. I realized we never use dataToTag# for small types in Ord deriving anyway!

• Continue

• Continue

Typo

• Skip CI

@simonmar, I reverted all that fancy machinery that turned out to be rather silly. I also split this into two commits: one for the type role change and one for the comment wibbles. Could I get another accept mark?

• Split differential; rebase; revert silliness

I had to make some changes. Could someone please have another look?

• Hopefully this is the last

• Silly me

• Typo

• Don't go quite so far

• Don't go quite so far

The StableName type in base needs to go back to having a representational parameter. The stable-maps package relies on that for safety.

Rebase

• Update release notes

• Formatting wibble

• Silly syntax error

• Don't bother trying to deprecate the C stuff. It seems tricky.

• Remove outdated comment

@simonmar, based on @bgamari's understanding and my own, I've removed the code to lock and unlock the stable name table during GC. If that's wrong, let me know. I've also updated the FFI names and added deprecation attributes for gcc and clang. Is there anything more to do here, or can we get this little business over with?

• More cleanup

Also, it appears that GCC, clang, and at least some other C compilers support a __deprecated__ attribute that we should be able to use. Should I just boldly use it, or should I try to use CPP somehow to check if the compiler supports it?

@simonmar, I'll get those FFI names sorted. My remaining question is whether we need to lock the stable name table for GC, or only the stable pointer table. The code doesn't explain why the garbage collector locked the stable tables. Is that because there could be C code hoping to free stable pointers while GC is in progress, or is there another reason?

• Document unsafe stable pointer operations

• Document unsafe stable pointer operations

Rebase

I've folded this into D5084.

Fix up the comparison business

I put the FFI functions back, with the same names, but only locking and unlocking the stable pointer table, since there's no other FFI access to the stable name table. I also split the last little header file that held these tables together.

• Clean up

@bgamari, what do you know about the FFI bits I tentatively removed? Should I put them back (locking and unlocking both tables)? Should I (alternatively or in addition) add the ability to lock and unlock the tables separately?

I should also split includes/rts/Stable.h. That's pretty trivial.

In D5081#139534, @simonpj wrote:

You surely need a long Note to explain the moving parts here :-). See the email thread.

Eg what do the entires in the stable name table actually look like? What's this fixedHdrSizeW offset doing? It's all very mysterious

Well, it certainly looks like it works. I checked that there are indeed some tests that exercise the stable name mechanism, but it would still be nice if one of the people who has worked on it could confirm that this is really valid.

@osa1, I don't know of a ticket, but there's an accepted GHC proposal.

Much better!

I think there should also be one or two tests that don't rely on all the details of this particular case. To begin with, there should surely be a simple example of defining the same recursive function twice with different names.

In D4967#137105, @simonmar wrote:

@Phyx should have a look at this. Also, can you run a benchmark? It's easy to make things theoretically faster but practically slower.

I believe there were people working on porting the IO manager to Windows which would presumably make this redundant, but I'm not sure what the status of those efforts is, perhaps @Phyx knows.

@simonmar, I see what you likely mean about the PSQ implementation now: it has the advantage of being specialized to fixed-width priorities. We could probably find/create something similarly appropriate for the Windows module, but I don't have the time to invest in it right now (note: we'd need something with a merge operation to maintain the current behavior; the PSQs here don't currently have one).

Another fixup

Fix -Wall

Remove module import cycle

Fix module name; add documentation.

In D4967#136826, @simonmar wrote:

It doesn't look like this compiles.

Did you consider using GHC.Event.PSQ instead?

• Restore original semantics

I've restored the original semantics for now. We can revisit that later. The latest version is less aggressive, but at least shouldn't have the earlier regression.

I just realized my last change makes a slight semantic difference, but one I expect is probably tolerable. With the old version,

@simonmar, I realized last night that my nice, simple definition of atomicModifyIORef' could lead to extra thunks in certain cases. I believe I've cleaned that up, but I'd appreciate a second look.

• Tweak the definition of atomicModifyIORef'

In D4884#136463, @simonmar wrote:

For atomicSwapMutVar# it looks like we don't have the right primitive in Cmm yet, namely %xchg. I suppose we could defer that for a separate diff?

What testing do we have for atomicModifyIORef and friends? It would be good to have some tests to check the strictness properties at least.

Fix atomicModifyIORef' strictness