Rewriting symbol context?

Question

I have some code that uses a list of replacement rules to inject values (physical constants for different materials) into a more complicated expression. This is convenient since I can tweak the values in my rule list independently from the code and they appear in the code as familiar greek letters for the values until substitution.

This all works fine in the normal context of a notebook, but when I move the code to a package the symbols in my expression are in the package context and the are not replaced by applying ReplaceAll with a list of symbols created in the default Global` context.

Is there a simple way to get around this problem without resorting to tedious incorporation of a long list of named options, or explicitly passing the constants in the function code, or using order dependent lists of unlabeled data?

Can this be fixed by applying a pure function to the replacement rule lists? Something that rewrites the symbol contexts just before calling ReplaceAll for the substitution? It should transform something like this

{Global`x->1.0, Global`y->2.*^10, Global`z->0.123}

into something like this:

{MyContext`x->1.0, MyContext`y->2.*^10, MyContext`z->0.123}

with the intention of making substitutions in a call to the packaged code in a way that is transparent to the user who simply inputs a list built in a regular notebook.

Does anyone have a better arrangement for this use case?

Here's a short example of what I mean:

BeginPackage["foo`"]
Unprotect @@ Names["foo`*"];
ClearAll @@ Names["foo`*"];
f::usage = "sol=f[x,plist]"
Begin["`Private`"]
f[x_, plist_] := x + y + z /. plist;
End[]
Protect @@ Names["foo`*"];
EndPackage[]

paramList = {y -> 1, z -> 2};
sol = foo`f[x, paramList]

which gives

(*x + foo`Private`y + foo`Private`z*)

while the desired ouput would be

(*3 + x*)

Answer 1

It is hard to answer you without you showing a minimal example of the problem.

But my guess is that you are making the mistake of returning symbols from the package back to the user.

The way to handle these things, is to do like all Mathematica functions do, which is pass the symbols needed in the call itself. For example, when using DSolve or Integrate, and others, the symbols x, y etc... are passed in and they are returned back in the solution. This way, you can now to the replacement in the global context with no problem. Here is an example of simple package

  BeginPackage["foo`"]
  Unprotect @@ Names["foo`*"];
  ClearAll @@ Names["foo`*"];  
  f::usage = "sol=f[x,y]"
  Begin["`Private`"]  
  f[x_,y_] := Module[{z=1}, x+y+z];
  End[]
  Protect @@ Names["foo`*"];
  EndPackage[]

In the above, x,y are passed in, from the user, while z is local. Now you can do this:

SetDirectory[NotebookDirectory[]]
Get["foo.m"]
?foo`*

Now call the package function, but pass it the symbols in the call

 sol = foo`f[x, y]

Now the symbols x and y can be replaced as is, since they have the same context as the caller's

  sol /. {x -> 10, y -> 2}

So you have to pass in all the symbols you expect to be part of the result coming back.

Now compare what happens if you return symbols back from the package

  BeginPackage["foo`"]
  Unprotect @@ Names["foo`*"];
  ClearAll @@ Names["foo`*"];  
  f::usage = "sol=f[]"

  Begin["`Private`"]  
  f[] := Module[{z=1,x,y}, x+y+z];
  End[]
  Protect @@ Names["foo`*"];
  EndPackage[]

  Get["foo.m"]
  ?foo`*

  sol = foo`f[]

Now the replacement does not work

  sol /. {x -> 10, y -> 2}

Again, this is how Mathematica functions all do this. If you return a symbol that is local in the package back to the user, only then you'll have the issue you are talking about.

Update

Using the example shown now in the question, this is how I would do it:

BeginPackage["foo`"]
Unprotect @@ Names["foo`*"];
ClearAll @@ Names["foo`*"];
f::usage = "sol=f[p,plist]"
Begin["`Private`"]
f[{x_,y_,z_}, plist_] := x + y + z /. plist;
End[]
Protect @@ Names["foo`*"];
EndPackage[]

Then

Get["foo.m"]
paramList = {y -> 1, z -> 2}
sol = foo`f[{x, y, z}, paramList]

To avoid writing the symbol list explicitly, the symbols can be extracted on the fly from the replacement list itself, using a pattern, like this

paramList = {y -> 1, z -> 2, x -> x}
sol = foo`f[paramList /. Rule[x_, y_] :> x, paramList]

Answer 2

I have exactly the same project. In my case paramList always has the same variables' names, so I defined a "structure" to handle it in the package and a way to transform it into a rule:

BeginPackage["foo`"]
Unprotect @@ Names["foo`*"];
ClearAll @@ Names["foo`*"];
f::usage = "sol=f[x,plist]"
Begin["`Private`"]
constructPData[y_, z_] := pData[y, z];
pData /: Normal[pData[y1_, z1_]] := {y -> y1, z -> z1};
f[x_, plist_pData] := x + y + z /. Normal[plist];
End[]
Protect @@ Names["foo`*"];
EndPackage[]

pd = foo`constructPData[1, 2];
sol = foo`f[x, pd]

Since the transformation to a rule is invoked inside the package, the variables' names are correct.

The drawback of the method is that you need to know the structure of pData in advance (number of variables and their names).

Answer 3

Consider using strings:

BeginPackage["foo`"];
Unprotect @@ Names["foo`*"];
ClearAll @@ Names["foo`*"];
f::usage = "sol=f[x,plist]";
Begin["`Private`"];
f[x_, plist_] := 
  With[{y = Lookup[plist, "y"], z = Lookup[plist, "z"]}, x + y + z];
End[];
Protect @@ Names["foo`*"];
EndPackage[];

paramList = {"y" -> 1, "z" -> 2};
sol = foo`f[x, paramList]

Or do this:

BeginPackage["foo`"];
Unprotect @@ Names["foo`*"];
ClearAll @@ Names["foo`*"];
f::usage = "sol=f[x,plist]";
Begin["`Private`"];
With[{context = $Context}, 
  makeSymbol[x_String] := Symbol[context <> x]];
f[x_, plist_] := 
  x + y + z /. MapAt[makeSymbol@*SymbolName, plist, {All, 1}];
End[];
Protect @@ Names["foo`*"];
EndPackage[];

paramList = {y -> 1, z -> 2};
sol = foo`f[x, paramList]
Names["foo`*"]
Names["foo`Private`*"]
Names["Global`*"]

The code at the end shows that the contexts contain the correct symbols.

However the latter has the disadvantage of evaluating x + y + z symbolically first which might not always be desirable. Use Hold and ReleaseHold if you don't want a symbolic evaluation to leak.