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.
Feb 14 2019
Jan 20 2019
Yes, I would like to finish this.
Jan 4 2019
Jan 3 2019
Dec 21 2018
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#?
Dec 6 2018
Dec 5 2018
You seem to have accidentally reverted everything.
Nov 13 2018
Thanks for taking care of this!
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.
Oct 9 2018
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.
Oct 8 2018
Oct 5 2018
The small type optimization is low priority. I realized we never use dataToTag# for small types in Ord deriving anyway!
Oct 4 2018
Sep 17 2018
Sep 14 2018
@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
Sep 10 2018
I had to make some changes. Could someone please have another look?
Sep 9 2018
- Hopefully this is the last
The StableName type in base needs to go back to having a representational parameter. The stable-maps package relies on that for safety.
Aug 30 2018
Aug 29 2018
- Don't bother trying to deprecate the C stuff. It seems tricky.
Aug 28 2018
- 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?
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?
Aug 27 2018
- Document unsafe stable pointer operations
- Document unsafe stable pointer operations
I've folded this into D5084.
Fix up the comparison business
Aug 24 2018
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.
Aug 23 2018
Aug 22 2018
@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?
Aug 21 2018
I should also split includes/rts/Stable.h. That's pretty trivial.
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.
Aug 20 2018
@osa1, I don't know of a ticket, but there's an accepted GHC proposal.
Aug 19 2018
Aug 3 2018
Aug 2 2018
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.
Jul 26 2018
Jul 21 2018
Jul 18 2018
@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.
Jul 17 2018
@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).
Jul 16 2018
Remove module import cycle
Fix module name; add documentation.
It doesn't look like this compiles.
Did you consider using GHC.Event.PSQ instead?
Jul 15 2018
Jul 14 2018
Jul 13 2018
- 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'
Jul 12 2018
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.
Jul 11 2018
Fix atomicModifyIORef' strictness