environment as seen by lfe_shell:run_*

[Duncan McGreggor]

Robert,

I've been a little confused lately when looking at the environment data returned by run_string/3. In particular, what I see is a state tuple that contains several env tuples. So my questions are these:

1) what are the various environment tuples for? I had naively assumed there would be only one

2) which env tuple should be passed as the third argument to run_string/3 in the next call to it?

3) I'm assuming that state shouldn't be passed (the collections of envs), since run_string/2 passing lfe_env:new/0 as the third arg to run_string/3, and it creates the tuple #(env () ()).

Hrm, I've just saved each env data structure into a file and diff'ed them against each other:

1) it seems that the env in the first position is the environment created after executing the function -- it has the * and + values associated with the results.

2) the differences between the second and third env are less clear to me. It looks like the primary difference is that the dynamic functions have been updated in one and note the other.

So I guess this answers one of my questions: I should use the first env data structure.

That still leaves the more interesting question: what are these used for?

d

[Robert Virding]

So the state tuple is a record with two fields, the variable bindings and the function/macro bindings. Both are orddicts. Then environment handling is implemented in lfe_env.erl. run_string/3 hasn't been written in such a way that it can be called again threading the environment through as it is re-initialised every time with the shell functions, macros and variables. This is not what you want. I will fix it. This won't cause any problems as it is not used in that way in the current code.

Then you will be able to do:

St0 = lfe_shell:init_state(),
{Res0,St1} = lfe_shell:run_string(String1, Args1, St0),
{Res1,St2} = lfe_shell:run_string(String2, Args2, St1),
...

The string is the string you want to evaluate and args should also be a list of strings. run_string binds the LFE shell variables script-name to "lfe" and script-args to the args list. It then evaluates the string. If you call run_script then script-name is the name of the script file. They were designed to be called for running things from the command line but I can fix them.

However this will not handle any io. An alternative is still run the LFE shell directly but control the io through a special io-server.

Robert

[Robert Virding]

Sorry that was just the environment. The state contains more. It contains the current environment; an environment saved when we do a slurp which we can unwind back to when we do unslurp or a new slurp, and the base environment which we roll back to with reset-environment. It also contains a flag saying whether we have slurped or not.

How you would want to handle this depends on how you would like the shell to behave, like the normal shell or in some special way.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.