Bug?: interpret_in_new_env

[Ralf Hemmecke]

Unfortunately, interpret_in_new_env does not keep interpreted macros
private. :-(

Ralf

%%% (7) ->
interpret_in_new_env(parse("xx==>5;yy:=xx+3")$InputForm)$InputForm

(7) 8
Type:
PositiveInteger
%%% (8) -> xx

(8) 5
Type:
PositiveInteger

[Waldek Hebisch]

Well, interpret_in_new_env is doing what the name promises.
Unfortunately macro handling in interpreter is rather baroque,
interpreter distinguishes between "parser macros" which are
_not_ kept in environment and "interpreter macros" which
are mostly kept in environment. Few pre-build macros
are kept separately, but for some reason interpreter may
look in two environments, so there is some extra complication.

"parser macros" are kept in '$pfMacros', saving it we can
get behaviour that you expect for construct above. But
currently "parser macros" do not respect frames, so
they would still have different scope than other constructs.

I will look what can be done, probably we should turn all
macros into "interpreter macros".

--
Waldek Hebisch

[Waldek Hebisch]

On Tue, May 06, 2025 at 10:51:28AM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:

Actually, already 'parse' causes trouble:

(1) -> parse("xx==>5;yy:=xx+3")$InputForm

(1) (SEQ /throwAway (LET yy (+ 5 3)))
Type: InputForm
(2) -> xx

(2) 5
Type: PositiveInteger

AFAICS fixing this requires rework of macro handling in interpreter.
I have now version which passes all our tests and gives expected
result in your example, but it may have significant problems
(our testsuite tests only a few simple macro uses).

--


Waldek Hebisch

[Waldek Hebisch]

Rework of macro handling has some troubles which will take more
time to resolve. I have now commited a simple change so that
macros defined during 'parse' do no leak to global enviroment.
Since macros still are expanded during 'parse' it means that
sequence of 'parse' and normal interpret will have no effect
on global macros.

--
Waldek Hebisch