As I’ve been using Haskell Playground more frequently, especially from my phone, I’ve been doing spinning some code snippets to test things out like I would if I had GHCi to show to other people. It reminded me of how the haskell IRC channel had a bot that allowed people to run GHCi REPL live, and get interactive results.
I thought it would be a neat idea to allow a GHCi repl to run on the playground, and a decent usecase is sharing a GHCi session for other people to experiment with.
I’ll be the first to mention that it’s most likely more effort than I’m realizing, and for a good number of usecases, you can kind of replicate them without needing GHCi. Even for some usecases that don’t, you could likely just link to something like Hoogle for type signatures or Hackage, but I’m still thinking it might be useful, I’m just wondering if otber people are interested in such a thing.
I remember this was asked at a presentation by @tomsmeding about the playground. I think the main problem was that keeping a GHCi session alive would be too expensive. You would need to keep a copy of GHC in memory for every user. It ended up being a kind of brainstorm session considering using MicroHs or the WASM backend. I guess now the WASM backend should be stable enough to run a GHCi session on the client side. Although sharing the GHCi state between users sounds difficult.
Perhaps so, but I’m really interested in onlije GHCi sessions even if it’s on a different site (it doesn’t need to be the Haskell Playground that does it). I did see the WASM thread earlier, that was why I thought about making this one.
No, it was just some brainstorming. I love to think about PL implementation details like these, but, to be honest, I don’t have that much motivation (or time) to really implement something.
It would be cool to do it like how Godbolt.org does (it’s a compiler assembly analyzer).
They encode all the input file contents (no matter how long it is) into one massive urlencoded URL query parameter, and that’s the permalink. When you share the full link, there’s zero input session state stored on the server.
For convenience, they can also create a short link for you if you tick a box when sharing, which a few years back worked by using goo.gl’s link shortening service, and nowadays they self-implement it as:
lookup table of short link→hash(document)
Find document in S3 where filename=hash
Honestly, I think GHCi session data are probably much shorter than typical Godbolt input sizes and can afford to be encoded without a shortener. A JSON array of strings, one for each input line, and urlencoded and put in the URL would probably work. Then when someone opens the link, it will replay all inputs one line at a time on their local browser’s GHCi session.
Thanks for mentioning me, @jaror. While it would be cool to have GHCi available on the playground, there are some things to think about indeed:
There is the wasm-based playground which invokes GHC; not sure if it can also do GHCi, but as I recall it was using the interpreter anyway so that may not be the biggest technical obstacle.
It does involve a 50 MB download, tough – 1.2 MB for bsdtar.wasm and 49 MB for rootfs.tar.zst, if I look in my browser console. I don’t want to force this on anyone, so the main playground setup is not going to change, but perhaps it would be acceptable specifically for running an in-browser GHCi session.
The playground allows saving and sharing code snippets; I did consider putting a compressed representation of the code in the URL, but the URLs become way too long to be practical for the purposes for which I want the playground to be useful. So it would have to be saved on the server anyhow.
I don’t want to save program output in the database because that can be, and regularly gets, large; thus we’d store only the inputs to GHCi and we’d have to replay them, as @yutotakano said. This may not be such an issue, but it forces the 50 MB download on not only the author of the paste, but also on anyone who wants to see it.