Online Gleam Playground

[lpil]

One common language feature these days is an online playground. This is a website with a built in text editor where people can try out writing code in the language without having to install anything on their computer. It is useful for getting started with the language, for sharing snippets of code with others for debugging or learning, and they can also be a way of offering interactive tutorials for the language.

I think Gleam would greatly benefit from having something like this.

The upcoming JavaScript generating the backend for the compiler could be the foundation of a playground for Gleam. By two crewing the compiler to web assembly and then emitting JavaScript code we can have the full compilation and execution process happen entirely within the browser, removing the need to host and maintain a system of isolated build machines.

The Glean JavaScript backend emits ES modules, so we cannot use the eval function to evaluate them. This blog post suggests an alternative approach that could be taken with import and data URLs. https://2ality.com/2019/10/eval-via-import.html
A combination of this and some precompiled library modules hosted publicly for import by playground generated modules could be a workable strategy.

Goals

1. In browser Gleam compilation
2. In browser Glean execution
3. In browser text editor
4. Standard library importable
5. Standard out of execution presented to the user
6. Build errors presented to the user
7. Execution crashes presented to the user
8. Visual styling
9. Option to preview generated JavaScript code
10. Option to preview generated Erlang code
11. Option to save and share Gleam code
12. Tutorial workflow
13. Tutorial content

[massivefermion]

I don't think using import for code evaluation is right for this case.
Consider console.log. If you use import to evaluate it, It will just output to the browser's console. But the output should be a part of the playground.

[lpil]

I don't think we would use console.log for IO in the playground, we would want to output to screen as you've said.

How would you evaluate the JavaScript? Another option I've been playing with is to append a script to the body.

[massivefermion]

Yeah, sorry, I think I misunderstood...wait...I think I'm not quite clear on what you mean when you talk about "javascript backend" and "emitting javascript". Could you please clarify which of these following scenarios is the case?

1- You could compile your rust code to web assembly. Which means you can just send your compiler down to user's browser. But since your compiler is producing BEAM bytecode, you would also need a version of BEAM that can work on the browser. I think I remember someone was rewriting BEAM in rust. that could work. but is this the scenario?

2- Like some other languages, you could also compile gleam to javascript(is that what you mean by "emitting javascript"?). But this means you should send user's code to a server so it can be compiled to javascript.

But there seems to be a third option here. Having the compiler compile gleam to javascript and then compiling the compiler to web assembly. That eliminates the need to have BEAM on the browser. Is this what you mean?

[lpil]

Yes the third option is the one proposed here. The Gleam compiler outputs either Erlang or JavaScript, so we can evaluate the compiled JavaScript code in-browser.

[massivefermion]

That's great. I'll try a few things and report back.
P.S.
I saw your interview on youtube. Great job. And it was interesting to know that you studied bio. I have a physics background.

[lpil]

Thank you :)

[massivefermion]

We can't use import or eval or anything that the browser provides simply because we don't have access to the internals. But I think I have a plan.
These are what we need:
1 - A javascript parser (we can use acorn). This will get the javascript code and return an ast.
2 - An instruction set. As we traverse the ast, we'll emit instructions.
3 - A state object that will evolve as it receives instructions.
4 - A system that manages the playground GUI based on the state.

Given that the javascript code we're dealing with here is coming from gleam, its going to be simpler than the general case. But I still need some time to figure out how to work with it.

[lpil]

What do you mean by we don't have access to the internals?

[massivefermion]

Consider a gleam program with a few calls to the print function. Obviously the compiler will output console.log for those calls. So whether we want it or not, we have to deal with it because our output needs to be on the playground not in the browser's console.
So we can't just feed the whole code to eval at once, because we need to go inside and fish out all the uses of console.log and handle them in a suitable way. Which now means we have to manage the state(all the variables and functions) on our own. But that means we can't leave all the other code to the browser to deal with, because that way we can't keep track of the state.
So to keep track of the state, we need to actually parse the code ourselves.
I know it all started because of console.log, but the problem is fundamental here. If we can't keep track of the state, we're always limited in the functionalities that we can provide.
For example you may want to implement syntax highlighting and have all the previously defined variables and functions have a different color.

[lpil]

We likely wouldn't use console.log as the basis of the io print functions, instead we'd offer an augmented version of that module that stored the values somewhere. A patch like this to the io module with an associated JavaScript definition for gleam/javascript_core.print would do the trick

pub external fn print(String) -> Nil =
- "" "console.log"
+ "gleam/javascript_core" "print"

[massivefermion]

I'm not quite sure how that would work for the playground.
open your browser's console(Not here, because github doesn't allow using eval).
Now try eval("let msg = 'hello world'"). Then try either eval("msg") or msg. You'll get the error below:
msg is not defined

So it seems when eval is done with evaluating a piece of code, everything returns to the way it was before calling eval. The only way to preserve any kind of state is using window.localStorage, but that can only store strings which is very limiting.

[lpil]

