search

trueagi-io / hyperon-experimental

MeTTa programming language implementation
https://metta-lang.dev
MIT License
133 stars 44 forks source link

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

Closed luketpeterson closed 5 months ago

luketpeterson commented 6 months ago

Adding mod-space! Op Atom, to access the space of a module, loading it if necessary See https://github.com/trueagi-io/hyperon-experimental/issues/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

luketpeterson commented 5 months ago

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. https://github.com/trueagi-io/hyperon-experimental/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 commented 5 months ago

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

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

luketpeterson commented 5 months ago

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.