ku-fpg / hermit-shell

HERMIT with GHCi shell
BSD 3-Clause "New" or "Revised" License
2 stars 0 forks source link

Remote GHCi #41

Open xich opened 8 years ago

xich commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.