Pragmas and REPL configuration

[vsbogd]

After #419 we have two ways to configure execution environment REPL settings and Metta settings:

hyperon-experimental/lib/src/metta/runner/mod.rs

Line 34 in a66e830

settings: Shared<HashMap<String, String>>,

which are editable via pragmas:

hyperon-experimental/lib/src/metta/runner/stdlib.rs

Line 680 in a66e830

pub struct PragmaOp {

See start of the discussion here #419 (comment).

This issue is to merge and unify these configurations in order to have single source of truth for the execution configuration.

[luketpeterson]

The pragma! op is cleaner because it just sets a key-value pair. So it's going to be both more efficient and clearer to the user what is happening, vs. querying the space for an expression.

The downside is that the evaluation is done only once. For example the ReplPrompt symbol is queried by the repl for each and every new line, so it could display pertinent information related to the state of the space.

[luketpeterson]

From @vsbogd on Mattermost:

the way I would suggest is representing configuration items as equalities and use interpreter to get the value instead of just matching it. Then one can write something like (names of the functions are just to demonstrate the idea I don't propose exact names here):

(= (ReplConfigDir) (path_concat (get_user_home_dir) ".config/metta"))
(= (ReplConfigFile) (path_concat (ReplConfigDir) "settings.metta"))

[vsbogd]

Two points here. First, I actually don't think we need to mix REPL specific configuration (like syntax highlighting or prompts) with execution configuration (like enabling syntax checker before adding atoms). I think these two should be separate configurations. I raised this issue specifically about execution configuration.

Second point is that I think we could have both file configuration for the execution and pragmas in code but the settings should be kept in a same structure inside Rust process: either in atomspace or in Metta.settings (like it is implemented at the moment).

The simplest thing we can do I think is to use pragmas inside REPL configuration file to configure execution environment. It is not very aligned with REPL specific configuration which is represented in a form of a equalities though.

[vsbogd]

I feel like we understood words "execution configuration" differently when we were discussing #419 (comment) I provided an example of execution configuration setting above. Basically when I talk about "execution configuration" I mean flags which can be set by pragmas in current code and similar.

[luketpeterson]

So I will do the following:
1.) run the init.metta file before anything else (for both runner mode and interactive mode), which can issue the pragmas to apply all MeTTa settings. This will include configuring the search path.
2.) rename config.metta to repl.metta (or maybe replrc.metta??)
3.) extract the values using the interpreter, not just a direct space-query. (for values that live in the space, like ReplPrompt), and move the "set-once" values (like styling) to pragmas / settings.

[vsbogd]

Looks good at a first glance. In fact I would also give a chance to an idea to keep results of pragmas in atomspace. Main point is that REPL specific and execution configuration should have different namespaces. @Necr0x0Der do you have any strong opinion here?

[Necr0x0Der]

I don't have a strong opinion, but I can make a few soft statements:

• it would be good to have different sort of settings in some space[s]
• it would be good not to pollute the main space with unnecessary expressions. Some people even don't want to have &stdlib inserted into the main space. If we had #pragma no-stdlib or something like this, it would be bad to put an expression with this config into &self.

Thus, we can have other spaces with these settings. We can store execution and repl settings in different spaces if we wish (I tend to prefer using different spaces for such cases, but it depends on the presence of a clear boundary between these settings; if they turn out to be deeply interconnected then using one space is more sensible). REPL can just add this token by itself. Apparently, current pragma settings can be put into a corresponding space. It is a metta-ish idea. I'm not stick to keeping them in settings: Shared<HashMap<String, String>>.

[Necr0x0Der]

Optionally loading a config file by repl if the default file exists, or directly loading a metta file into one or another config space sounds ok. The only problem is that some pragmas are potentially not just passive settings, but may require some immediate work. This may also be done via using ! in a config file, though.

[luketpeterson]

I went to make this change to the repl, but the current pragma! op is picky about what atom types it will accept as a value.

For example, !(pragma! ReplDefaultPrompt "> ") isn't acceptable when the python stdlib is loaded because the second atom is parsed as a string and then becomes a value atom, which is unacceptable to pragma!

It seems to me that we'd want to loosen up the types pragma will accept. For example:

!(pragma! ReplBracketStyles ("36" "35" "33" "32")) ; 36: cyan, 35: magenta, 33: yellow, 32: green

uses an expression atom to encode a tuple to express the styling of different levels of nested brackets.

What do you think, @vsbogd or @Necr0x0Der ?

[Necr0x0Der]

I'm ok with loosen up the types for pragma, at least, at the moment.

[luketpeterson]

Repl config migrated to pragmas, and separated from MeTTa environment config in #433

I want to leave this issue open to track configuring the import search path however.