Scripting RFC

[Moxinilian]

This RFC introduces our scripting proposal.
Rendered

@kabergstrom

[Xaeroxe]

I really like all of this. My only suggestion is a name change, rather than augmented FFI we should call it Automatically Idiomatic Foreign Function Interface. AI-FFI.

[fhaynes]

The first one is to ban scripts from handling their own threading.

What about languages that use green threads?

[Moxinilian]

Feel free to use GitHub's review features so we can have threads.
@Xaeroxe Sure, why not, I called it augmented FFI just for the context of the RFC, I wasn't planning on keeping the name.
@fhaynes I think this could fall under the "limited managed threading" kind of deal. But maybe it's been too long since I've read about green threads. I need to look at it again.
But like for example it would be perfectly fine to have Rust have threads, because Rust is smart. The constraints here are language-specific.

[fhaynes]

Feel free to use GitHub's review features so we can have threads.
@Xaeroxe Sure, why not, I called it augmented FFI just for the context of the RFC, I wasn't planning on keeping the name.
@fhaynes I think this could fall under the "limited managed threading" kind of deal. But maybe it's been too long since I've read about green threads. I need to look at it again.
But like for example it would be perfectly fine to have Rust have threads, because Rust is smart. The constraints here are language-specific.

I mean more like threads that are managed by a language runtime, goroutines or Erlang processes for example, but the OS views as just one OS thread.

[Moxinilian]

It would depend on specific cases then. I haven't thought about it yet. If you want to make an addition, please write a paragraph and PR it to my fork.

[fhaynes]

In order to expose that API in an idiomatic way to the language they drive, the drivers are also provided with additional high level metadata, along with the FFI. For example, if a type is an iterator, the language driver will be noticed of this additional information so that it can, for example, do the necessary language-specific work for this iterator to be iterated over in a for loop (see the Lua example for more details).

Something about this bugs me, but I'm not sure what. Will have to think about it more. At a minimum, I think this will need a strict schema. I just have a suspicion that the driver code responsible for the the translation will end up messy. But we won't know until we try it.

[fhaynes]

It looks pretty solid to me. I'd vote move forward with a minimal PoC using LuaJIT to get an idea of the difficulties associated with this level of genercism.

[torkleyy]

I think this is pretty similar to what was said before. I'm going to go through the details later.

[Marwes]

Does this mean that script system(s) are run in a separate World(?). I don't remember where I read it but since there is no way to add or remove systems after constructing a World it was recommended to keep dynamic systems in a separate world to avoid needing to reconstruct everything everytime something is reloaded.

https://github.com/Marwes/shred-example

https://github.com/Marwes/shred-example/blob/9f6d6a62f0b4cf7f55c3e5e9ca851c76c8ec9dea/src/gluon_system.rs#L798-L800

[torkleyy]

The architecture Specs will have in the future will differ from the current quite a bit. It's already in design ;)

[torkleyy]

Regarding your comment, I think you're mixing up Dispatcher and World. Both are very likely going to change (the latter one also renamed to SystemGraph which will not need any of those workarounds).