Playground on haskell.org?

[hasufell]

Everyone else has it, e.g. https://play.rust-lang.org/ ...I don't remember if the HF has a task force for that.

There already are open source implementations: https://github.com/google/codeworld (live here https://code.world/haskell).

I believe codeworld could possibly be adjusted a bit and added as a subsite. Some features Haskellers find interesting (e.g. which GHC version to pick) could be added.

@cdsmith @simonmichael @Kleidukos

[cdsmith]

You would be absolutely welcome to use the CodeWorld back end for this. The API is pretty simple: you just send a post to https://code.world/compile with multipart form fields { mode: "haskell", source: "..." }. The response will contain two hashes in a JSON object: { "dhash": "D11111111", "hash": "P22222222" }. The response code will be 200 on success, and 400 in case of error.

Now:

• To get compiler output, send a POST to https://code.world/runMsg, with multipart form fields { hash: "P22222222", mode: "haskell" }
• To run the code (assuming /compile gave a 200 response), load this URL into an iframe in the browser: https://code.world/run.html?dhash=D11111111&mode=haskell

When running the code, to capture console output in the parent frame, you want something like this:

window.addEventListener('message', (event) => {
  if (event.type === 'consoleOut' && event.msgType === 'log') {
    normalStdout(event.str);
  } else if (event.type === 'consoleOut' && event.msgType === 'error') {
    errorMessage(event.str);
  }
});

That should be all there is to it. Unfortunately, stdin is not currently implemented. I'd be happy to accept a patch to implement it.

You can also POST to https://code.world/errorCheck with the same form contents as https://code.world/compile, and get back the status code (200 or 400) and GHC error messages. This invokes GHCJS with -fno-code, so it's far more efficient, and is designed to be run every few keystrokes to update highlighting of error messages if the front end supports such a feature.

[hasufell]

@cdsmith excellent. Are you suggesting we should implement a different frontend?

[tomjaguarpaw]

We already have a sort of "playground" on the front page, but I don't know how it works or what it is capable of. Can anyone elaborate on the difference between what we have and where we should aim to get to?

See also #162

[hasufell]

We already have a sort of "playground" on the front page

Yeah, well. I think that's nowhere near what a proper playground supports:

1. an actual editor with lines
2. a way to share code snippets and run them
3. a way to pick which GHC version is used to compile
4. possibly typechecking during typing (or even integrated HLS support)
5. maybe formatting functionality (e.g. via brittany)

[tomjaguarpaw]

Thanks, those features sound great. In terms of getting there is the best course of action to replace what we have with something CodeWorld-based?

[hasufell]

@tomjaguarpaw I guess.

@cdsmith how hard is it to support multiple GHCs?

[cdsmith]

@hasufell It would be fine to use the existing front end, as well, but I wouldn't have the time to offer any help in adapting it to fit into a different web design. It's also not the cleanest bunch of code in the world!

Multiple GHCs isn't something that's likely to happen with CodeWorld, nor is HLS integration. Both of these things would probably require rebuilding the back end using some kind of virtualization technology, and that's not something I'd be able to do right now.

[hasufell]

@hasufell It would be fine to use the existing front end, as well, but I wouldn't have the time to offer any help in adapting it to fit into a different web design. It's also not the cleanest bunch of code in the world!

Multiple GHCs isn't something that's likely to happen with CodeWorld, nor is HLS integration. Both of these things would probably require rebuilding the back end using some kind of virtualization technology, and that's not something I'd be able to do right now.

Can you give me some code pointers to the backend where the ghc process lives? Maybe I'll find a quick solution.

[cdsmith]

GHCJS is installed at https://github.com/google/codeworld/blob/master/install.sh#L216

The code to actually invoke it is here: https://github.com/google/codeworld/blob/master/codeworld-compiler/src/CodeWorld/Compile.hs#L257

Thinking this through now, it wouldn't require any kind of virtualization. It's just that GHCJS is so darned difficult to build. I have cobbled together enough (including some local patches) to reliably build a GHC 8.6 version that works for me. That's definitely too old, but it's a daunting prospect to try to upgrade and deal with potential new bugs and such. You're not going to get 9.2, in any case, because GHCJS just lags behind too far for that. But I think it's definitely possible to build 8.10 now.

[ulysses4ever]

The current solution is very limited, to the point where I'm not sure it serves any purpose except for a decorative one. Even the primes example featured so prominently on the same index page is impossible to fit in the current REPL there. Imho, the current state of affairs hurts more than it helps.

Code.World is a great project but with a very targeted design in mind (which is great!) that won't fit in the use case that one would hope for, as you already mostly identified.

Implementing something from scratch (or based on similar solutions on the web) is a big endeavor. Maybe having it on the list of things that Haskell Foundation volunteering program can take up would be a good thing. But this is likely a long term goal.

Short-term, I think, the best way to proceed would be to

