You can explicitly define variables in the global context by prefixing their name with Global`, for example, Global`i = 3 or Global`f[x_]:=x^2. However if you have set the notebook to have private context, you don't have Global` in your $ContextPath (in order to prevent interference from other notebooks with non-private context). Therefore in your notebooks the context Global` isn't really special, you can use any context, like myShared`. Indeed, that's desirable because that way you know that a third notebook will be unlikely to interfere.
So you would write in your first notebook
myShared`function[x_]:=x^2
and then could access that function from the other notebook as
myShared`function[3]
(*
==> 9
*)
Note that you can add your context to the context path by using
AppendTo[$ContextPath, "myShared`"]
This then allows you to refer to the function above without the prefix, e.g.
function[3]
(*
==> 9
*)
However note that with this, your local symbols may shadow the shared ones (however access as myShared`function still works even then), so you have to make sure that you don't use the unprefixed symbol in any way before the prefixed one was created.
You might consider avoiding the issue by using PrependTo instead of AppendTo, but then you are vulnerable to variable injection (including accidental one) from the other notebook. For example, imagine that you have the definitions
a = 3;
PrependTo[$ContextPath, "myShared`"]
and then you do in your other notebook
Begin["myShared`"]
function[a_] := a^2
other[a_] := 5
End[]
Let's assume the symbol a had not yet been used in that notebook, then it is created, together with the symbols function and other, in the context myShared`, and therefore in your first notebook now hides the local definition of a. That is, if you now evaluate a in your first notebook, the kernel will find myShared`a (without a value) first, and therefore use that instead of the local a; of course it won't evaluate to 3.
Yet another way to access the symbol without prefix would be the definition
function := myShared`function
which however only works in a context with evaluation. Especially it should not be used for shared variables because after
variable := myShared`variable
a subsequent assignment like
variable = 42
does not change the shared variable, but only the local one (which no longer refers to the shared one).
Therefore I think it is a better idea to not do either, but always use the prefixed version.
Note that the PrependTo scenario is also an argument against using Begin["myShared`"] … End[] to simplify definitions in this case: It's too easy to accidentally introduce new symbols in that context which were not intended to be there.
Note that another way of sharing functions is to make them into a package and use that package from both notebooks. Ultimately this also boils down to having a shared context, as rcollyer noted in the comments. However a properly written package protects against or at least warns about most problems with hiding. Of course, writing a package might be overkill for your specific situation.
myShared`function[a_]:=a^2is not vulnerable asais localized due toSetDelayedhaving theHoldAllattribute. – rcollyer May 24 '12 at 14:28ain notebook 1 will no longer evaluate to3, not because the value ofnotebook1uniquecontext`ahas been overridden (that one still has the value 3 associated with it) but because that definition is hidden by the symbolmyShared`a. Yes, that's a non-obvious effect, and exactly for that reason you should avoid it. – celtschk May 24 '12 at 14:34$ContextPathto minimize its effects, i.eAppendTov.PrependTo. I'm disappointed, though, that there isn't a shadowing warning raised. – rcollyer May 24 '12 at 14:43PrependTo, you circumvent any checking capability, also. Well, that seals the case, then.Prependfor globals is bad. – rcollyer May 24 '12 at 14:56AppendToin the two-notebook case, you also can get a no-warning shadowing: Assume you try to refer to a shared function from the other notebook without context prefix, but forgot that you haven't yet executed the definition there. Thus you'll create a local context symbol. Then when defining in the other notebook, the symbol will be created in the shared context. However the already created local-context symbol in the first notebook will hide the newly-created shared symbol. However in the notebook creating the shared symbol, there's no shadowing and therefore no warning. – celtschk May 24 '12 at 15:09$ContextPath. – rcollyer May 24 '12 at 15:22myContext`Privatewhich is not elevated, while exposing the needed symbols viaf::usagein the outer context. But, at that point, you might as well call it a package, and be done with it. – rcollyer May 24 '12 at 15:22