-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get type information from the GHC API (for type class support) #269
Comments
If i can help in some small way, let me know. having a richer subset of ghc extensions / type system features + being able to target JS would really really be valuable for me. |
Cool stuff! I don't mind depending on GHC, but my worry is like you said the undocumented API. It would be nice if someone can spend some time experimenting with this. I plan to spend as much time as possible with the haskell-suite on odhac, then we can hopefully evaluate which direction Fay should go. I have the impression that haskell-suite would be nicer in the long run, but that remains to be seen. |
I'd like to volunteer to do something on this. I see what you mean about the undocumented API, but I'd naively argue that since HTE hasn't really been touched in a year and a half, then if any breaking changes were made to the GHC API that had useful effects, we'd eventually have to implement something equivalent in HTE ourselves to get the benefit of those changes if we used HTE. Does anyone have a branch I can use as a starting point? |
I agree, at this point it seems pretty unlikely that the haskell-suite will go further. I also was never against using GHC. I have to admit that I'm pretty clueless about how to get started on using the GHC API apart from what chris described above. But there are at least three ways of doing this afaics:
|
OK, here's how I imagined it would work (although I might be talking a load of rubbish, having never hacked on a compiler before): "Request type information on an ad hoc basis, this might be the easiest to get started with to validate the idea." is pretty much what I propose. For each function we export, we generate JS for every concrete type signature that it's called with. I've thought of type variables as being equivalent to c++ template arguments, where functions with type arguments are just templates, which would generate a function for each type they are used with. At the call sites, we will know the type, so we can call the correct function. This is where the GHC API comes in. I haven't really thought about actual typeclasses too much - I could write Fay code with just fine with the current implementation, but the my main blocker is the fact that functions with type variables always get treated as So far I've been hacking around with the GHC API and I've managed to delve my way into the expressions from I'm not even 100% confident that concrete types are ever resolved at any stage within GHC's compilation, and if not, we'd need to resolve type variables ourselves. Also traversing the Fay AST and the GHC AST together to extract the types seems hard. We'd then need to modify the code generation to output different functions for the different types, combining functions that happen to be identical. It seems really hard but I'm definitely up for it, depending on what else I can extract from the GHC API. I'll put something up when I have a good GHC API example working. What are your thoughts? |
Desugared output from GHC, but not sure how to find locations from it: http://lpaste.net/117909 How hard would it be to implement our own type resolution in Fay? |
With the disclaimer that I haven't implemented a type checker myself: Writing a Haskell98-compatible type checker is described and implemented in the paper Typing Haskell in Haskell. This wouldn't make us completely GHC compatible since its type system has been extended even further and is now using a constraint based solver. But it would give us type classes and more. It might also be helpful to look at purescript's typechecker. To do this I'd imagine that we'd, at least temporarily, add an extra level of annotations with types on top of the haskell-src-exts AST which right now contains name information from haskell-names. One of the problems with haskell-type-exts was that it was written before haskell-names so it had its own implementation of name resolution. As you probably concluded, trying to match the HSE AST with the output you pasted sounds really hard. I think typeclasses can be a solution to the FFI problems. We could have typeclasses with methods for transcoding values to JS/JSON and move the notion of |
Yesterday evening I started bringing the GHC API into the Fay compiler, but I realised that I might be reinventing the wheel. I'm going to try Haste in my application before I do anything else. I hope the Haste "runtime" is small enough. Thanks to looking at this I've learned more about Hindley Milner types, compilers, Haskell, and GHC. Thankyou for answering my questions so well. This has been really educational! I'd also like to say that I think Fay is really clever to actually work at all without type information. |
Spring cleaning. Lack of activity and a very big project, it's unlikely that this will happen. |
I find myself studying GHC API [1], [2]. With given module:
if we pass several flags to produce result of
we will receive output:
[1] https://wiki.haskell.org/GHC/As_a_library#Another_example |
From desugarring step the most valuable part is
as it contained exact methods for type There are two ways: either to typecheck only and to deal with [3] https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/deSugar/Desugar.hs#L271-273 |
With given modified example from wiki [1]
...and
However, top I am going to spend some time with these new concepts to make them familiar to me. |
Instead, with
[4] https://downloads.haskell.org/~ghc/8.6.3/docs/html/libraries/ghc-8.6.3/HscTypes.html#t:ModGuts |
I spent some time trying to realise, how to deal with
|
As it was described here six years ago, |
So, a while back when I first started Fay I mentioned that my first approach was to use the GHC API. Which is the first thing I wrote:
http://hpaste.org/75112
With the intention that I could get type information and such. But I couldn't see how to do that, and in the interest of expedience I gave up on type-classes and I switched to haskell-src-exts because it was better documented.
Now, looking at it again, I think it may be the answer to many problems, including:
At the start I had no idea what was required for a Haskell compiler. Now with experience it's a lot easier to pick out the key requirements.
Notice the definition of
Var
:It appears to me that it contains a name, type and a guid, even scope info. That would be useful for getting name resolution for free but still outputting useful names (i.e. the original), maybe I imagine like foo_1234 or w/e.
Notice also that the typechecked source just gives you a list of binds, and if you want other stuff, it's elsewhere:
That seems to be pretty much everything that we need.
I've also noticed in the ghc-mod package this code:
And I've tested it and it does indeed give the type information.
The downside would be that we depend directly on GHC. The other downside would be that GHC's API is highly undocumented, and the API is kind of OTT overengineered, which is miserable to use, and subject to change, so version changes would need to be ifdef'd.
Maybe this approach is a different philosophy from Fay (which depends on GHC-independent libraries like haskell-src-exts and after haskell-type-exts) and belongs in a fork or something, I don't know. But it's an approach that I will be taking seriously.
The text was updated successfully, but these errors were encountered: