4

This phenomenon has confused me a long time. Consider the following package example,

BeginPackage["temp`"];

test;

test2;

Begin["Private"];

f[x_]:= test_:>{x,test};

f2[x_]:= test2_:>{test2};

End[];

EndPackage[];

where test2 is for comparison.

Then in notebook evaluate the following test code with a fresh kernel,

<<temp`

Names["temp`*"]

??test$

??temp`test2$

enter image description here

It's weird that the temporary symbol test$ leaks into the public context temp` . Notice that:

  • the leaked temporary symbol must have the same name as the public one;

  • the local symbol x in the definition of f is necessary to repeat this behaviour.

Is this a bug?

Lacia
  • 2,253
  • 3
  • 19
  • 1
    I'm pretty sure it's generated by the definition of f, but I can't explain it. Other than it's because of the x in the RHS of the RuleDelayed[]. – Michael E2 Jun 20 '23 at 19:46
  • 1
    Some of the related Q&A: (20766), (119403), (124435) -- It's as though the system is anticipating the renaming to happen if temp`Private`f[3] should ever be called. – Michael E2 Jun 20 '23 at 21:32
  • 2
    Leaking via Pattern naming is a common phenomenon. The name space for local pattern leads to unexpected results in replacements, regularly, if pattern symbols collide with DelayedSet symbols. It's good practice, to chose symbols locally with sight on the symbols around and don't use general replacements procedures, because Replace does not respect any algebra notation conventions. – Roland F Jun 21 '23 at 05:53

0 Answers0