Rhai playground (using WebAssembly)

[alvinhochun]

The idea is to make a playground for Rhai scripts that runs in a web browser which can showcase the features of the Rhai scripting language. It might also be possible for others to repurpose it as a Rhai script editor.

I've started an attempt on https://github.com/alvinhochun/rhai-playground, but I am not making any promises.
The master branch gets automatically built and deployed to: https://alvinhochun.github.io/rhai-playground-unstable/
I might irregularly upload specific builds to: https://alvinhochun.github.io/rhai-demo/

Wish list (not a roadmap or to-do list):

• Ability to run Rhai scripts
• Proper syntax handling for Rhai scripts
• Real-time AST compilation with error reporting (already works though pretty limited)
• Integration with the book (embedding is now possible)
• REPL
• Autocomplete list for built-in packages
• Provide more fancy IDE-like features
• Engine settings
• Custom modules
• Heuristically guess variable types?
• Debugging

[schungx]

Added an entry in #100

[schungx]

Real-time AST compilation with error reporting

This may be quite possible because the parser is fast enough. If you trottle the parsing during 500ms pauses or so it'll probably work fine...

However, the parser currently bugs out at the first error, which may not be perfect. To have a good experience, we really need reasonable error recovery, as per #119

Autocomplete list for built-in packages

This may not be easy as Rhai is dynamic, so there is no type information. It is difficult to know how to filter the list.

[alvinhochun]

Autocomplete list for built-in packages

This may not be easy as Rhai is dynamic, so there is no type information. It is difficult to know how to filter the list.

It will just be unfiltered (i.e. only filtered based on whatever the user already typed in) to start with. If it ever gets advanced enough to be able to heuristically guess the data types (which seems very unlikely) then perhaps it can be developed further. Another idea could be type annotation comments but I don't aim to discuss this...

---

I realized that it might be easier to code the playground if it can have direct access to the AST content, but it looks like a lot of it is currently inaccessible from the outside. I might also end up wanting to use some other innards or Rhai to implement other functions. That means I might have to maintain a fork for playground-specific use and the playground repo will stay as a separate repository. Do you have a better idea?

[schungx]

I can open up AST including the Expr, Stmt and Token types. Never did realize that users will want to know the inside details, so I kept them private before in order not to break code when I change the implementation.

Or do you think hiding a pub behind a feature gate?

[schungx]

@alvinhochun if you'd pull from my fork instead: https://github.com/schungx/rhai

The latest version has a new feature internals that exposes the internal data structures of the AST.

[alvinhochun]

Perhaps you can consider splitting up the crates?

[schungx]

You mean a rhai_core and a rhai that only re-exports the common API?

[alvinhochun]

How about splitting the parser and AST stuff to a rhai_ast crate?

[schungx]

How about splitting the parser and AST stuff to a rhai_ast crate?

Hhhmmm... that probably should work, but I'd hesitate to split a simple proj like Rhai into two yet even simpler crates. Unless there is an overwhelming reason...

[alvinhochun]

Maybe it'll just be simpler for me to maintain a fork for the playground.

[schungx]

Maybe it'll just be simpler for me to maintain a fork for the playground.

You don't have to. Just turn on features = [ "internals" ] and you basically get rhai_ast there.

I fully intend to merge this feature into master a bit later.