We'll be creating a playgroun experience closer to that of Go or Rust where the full program is compiled and run each time, rather than having a REPL-like experience as found elsewhere. This way there's no state to preserve between runs.

[hayleigh-dot-dev]

Wrt console.log (because it was mentioned in multiple threads), you can shadow the definition and implement any bonus functionality without anyone knowing:

const log = window.console.log
window.console.log = function (...messages) {
    log(...messages)

    messages.forEach(message => {
        app.ports.toConsole?.send(...)
    })
}

This is a snippet for the playground of a language I'm developing. We save a reference to the original window.console.log, and then just reassign it, calling log to preserve the original behaviour but in this case, also sending it to an Elm app where the playground is rendered so I can render console output on the page.

[massivefermion]

I understand that. What I don't understand is that if you are evaluating your code using eval, your code is being executed in an isolated sandbox. How can you send anything outside that sandbox? Basically what is behind that app.ports.toConsole.send?

[hayleigh-dot-dev]

Code is evaluated using the same method that @lpil linked in the OP. That is to say that I generate a js module and then use dynamic imports to import and run that code:

app.ports.toJavascript?.subscribe(source => {
    const href = location.href.replace(location.search, '')
    // This fixes some weird quirk to do with relative imports. I'm not sure its
    // entirely necessary but I was deep in the weeds trying to work out why imports
    // weren't working and this was one of a few things I tried that seemed to 
    // work.
    const modifiedSource = source.replaceAll(/ren\/(.+)'/g, href + 'ren/$1.js\'')

    source && import(ESM.toDataURI`${modifiedSource}`)
        .then(({ main }) => {
            main && main()
        })
        .catch(err => {
            window.alert(
                'Oops, it looks like I ran in to some troubles running your ren '
                + 'code. Make sure you\'ve defined a public `main` function '
                + 'for me to run.\n\n'
                + 'If the problem persists, please open an issue with the code '
                + 'you tried to run quoting the error below:\n\n'
                + err.toString() + '\n\n'
                + 'https://github.com/ren-lang/playground/issues'
            )
        })
})

I don't want to hijack the discussion because I'm not sure Ren's implementation is too relevant to this, but you can see a (slightly out of date, no console.log hijacking) version of the playground and also the compiler here:

• https://github.com/ren-lang/playground
• https://github.com/ren-lang/compiler

[massivefermion]

ok...this is what I've done so far: playground
Currently you write javascript code and it executes it just as a demonstration.

But it has two problems:

1. If you do console.log([1,2,3]), it will not output an array but 1,2,3 which is [1,2,3].toString().
2. If you run the code and clean everything and run some code again, it will not show anything.

[lpil]

I would probably use JSON.stringify over .toString() as I think it is generally more readable, especially with objects

[massivefermion]

I wasn't using .toString(), I was just outputing it to the display. But yeah, that was pretty obvious. Changed it. thanks.

[massivefermion]

The second issue is solved too. Apparently import has a cache and it prevented the same code being executed more than once. So I had to invalidate it.

[massivefermion]

I also added some more functionalities. If you open any delimiters, it'll be closed automatically. And if you delete the opening one when there is nothing inside, the closing one will be deleted too. Same with quotation marks.
And if you press Enter after a delimiter, the next line is going to have an indentation.

[massivefermion]

I also think I may be able to implement syntax highlighting but that seems to be more of a long term thing!

[J3RN]

Sorry to necro this thread, but for posterity: a coworker of mine created a functioning Gleam playground and has it hosted at https://johndoneth.github.io/gleam-playground/

[Aloso]

I really like this playground and have already made a few PRs (I added an integrated JS console, example). I would like to see this project succeed. Since it is MIT licensed I guess it can be put on the official website?

[J3RN]

Could be, sure! However, I know @lpil was hoping that the playground that is ultimately made "official" would be written in Gleam. I believe @JohnDoneth is working on porting the existing JavaScript application to Gleam (perhaps with this? https://github.com/JohnDoneth/gleam-vdom), but it's non-trivial and work is likely to proceed somewhat slowly during the holiday season.

[JohnDoneth]

That's the plan! The holidays are certainly impacting my productivity. I just caught up the wasm-compiler on my fork powering the playground to the main branch just now. I'd like to get that mainlined and then focus on gleam-vdom but it still requires a bit of work to be of a level of quality I'd like to hold myself to. With gleam-vdom the aim is to write a nice framework on top of it for writing declarative and reactive client-side web apps and use it for the gleam-playground. It could also be used to power a LiveView-like library, but that's currently not my focus.

[timjs]

Sounds awesome! Should be quite doable to create an Elm-like web framework in Gleam. Gleam's language features are quite on par with Elm. Some other libraries implementing The Elm Architecture in different languages:

• Flame (PureScript, https://flame.asafe.dev)
• Miso (https://haskell-miso.org, Haskell)
• Elmish (https://elmish.github.io/elmish/, F#)

[lpil]

I quite liked the look of reason react where components could have their own state https://reasonml.github.io/reason-react/