Adding mod-space! Op Atom, to access the space of a module, loading it if necessary

[luketpeterson]

Adding mod-space! Op Atom, to access the space of a module, loading it if necessary
See #592

It's now possible to do this: !(add-atom &new_space (mod-space! mod_name))

Therefore, !(add-atom &self (mod-space! stdlib)) adds the same atom(s) as !(import! &self stdlib), but does not add any tokens.

For me the remaining question is whether we want to enshrine the "nested-sub-space" behavior into MeTTa semantics? We could add a merge-atoms or similar operation, to make it clear we're bringing in all atoms from the source space, but the implementation in the present code would be identical to add-atom

[Necr0x0Der]

Taking into account that modules drift away from pure spaces as was supposed, mod-space operation makes sense. I wonder if it has to have side effects, though. Do we need to load the module if it is not loaded, or would it be better to return Empty?

[luketpeterson]

Taking into account that modules drift away from pure spaces as was supposed...

The biggest conceptual issue here is the Tokenizer. There are other minor things, but if we can come up with a way the Tokenizer leverages the space then I am sure we can solve the rest of the issues. #510 Of course the Alpha release timeline might constrain us a bit.

Do we need to load the module if it is not loaded, or would it be better to return Empty?

Not sure. My assumption was that load-on-demand would be more convenient. Otherwise people would need to use register-module! or import! prior. Which might be inconvenient. Especially because import! does additional stuff (e.g. registering tokens) and register-module! works with paths and therefore is limited to modules in the file system.

[Necr0x0Der]

My assumption was that load-on-demand would be more convenient.

Maybe, this functionality should be covered by a unit test.

[luketpeterson]

Maybe, this functionality should be covered by a unit test.

The Op Atom generally has this unit test: https://github.com/luketpeterson/hyperon-experimental/blob/b686aa950964c089621a6ad5a60ea46e2d2cc799/lib/src/metta/runner/stdlib.rs#L1527

as far as a unit test specifically for load-on-demand, it calls through exactly the same pathway as import!, so I don't think there is much untested surface area in that particular interaction.