Skip to content
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

Remote GHCi #41

Open
xich opened this issue Jan 15, 2016 · 3 comments
Open

Remote GHCi #41

xich opened this issue Jan 15, 2016 · 3 comments

Comments

@xich
Copy link
Member

xich commented Jan 15, 2016

Has anyone been following Simon's work here:

https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi

I was going to try and catch up with what is going on there so I can talk to him about it next month when I see him, but I was wondering if anyone had thoughts on how it relates to what you did with hermit-shell... is there some limitation that would prevent us from using it?

(Not to discount the remote monad work, but this seems like a path to full haskell in the shell.)

@ecaustin
Copy link
Contributor

My recent re-interest in hermit-shell is because I've been toying with an extension of the remote monad design pattern that uses the hint package server-side in an effort to eliminate the use of external dictionaries.

This seems like Simon is taking that a step further by building a remote monad like thing directly into GHC's RTS, which I like. The communication is via binary serialization over pipes instead of JSON over the network, but the basic idea is the same from what I can tell.

Assuming that the exposed API is robust enough to spawn just the "server" side of remoteGHCI, we should be able to use that in partnership with any client we want, right?

Also, this was born out of the GHCJS team's efforts to get Template Haskell to work with their compiler right? Any idea how much of that code was inherited?

@xich
Copy link
Member Author

xich commented Jan 16, 2016

Assuming that the exposed API is robust enough to spawn just the "server" side of remoteGHCI, we should be able to use that in partnership with any client we want, right?

Yeah, that is my hope. We could just build hermit-shell against that server API. As for network/JSON, my thought was to write a sort of shim client that just wrapped the binary and sent it over the network. Then you could have ghci on a different machine.

Also, this was born out of the GHCJS team's efforts to get Template Haskell to work with their compiler right? Any idea how much of that code was inherited?

As I understand it, he started with the GHCJS TH implementation and fleshed it out... this is motivated by our desire to performance profile stuff.

I'll have to look into hint...

@ecaustin
Copy link
Contributor

hint is sweet. I was really struggling with figuring out a way to serialize conversion nets for HaskHOL when it hit me that I could just store the conversion names, pattern terms, and requisite modules as pseudo-closures that could be dynamically called by hint at the time of rewriting.

I should probably write that stuff up, but I haven't really found the time to do so.

See the following modules for implementation details if you're curious:
https://github.com/ecaustin/haskhol-core/blob/master/src/HaskHOL/Core/State/Monad.hs
https://github.com/ecaustin/haskhol-deductive/blob/master/src/HaskHOL/Lib/Simp.hs
https://github.com/ecaustin/haskhol-deductive/blob/master/src/HaskHOL/Lib/TypeQuant/Context.hs

runHOLHint, unCConv, and extendBasicConvs are the key functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants