- User Since
- Mar 28 2016, 7:32 AM (124 w, 5 d)
Jul 12 2018
The tests are now passing. I still need to deal with type families, data families, and levity-polymorphic newtypes.
- UnliftedNewtypes works on vanilla newtypes and GADT-style newtypes
Good to know. Locally, I've changed decideNewtypeKind to not use isNewTyCon, and this looks like its working now. I've still got a ways to go, but at least vanilla newtypes look like they are behaving correctly.
Jul 11 2018
I've realized that I must horribly misunderstand what exactly isNewTyCon does. Either that, or I've messed up something else pretty badly. In the test suite, recall that I have a newtype named Darth:
Jul 5 2018
Sorry. This was created by accident. Anyone who can close or delete this should feel free to do so.
Rebase and stop inferring cusk when unlifted newtypes are used without a kind signature
Jul 4 2018
I've made some more changes. There was a check for undetermined type variables that I had to disable to get past the error I mentioned previously. However, now, when the test suite is run, GHC think that Foo, Darth, and Pat have kind TYPE 'LiftedRep. So, somewhere in the typechecker, those kind variables are getting unified with TYPE 'LiftedRep before I get a chance to unify them with the kind of the underlying type. Alternatively, it's possible that my attempt to unify them with the kind of the underlying type doesn't actually work and they get unified with TYPE 'LiftedRep at some point after this.
- suppress undetermined-type-variable when UnliftedNewtypes is on. still not working, but closer
Jul 3 2018
I'm pretty sure you don't need a bang pattern on acc when you use foldl'. Also, <> is preferable to mappend here, since SMP has happened.
Jun 25 2018
I'm now getting the following error in stage2:
- try unifying newtype kinds differently
Jun 4 2018
I've added a function decideNewtypeKinds. I thought it would eliminate the kind variables introduced by newMetaKindVar (by unifying it with the kind of the type inside of the newtype), but it does not work as I expected.
- tried to get the fresh kind variable to unify with the kind of the type inside the newtype. it did not work correctly.
Maybe I just need to modify kcTyClDecl. One thing that isn't clear to me is how to tell GHC that I want to attempt to unify two kinds. I think that should be all I need to add to kcTyClDecl.
I'd like some confirmation that I'm on the right path. This code doesn't currently work for anything except GADTs with a kind signature, and even for those I think it accepts bad programs. I'm trying to support kind inference when the user writes something like:
- generate fresh kind variable for newtypes
Jun 3 2018
- improve test for UnliftedNewtypes
- add test for gadt without kind sig
All I've done so far is allow newtypes (vanilla or GADT-style) over types that are not kinded TYPE 'LiftedRep. Things from the proposal that I still need to implement and test are:
Diff against the correct commit.
Mar 26 2018
Mar 25 2018
Mar 8 2018
Looks good to me. Thanks for doing this!
Mar 6 2018
- nearly correct implementation
Mar 5 2018
I've clarified where the note is found.
- clarify in what file Word Hex Literals note is found
I've improved the documentation around the new code. Simon, let me know if this adequately addresses your comments.
- improve documentation of -dword-hex-literals in source code
Mar 4 2018
I should probably mention the effect on error messages in the user manual as well.
document -dhex-word-literals in ghc user manual
I've added a note to the description about the effect on error messages.
That’s a good point about having an effect on error meassages. Let me know if I should change this behavior or if I should leave it as is.
Mar 3 2018
As an example of what this does, consider the following haskell file Literals.hs:
Feb 8 2018
Checked off more boxes.
Everything's been done. Thanks for the thorough review Ryan!
- put a period at the end of the docs for defaultComparison
Checked off more changes.
I've implemented most of requested changes. As I was checking them off, I realized there were several that I missed, so I'm going to push another differential addressing those.
update manual, update changelog, use more GND and more laziness, update to fit into the post-Semigroup-Monoid-Proposal world
I think I finally got the differential right. Third time's a charm.
Update the differential to start at the first commit.
Move Data.Functor.Contravariant from the contravariant package to base.
Aug 25 2017
If it does blow anything up, I'll find out soon.
Mar 28 2016
Ah, I was running arc diff HEAD^ and arc diff --update D2051 HEAD^. That explains it. Thanks!
Rebased again, added trac number to changelog
Thanks for the helpful explanation. I've messed up the diff again, so I'm going to fix that. It seems like I need to rebase and squash all my commits every time I make a change. Is that the typical workflow when using phabricator/arcanist, or does one of those tools have a feature that can automatically rebase for you?
Added docs for Proxy's new instances
@RyanGlScott I've squashed the commits, so now it looks like the right diff is showing up in phabricator. Also, I've added to the changelog.
Squashed commits to make the right diff show up in phabricator. Also,
add an entry to the changelog.