Gluon Language Implementation for ScriptHost

[themaxhero]

I would like to implement a ScriptHost for Gluon.
Is there any contributing rules or conventions that I should be aware of?

Some information about Gluon:

Gluon is a small, statically-typed, functional programming language designed for application embedding.

• Embedding API
• Repo

[makspll]

Hi @themaxhero!

I am more than happy to merge new language PR's. When it comes to contributing, your standard etiquette + process (issue -> PR -> CI/CD -> Review) applies.
When it comes to adding new languages here are some things to keep in mind (bit of a brain dump):

• Script hosts have a very flexible interface, they are more than capable of completely ignoring the standard lifecycle of scripts as it looks like for Lua and Rhai currently, this of course does not mean they should be doing that. In fact I would advise that the register_with_app function will likely be either identical or very close to the ones in Lua and Rhai script hosts:

  bevy_mod_scripting/languages/bevy_mod_scripting_lua/src/lib.rs

  Lines 79 to 103 in 781754a

  	fn register_with_app(app: &mut App, stage: impl StageLabel) {
  	app.add_priority_event::<Self::ScriptEvent>()
  	.add_asset::<LuaFile>()
  	.init_asset_loader::<LuaLoader>()
  	.init_resource::<CachedScriptState<Self>>()
  	.init_resource::<ScriptContexts<Self::ScriptContext>>()
  	.init_resource::<APIProviders<Self>>()
  	.register_type::<ScriptCollection<Self::ScriptAsset>>()
  	.register_type::<Script<Self::ScriptAsset>>()
  	.register_type::<Handle<LuaFile>>()
  	.add_system_set_to_stage(
  	stage,
  	SystemSet::new()
  	// handle script insertions removal first
  	// then update their contexts later on script asset changes
  	.with_system(
  	script_add_synchronizer::<Self>.before(script_remove_synchronizer::<Self>),
  	)
  	.with_system(
  	script_remove_synchronizer::<Self>
  	.before(script_hot_reload_handler::<Self>),
  	)
  	.with_system(script_hot_reload_handler::<Self>),
  	);
  	}

  Ideally we want things to be consistent between all scripting languages.
• This crate prioritizes the developer experience on both the original studio's and modders side of things. What this means in practice is that languages ideally should or be capable of eventually: supporting static typing, documentation generation, writing a script side API which is close to the native Bevy API (of course within reason, Lua's 1 based indexing is a notable pain point here)
• The main branch of this repo is a re-factor away from the current release (more crates), and a lot of work has been done on the add_rhai_api branch main...feature/add_rhai_api. Namely code sharing between the different language API's is being improved, the Rhai API is being formed, and at the same time the wrapper generator macro is moving to become a derive macro. I have recently started a new job at a different city so in a bit of a chaotic period, hence it's taking longer than I'd like.
• All in all you will find that implementing the script host/language support should be fairly straightforward and quick, adding automatic API support will be the second part of the process and you'd likely want to wait for me to merge that branch before you start on that, to avoid duplicating work (but also the two parts do not at all have to come in one release, having support for a new language even without the bevy API is fantastic).
• My original plan was to merge that Rhai branch and then make a big release, but if you add gluon support I will be happy to release immediately

Do not hesitate to ask any questions either here or in private, while I cannot do as much development work at the moment until I have access to my PC, I can still help.

If there are any issues with dependencies/linting on the main branch do let me know.

Your contributions will be greatly appreciated!

[themaxhero]

I'm working on it on my spare time, so If you think I'm taking too long, please don't wait for me for the next release.

[themaxhero]

I'm having too much stuff to do on my job and I'm not having free time enough to work on this.
I'm sorry :(

[makspll]

No worries at all, no reason to apologise! If you ever feel like picking this up, feel free, there is no pressure!