Need accessor for loaded module's space, within MeTTa

[vsbogd]

When I run f1_imports.metta manually I get the following error:

$ metta tests/scripts/f1_imports.metta 
[(Error (assertEqual ((let $x (get-atoms GroundingSpace-0x55f3df6e5278) (get-type $x))) ((get-type GroundingSpace-0x55f3df6e5278))) 
Expected: [(hyperon::space::DynSpace)]
Got: [(hyperon::space::DynSpace), (hyperon::space::DynSpace)]
Excessive result: (hyperon::space::DynSpace))]

!get-atoms(&self) returns [GroundingSpace-0x55abbf778a08, GroundingSpace-0x55abbf8c9f58] while &self is GroundingSpace-0x55abbf7ab278 thus &self contains imported modules atomspaces which is expected but doesn't contain &self.

[luketpeterson]

The issue is that running the script manually initializes the environment using the default init.metta file while the test environment does not contain any init.metta file at all.

An updated version of the test is here: https://github.com/luketpeterson/hyperon-experimental/blob/b504aeb1de476c13d0f9fbf4e9d7112088cca939/python/tests/scripts/f1_imports.metta

But this modified test fails in the test environment.

Harking back to the discussion here: #450 (comment) , the deeper issue is that some aspects of this test are testing an incidental behavior (arbitrary detail of the implementation) rather than a fundamental behavior (something a user can depend on).

In my opinion, a better test would bind a name to the loaded module, and then make sure that module was successfully loaded into the space by retrieving it by name, rather than taking for granted that the space would contain exactly N atoms and that the ith atom in a get-atoms list would be a specific atom. (The current test is also sensitive to atom ordering within the space, which is also a problem)

[vsbogd]

Thanks Luke, my description is incorrect. I was confused by the fact the test fails in minimal MeTTa on a different line than it fails when I run it using REPL. Thus you are right that it is an issue of the test itself.

[Necr0x0Der]

This test tests a certain behavior. If this behavior is changed, this is detected by the test. Whether it is incidental or fundamental, the change apparently breaks some compatibility. Some users are already surprised that &self contains some atoms from the beginning. The script explains, why. And now, I'm surprised that init.metta is loaded into &self as well, which may not be the case for other environments. Thus, the problem is not in the test itself. The problem is in the changed behavior with no provided explanation. It's ok since it's WIP. And it's ok if this behavior is changed if it is sensible (and I expect that it can be changed further when we introduce a solid way of dealing with MeTTa libraries, imports, extensions and such). In any case, could you explain, what is init.metta, what it contains, how it is used, do we need to load it into &self and for what reason?

[luketpeterson]

could you explain, what is init.metta, what it contains, how it is used, do we need to load it into &self and for what reason?

init.metta is a user-customizable part of the environment. Any MeTTa code the user would like to run automatically upon the creation of a runner can go there. The idea is that it will also provide hooks for initializing things like the module search paths and other environment-specific settings, as well as running any setup code the user might want for their application.

init.metta was loaded as a module to keep the config Space separate from the top-level &self space, but that cuts both ways as the user may want to load directly into &self. #467 changes init.metta to run in the runner's top-level space, rather than to treat it as a module.

Independently of that, #468 adds the "module-space" accessor operation to the stdlib, in order to access the space of a loaded module. (I didn't add it to stdlib2, although it could be easily migrated)

Ideally we can agree on a good way to test module loading without encouraging users to rely on the specific order of atoms returned by get-atoms

[luketpeterson]

I thing we can close this issue, given the implementation of the mod-space! op.

Do you agree @vsbogd?

[vsbogd]

Just to confirm my understanding:

• init.metta is not loaded anymore it is ran but not included into &self
• test checks presence of two spaces because second is "dependency of stdlib" (I am not sure what is this), and comment before test states it.
• test passes

Thus I think we can close it but I would suggest adding a word about this stdlib's dependency what is it exactly.

[luketpeterson]

init.metta is not loaded anymore it is ran but not included into &self

init.metta is run in the top-module context. So it's not a module itself but a chance to run code each time a new runner is created.

test checks presence of two spaces because second is "dependency of stdlib" (I am not sure what is this), and comment before test states it.

Right. corelib and stdlib are separate modules. corelib is the rust stdlib. stdlib is the Python stdlib.

test passes

Yes. As long as you're running under Python.

The comment at the top of f1_imports.metta was outdated and misleading. I fixed the comment in 2955ec9