1. scrap the current thing (it's more harmful, as I express above),
2. add a prominent link to repl.it
3. add a project for implementing a more specialized solution than repl.it to some list (HF or something).

[cdsmith]

@ulysses4ever I don't think this is necessarily a terrible idea, actually. Mainly, the bits of CodeWorld that are targeted toward children are disabled when you use Haskell mode, which my instructions above do.

I agree there are some things about CodeWorld that are not ideal. Chief among them is the difficulty of supporting more GHC versions because the architecture depends on GHCJS. The plan is for GHCJS to be merged into mainline GHC starting in 9.6, so I'm optimistic that this is a limited-time disadvantage.

In any case, my opinion remains that I'm happy to offer the CodeWorld backend for such a project if it's helpful, and I think it's a reasonable choice. I'll happily advise on choices, and review, merge, and deploy changes promptly, to make the experience better. I just cannot do a lot of the development myself.

Other weaknesses to keep in mind:

1. CodeWorld currently doesn't have multi-module support. This could definitely be added, though. In fact, if someone were building a new front end anyway, it's considerably easier to add multi-module support in the CodeWorld back end versus in the front end.
2. CodeWorld doesn't allow TH in user code, nor does it allow GHC plugins. There are ideas for how to allow this by proxying the TH external interpreter to the web browser, but it's a bit ambitious.
3. HLS remains pretty far-fetched. CodeWorld's architecture just isn't set up to have persistent GHC API sessions. However, for code of reasonable sizes, it's surprisingly usable to just run ghcjs -fno-code any time you stop typing for a couple seconds and flag errors. I'm a huge fan of HLS for larger projects, but it need not block deploying something here.

[simonmichael]

To clarify requirements, what high level goal(s) / target audiences do you have in mind @hasufell ? Eg how important is multiple GHC versions in a web browser, how would this be presented, what should visitors be able to accomplish, should non-FOSS apps like (AFAIK) repl.it also be considered ?

play.rust-lang.org looks very like code.world/haskell, without the docs, and with more choices interesting to compiler developers, such as compiler version and compilation stage. Would a link/redirect/proxy from [play.]haskell.org to code.world/haskell be a good quick first step ?

[hasufell]

To clarify requirements, what high level goal(s) / target audiences do you have in mind @hasufell ? Eg how important is multiple GHC versions in a web browser, how would this be presented, what should visitors be able to accomplish, should non-FOSS apps like (AFAIK) repl.it also be considered ?

I already made a list in a previous comment: #185 (comment)

I'd consider the first 3 points to be the starting point. If you've done some experiments locally and on e.g. GHC 8.6.5 and want to share the compileable snippet, 9.2.2 will cause a lot of compile errors you don't care about. So this would be important for generic playground.

I don't consider repl.it an alternative, nor would I encourage its use on haskell.org.

play.rust-lang.org looks very like code.world/haskell, without the docs, and with more choices interesting to compiler developers, such as compiler version and compilation stage. Would a link/redirect/proxy from [play.]haskell.org to code.world/haskell be a good quick first step ?

Dunno, maybe.

[hasufell]

I think my idea would be to create a simple backend that's merely a shim around invoking ghc-<ver> executed via bubblewrap for security and using prlimit for resource limits.

The frontend could be mostly stolen from codeworld or rust playground.

[simonmichael]

Those are technical goals, nothing wrong with those but what might some higher-level objectives be ? I'll brainstorm:

• Increase Haskell's adoption rate by making it more approachable/hip/inviting for coders ?
• Lower Haskell's learning curve by providing a more prominent, easier, no-install playground perhaps with tutorials/learning aids attached ?
• Improve the Haskell community's efficiency by providing a more powerful super-pastebin ("hsfiddle") for sharing/collaborating/support ?

[simonmichael]

I don't consider repl.it an alternative, nor would I encourage its use on haskell.org.

Could you say why ?

[hasufell]

but what might some higher-level objectives be

Making Haskell great again.

[hasufell]

I don't consider repl.it an alternative, nor would I encourage its use on haskell.org.

Could you say why ?

I'm not sure if it's open-source and what I've seen so far it has a very different scope, with version control features and whatnot. What I'm thinking about is a simple backend with a neat fronted, much like the rust playground and having access to all existing GHC versions. repl.it doesn't seem to provide that either. So something in between the simplistic version on haskell.org and the feature-creep of repl.it. Something that the community can reasonably maintain.

[soupi]

It might be possible to fork https://try.purescript.org to support a Haskell backend such as the one provided by code.world without too much work.

[hasufell]

@tomsmeding implemented a playground via bubblewrap as suggested: https://github.com/tomsmeding/pastebin-haskell/tree/play

We're currently trying to improve the editor: tomsmeding/pastebin-haskell#15

[hasufell]

@tomsmeding what's your opinion on having a redirection from https://play.haskell.org to https://play-haskell.tomsmeding.com/ and then advertise it on the front page?

I think redirection might be easied for now. Moving servers can be considered when/if this is approved.

People have been asking about this again, but haskell.org development is mostly stagnant.

https://discourse.haskell.org/t/haskell-playground-on-haskell-org/5227

[tomsmeding]

@hasufell Yes that would be awesome :)

There is still a bunch of stuff that I'd still like to do on the playground, but due to a combination of stuff I've had zero time for it since August. I hope that later this autumn I'll be able to do some development on it again.

We'll see whether my current small server can hold the traffic. I expect it to hold easily, but who knows.