search

goldfirere / ghc

Mirror of ghc repository. DO NOT SUBMIT PULL REQUESTS HERE
http://www.haskell.org/ghc/
Other
24 stars 1 forks source link

Can't build singletons >= 2 #54

Closed int-index closed 8 years ago

int-index commented 9 years ago

@goldfirere You've mentioned that this branch is out of sync with 7.10, but I think it would make sense to merge at least some changes, so that latest singletons can be built with this version of GHC. I'm currently working on some code that relies on singletons, and I think it could be improved if I could promote GADTs. I'm eager to try it.

And by the way, thank you for your awesome work.

goldfirere commented 9 years ago

I've gotten singletons to compile on this branch with only a few edits. I believe all it takes is adding a few import Control.Applicatives. But the problem should resolve itself soon enough. I expect I'll merge against ghc's master branch in the next two weeks.

What are you building with all this fancy type stuff?

int-index commented 9 years ago

I believe all it takes is adding a few import Control.Applicatives

Right, I've only got errors about the lack of <$> in Prelude. However, I thought it was only the tip of the iceberg, so I didn't attempt to fix it.

I expect I'll merge against ghc's master branch in the next two weeks.

That's great, thanks. Will the Nix build get updated automatically?

What are you building with all this fancy type stuff?

I'm building a semantic code editor (perhaps an IDE). I initially planned to write a Haskell editor, but Haskell is a big and complex beast, and GHC API isn't simple either, so I decided to use a simpler language (Morte) as a case study to refine the core principles of semantic editing. When it's done, I'll get back to Haskell.

The idea of a semantic editor is that instead of working with textual representations of programs, we manipulate the AST directly (Lamdu is a very similar project). However, when I started implementing even the basic features, I discovered that conventional AST representations are insufficient:

And of course I could've used dumb homogeneous data structures for both trees and paths, but I want static guarantees that they are well-formed according to a language description. So the language description gets promoted to the type level, and the rest of the code builds upon it. The promotion of GADTs will enable me to say more things about the language in the language description and simplify both type signatures and term-level code (and reduce boilerplate, too).

goldfirere commented 9 years ago

Very cool. Thanks for sharing. :)

I have no clue about the Nix build. @deepfire hooked my branch up with Nix. I'm quite clueless (but grateful) about it all. @deepfire? But no one should work very hard on keeping distributions of this branch alive. If all goes well, this will be merged into GHC's master in the next month or so.

Then, this branch will move on to bigger and better things: proper dependent types, making singletons obsolete.

deepfire commented 9 years ago

@goldfirere, @int-index, updating it should be a problem, once a new version is available.

vladfi1 commented 9 years ago

For me the install fails on the dependency syb-0.6. The cause appears to be that we no longer have Typeable instances for function types.

goldfirere commented 9 years ago

This branch has moved along significantly since the original post. But this failure is surprising, because syb-0.6 builds against GHC HEAD. Will look into this in the next weeks as I'm preparing to merge.

vladfi1 commented 9 years ago

I spied your commit 88d7f534dfb935bf95192bfe1d605d986d2ae514 "instance Typeable (a -> b)" and now syb compiles. Unfortunately now that base=4.9 not much else compiles. I guess I'd have to manually edit the upper bounds on base in a bunch of packages?

Edit: with --allow-newer I was able to start the installation but quickly ran into the bad interface file problem I mentioned in https://github.com/goldfirere/ghc/issues/59.

vladfi1 commented 8 years ago

Now that https://github.com/goldfirere/ghc/issues/59 is apparently fixed I tried again to install singletons. This time the install failed on the dependency th-expand-syns:

$ cabal install th-expand-syns --allow-newer
Resolving dependencies...
Configuring th-expand-syns-0.3.0.6...
Building th-expand-syns-0.3.0.6...
Preprocessing library th-expand-syns-0.3.0.6...
[1 of 1] Compiling Language.Haskell.TH.ExpandSyns ( Language/Haskell/TH/ExpandSyns.hs, dist/build/Language/Haskell/TH/ExpandSyns.o )

Language/Haskell/TH/ExpandSyns.hs:78:14: error:
    Not in scope: data constructor ‘FamilyD’
    Perhaps you meant ‘FamilyI’ (imported from Language.Haskell.TH)

Language/Haskell/TH/ExpandSyns.hs:115:11: error:
    Not in scope: data constructor ‘FamilyD’
    Perhaps you meant ‘FamilyI’ (imported from Language.Haskell.TH)
Failed to install th-expand-syns-0.3.0.6

I guess this perhaps shouldn't be surprising, since I'm using --allow-newer precisely in order to bypass the template-haskell <2.11 dependency on th-expand-syns.

Edit: installed template-haskell-2.10 with --allow-newer to get around the base=4.8.* dependency. This allowed me to cabal install singletons without --allow-newer. I now am running into an unknown error while building th-orphans. Cabal just says "Failed to install th-orphans-0.13.0" without any accompanying ghc error message.

goldfirere commented 8 years ago

There have been a lot of TH changes in this release (and they're not all quite settled). When it's settled, I can update th-desugar and then hopefully get this working again. I don't actually think singletons will need much to be changed to support the new stuff, though.

int-index commented 8 years ago

I figured it's not a GHC issue, so https://github.com/goldfirere/singletons/issues/140