Change in import &self behavior

[Adam-Vandervorst]

@Necr0x0Der, @luketpeterson, as per our MM thread:

Not sure if a bug or intended change: &self used to refer to space a statement is evaluated from, and now it seems to refer to the space it was written in.

; utils.metta
(= (transform $pattern $template) (match &self $pattern $template))

; main.metta
(import &self utils.metta)
(A X)
(transform (A $x) $x)
; now [], used to be [X]

[Necr0x0Der]

I don't have strong opinion. From general considerations of modules, one may argue that &self should refer to the imported space/module even if it is imported to &self in the parent module. This helps to separate stuff in the imported space and in the parent space. OTOH, if one wants this separation, the module can be imported into another space, so this argument is weak. Having &self token in the imported space together with importing into the parent &self would be more useful if these &selfs were identified. Thus, I'm in favor of the old behavior a little, but wouldn't insist on it.

[luketpeterson]

This is intended behavior.

&self used to refer to space a statement is evaluated from, and now it seems to refer to the space it was written in.

This statement isn't precisely true. &self gets converted to a concrete space pointer when it is parsed. Which currently happens during module loading. The reason this appeared to work in the past is because the source module's space and the destination space effectively became the same space. See https://github.com/trueagi-io/hyperon-experimental/issues/527

I am mid-way through prototyping an inline! operation that might be more like what people want when they reach for a module. The idea being akin to C's #include. ie. the referenced the block of code isn't parsed until it's inlined, and it can freely interact with the running state (ie. bidirectional dependencies between the imported and the importing (parent) code. because it's just a continuation of the same code). inline multiple times for meta-MeTTa-programming ;-)

[Adam-Vandervorst]

While this would be a great addition to the current system, equating spaces to files doesn't scale past toy examples anyways, so I wouldn't worry too much about it. In the WASM transpiler functions that used a reference got it as an argument in a partial function. I believe this would also be the way we can move to parametrized rules (transform in this example is match parametrized with a space). You want to be able to compose rules before knowing what space they're going to execute on.

[luketpeterson]

This is a deeper question than modules / import behavior. Right now MeTTa code is parsed and therefore refers to a concrete space, or it's not and is text. There is no atom that represents "The &self space of the currently running context". But perhaps there should be.

[luketpeterson]

@TeamSPoon this is in response to your comment https://github.com/trueagi-io/hyperon-experimental/issues/592

I like the name include! because I use it to include functions defined in .metta files. Also there are cases when I am including the same files that have directives I need into multiple metta files.

I want to separate (in my mind at least) two separate feature requests. 1.) The ability to bring in external code to be tokenized and interpreted in the currently running context. (ie. with @self pointing to the caller's self Space, using the tokens loaded in the current module, etc.)

2.) The ability to target any &space as a target into which to add new atoms from an external source.

My present thinking is a merge_into operation for 2. and an include operation for 1. Do you agree?

[luketpeterson]

Given the mod-space! operation is already provided to access any module's space, and you can effectively merge it using the add-reduct operation, the only thing remaining is a include operation to parse source code into the current running context without loading it as a separate module.

I'm going to mark this as a duplicate of https://github.com/trueagi-io/hyperon-experimental/issues/354

[luketpeterson]

Scratch that. @vsbogd explained the intention behind https://github.com/trueagi-io/hyperon-experimental/issues/354 and it relates to context management / capturing, whereas this issue will be a good tracker for adding the include operation.

[luketpeterson]

include operation added in d847c9a

[vsbogd]

Closing it after adding include