# How to resolve a context shadow problem (revised) [duplicate]

This question already has an answer here:

I have developed a notebook of 30+ functions for Geometric Algebra, all of which involved using the symbol e with subscripts like Subscript[e,1]. I write them here as e1, e2, e3 ... for readability. The functions all work correctly in the Notebook with the default Global context. Two items that complicate my question is my use of infix operators and a Palette I designed as a user-friendly device (with sliders, etc.) for the user to enter values that set up his environment.

I would like to make the functions available to others so I am trying to write my first package, and everything seems to work except a few instances of context shadowing. I believe I know how to modify the palette to eliminate those shadows but if not I may have to ask for help on that. I've boiled the other problem down to a short package (.m file) and data notebook, shown below. To illustrate the problem, I have created a simple wedge (^) infix operator, Fooxy. The result of x ^ y should be 4, as the last line shows, but it is not because the symbol e is shadowed in contexts Globaland Geom.

ClearAll["Geom*"];

BeginPackage["Geom"]
Fooxy::usage="Fooy[x,y]";

Begin["Private"]
Wedge:=Fooxy
Fooxy[x_,y_]:=Expand[x y]/.Subscript[e, u_]->1

End[]
EndPackage[]


Here is a sample user notebook:

Needs["Geom"]
x=1+Subscript[e,2];y=1+Subscript[e,1];
z=x^y
z = Expand[x,y]/.->1


Here is the output I get:

1 + Subscript[e, 1] + Subscript[e, 2] + Subscript[e, 1] Subscript[e, 2]
4


If the user sticks to a simple notebook using just Global context, then a VERY SIMPLE FIX is to insert

e=Globale;


after Begin["Private"]. This also fixes my palette issue and it may not be unreasonable for me to just release the package as is and put this limitation in the docs.

The current fix for shadow problems like this (Kuba, et. al. will correct me if I misunderstand this) is to have the user input Fooxy with the context of his e symbol:

Fooxy[x_,y_,e_]


If I make that small change, again all is well as long as I use Fooxy. But if I do this I don't think I can continue to use wedge, and wedge is necessary for the user to be able to do manipulations like x ^ y ^ z ^ w which are unwieldy otherwise. The package has 4 or 5 such infix operators currently with perhaps more to come.

I tried fixing this in a few ways but failed. One pretty reasonable approach is to require the user during setup to execute an initialization function that lets the package grab his context into a variable and somehow use it in function Fooxy or to replace the e-Globale statement in the Private section. Alternately I could design a context input in the Palette, allowing the user to change it on-the-fly. Another approach might involve Removing all e symbols except for the one in the user's context?

## marked as duplicate by Kuba♦, Feyre, m_goldberg, MarcoB, Mr.Wizard♦Dec 21 '16 at 22:49

• @matrixbud but 114768 is not advising to use Global  at all. The solution would be to define Fooy[x_, e_]:= like Integrate or D do. Your quick fix with Global  will fail as soon as someone will load your package from a notebook which has local context (CellContext->Notebook) because then e in the notebook will be Notebook\$123e or something. – Kuba Dec 21 '16 at 22:27