为什么这种使用 Begin[] 不起作用？答案

【问题标题】：Why doesn't this use of Begin[] work?为什么这种使用 Begin[] 不起作用？
【发布时间】：2011-12-16 13:58:33
【问题描述】：

如果我们逐个评估这些行，x 将在上下文cc 中创建。

Begin["cc`"];
x = 1;
End[]

但是，如果我们一起评估它们，

(Begin["cc`"];
x = 1;
End[])

然后x 将在Global 中创建。尽管有以下打印cc`：

(Begin["cc`"];
Print[$Context];
End[])

这种行为的原因是什么？我的猜测是上下文只在解析阶段很重要，而不是评估。

用例：我想创建一个调色板Button，它将在“私有”上下文中定义一些尚不存在的符号，以避免与全局变量发生冲突。 最好的方法是什么，除了将所有定义放在一个包文件中并从调色板加载它们？（我想保持调色板独立。）

【问题讨论】：

【解决方案1】：

符号（及其上下文）是在解析而不是评估时创建的。如果我们使用$NewSymbol，我们可以看到效果：

$NewSymbol=Print["Name: ",#1," Context: ",#2]&;

Print["first"];
test1;
Print["last"]

(Print["first"];
 test2;
 Print["last"])

第一个打印：

first
Name: test1 Context: Global`
last

因为单元格中的每一行都被视为单独的输入。第二个使用括号强制将所有三行视为一个输入并打印

Name: test2 Context: Global`
first
last

从中我们可以看到test2 是在进行任何评估之前在Global` 上下文中创建的。

我认为最简单的方法是在符号上使用显式上下文：cc`x = 1。

【讨论】：

另一个有时有用的选项是使用 ToExpression 进行一些新的解析 during 评估： (Begin["cc`"]; With[{s = ToExpression[" x"]}, s = 1]; 结束[];)
Brett，有没有办法使用$NewSymbol 来强制在特定上下文中创建符号，并且通过扩展不在默认上下文中创建符号？
@Andrew，您为什么不将其发布为答案？
@Mr.Wizard 可能不会，因为$NewSymbol 在进一步评估期间不会影响该符号的情况。我正在做类似于@Andrew所说的事情。当使用显式上下文名称变得很麻烦时，可以将所有内容放在一个 .m 文件中并读取它。使调色板独立的方法可能是使用一个巨大的字符串而不是一个 .m 文件，并从中读取。除非可能有一些可靠的笔记本/前端向导可以将代码包含在调色板笔记本中并在加载调色板时评估定义。
@Mr.Wizard 我想这值得一个单独的问题。我对笔记本和前端没有太多经验。

【解决方案2】：

对于您的第二个问题，我建议您参考我的this 答案，它可以有效地自动化您概述的步骤（使用ParseTimeNameSpaceWrapper 函数）。它可能需要更多的工作才能使其更健壮，但这可能是一个起点。我有时会自己使用这些东西。

【讨论】：

ParseTimeNameSpaceWrapper 仍然没有解决符号的上下文是在解析时决定的事实，即如果我这样做 ParseTimeNameSpaceWrapper[x]，那么 x 仍将被解释为 @987654327 @，而不是MyLocalizedContext`x。在理解了在解析时选择了上下文之后，我认为除了通过将一些代码放入字符串并使用ToExpression，或者从包中读取它（或者只是编写正如 Brett 所建议的那样明确地使用上下文，但对于较长的代码来说这是很多工作）。
@Szabolcs 我明白了。关于解析阶段，您可能会对这个线程感兴趣：groups.google.com/group/comp.soft-sys.math.mathematica/…

【解决方案3】：

仅供参考：

(Begin["cc`"]; Evaluate[Symbol["x"]] = 1; End[])

cc`x

【讨论】：