这是在Rebol的2和3之间的结合行为的差异汇总？ [英] What is the summary of the differences in binding behaviour between Rebol 2 and 3?

问题描述

在变量绑定目标雷博尔2.当前深入文档有人能提供雷博尔2之间差异的摘要3？

The current in-depth documentation on variable binding targets Rebol 2. Could someone provide a summary of differences between Rebol 2 and 3?

推荐答案

有没有真正的地方汇总，让我们走在基础知识，也许有点多比非正式的Bindology 。让拉吉斯拉夫写他的论文R3和红色的新版本。我们还是要过的基本差异，按重要性排序。

There isn't really a summary somewhere, so let's go over the basics, perhaps a little more informally than Bindology. Let Ladislav write a new version of his treatise for R3 and Red. We'll just go over the basic differences, in order of importance.

的这里是很大的区别。的

在R2中，有基本上有两种情境：常规对象上下文和系统/字。两人都静态绑定表项，这意味着一旦绑定函数运行，这个词结合针对性的特定对象一个真正的指针。

In R2, there were basically two kinds of contexts: Regular object contexts and system/words. Both had static bindings, meaning that once the bind function was run, the word binding pointed to a particular object with a real pointer.

的系统/字背景是能够在运行时扩大到包括新词，但所有其他对象则没有。功能使用常规对象上下文，有些两轮牛车当你递归调用函数转出的数据块。

The system/words context was able to be expanded at runtime to include new words, but all other objects weren't. Functions used regular object contexts, with some hackery to switch out the value blocks when you call the function recursively.

的自的词，只是一个普通的词，发生在对象上下文中第一个，带有显示器的黑客不显示在上下文中的第一个字;功能上下文没有这个词，所以他们没有正确显示的第一条定期字。

The self word was just a regular word that happened to the first one in object contexts, with a display hack to not show the the first word in the context; function contexts didn't have that word, so they didn't display the first regular word properly.

<青霉>在R 3中，几乎所有的是不同的。的

在R3也有2种上下文：定期和堆栈的局部。定期上下文由对象，模块，结合环使用，使用，基本上一切，但功能，它们是可扩展的，比如系统/字是（是的，是，我们会到达那个）。旧的固定长度的对象都没有了。函数使用堆栈的局部环境中，它（除非我们还没有看到任何错误）不应该是可扩展的，因为这会打乱堆栈帧。与老系统/字你不能收缩背景下，由于从上下文中取出的话将打破这些词的任何绑定在那里。

In R3 there are also two kinds of contexts: Regular and stack-local. Regular contexts are used by objects, modules, binding loops, use, basically everything but functions, and they are expandable like system/words was (yes, "was", we'll get to that). The old fixed-length objects are gone. Functions use stack-local contexts, which (barring any bugs we haven't seen yet) aren't supposed to be expandable, because that would mess up stack frames. As with the old system/words you can't shrink contexts, because removing words from a context would break any bindings of those words out there.

如果您想将单词添加到常规情况下，你可以使用绑定/新，绑定/设置 ，解析/延长或追加，或调用这些，这​​取决于你所需要的行为等功能。这是新的行为绑定和追加在R3 功能。

If you want to add words to a regular context, you can use bind/new, bind/set, resolve/extend or append, or the other functions that call those, depending on what behavior you need. That is new behavior for the bind and append functions in R3.

词经常和堆栈的局部环境的绑定是静态的，如前。值的查表的又是另一回事。对于经常上下文值查找为pretty直接的，通过简单的指针间接做价值插槽的静态块。对于堆栈的局部环境中的数据块被堆栈帧链接和引用的来自那里，所以找到合适的框架，你所要做的堆栈步即O（堆栈深度）。请参见的bug＃1946年的详细信息 - 我们将进入后为什么

Bindings of words to regular and stack-local contexts are static, as before. Value look-up is another matter. For regular contexts value look-up is pretty direct, done by a simple pointer indirection to a static block of value slots. For stack-local contexts the value block is linked to by the stack frame and referenced from there, so to find the right frame you have to do a stack walk that is O(stack-depth). See bug #1946 for details - we'll get into why later.

哦，自不是一个普通词了，这是一个具有约束力的把戏，关键字。当您绑定的话提出异议或模块上下文块，它结合关键字自其计算是上下文的参考。但是，可以设置一个内部标志，它说，一个背景是无私，果然是自关键字了。当关键字被关闭，实际上你可以用这个词自在上下文中的字段。结合环，使用和功能情境设置无私的标志，他们的背景，以及无私？该功能检查。

Oh, and self isn't a regular word anymore, it's a binding trick, a keyword. When you bind blocks of words to object or module contexts, it binds the keyword self which evaluates to be a reference to the context. However, there is an internal flag that can be set which says that a context is "selfless", which turns that self keyword off. When that keyword is turned off, you can actually use the word self as a field in your context. Binding loops, use and function contexts set the selfless flag for their contexts, and the selfless? function checks for that.

此模型获得改进，并在一个相当复杂的治疗code火焰战争记录，很像R2的模型是由REBOL记录邮件列表火焰战争早在1999- 2000年。 ： - ）

This model was refined and documented in a fairly involved CureCode flame war, much like R2's model was documented by a REBOL mailing list flame war back in 1999-2000. :-)

当我在上面讲堆栈的局部功能的上下文，我的意思是使用功能！键入功能的上下文。 R3有很多的功能类型，但其中大部分都是本地功能于一体的这样或那样的，和本机功能不使用这些堆栈的局部环境（尽管他们得到堆栈帧）。这是Rebol的code的唯一功能类型功能！和新的关闭！键入。闭包是从常规的功能非常不同的。

When I was talking about stack-local function contexts above, I meant the contexts used by function! type functions. R3 has a lot of function types, but most of them are native functions in one way or another, and native functions don't use these stack-local contexts (though they do get stack frames). The only function types that are for Rebol code are function! and a new closure! type. Closures are very different from regular functions.

当你创建一个功能！，你要创建一个函数。它构建了一个堆栈的局部范围内，code体结合到它，并且捆绑在一起code身体和规范。当你调用该函数它与该函数的上下文的引用堆栈帧并运行code座。如果它可以访问词语的功能方面，它确实栈步行到找到合适的框架，然后从那里得到的值。相当直接的。

When you create a function!, you're creating a function. It constructs a stack-local context, binds the code body to it, and bundles together the code body and the spec. When you call the function it makes a stack frame with a reference to the function's context and runs the code block. If it has access words in the function context it does the stack walk to find the right frame and then gets the values from there. Fairly straight-forward.

当你创建一个关闭！，在另一方面，为您营造的的函数生成器的。它设置了规范，函数体pretty大致相同功能！，但是当你的呼叫的封闭它使一个新的常规的无私的背景下，然后再执行绑定/复制，改变所有引用函数上下文是在新的常规范围内引用复制。然后，当它的复制体，所有闭合字引用的那些对象上下文静态

When you create a closure!, on the other hand, you create a function builder. It sets up the spec and function body pretty much the same as function!, but when you call a closure it makes a new regular selfless context, then does a bind/copy of the body, changing all references to the function context to be references to the new regular context in the copy. Then, when it does the copied body, all closure word references are as static as those of object contexts.

两者之间的另一个区别是在他们的行为的功能正在运行之前，该函数运行过程中，与该功能完成运行后

Another difference between the two is in how they behave before the function is running, while the function is running, and after the function is done running.

在R2中，功能！情况下仍然存在，但功能的顶级调用的数据块仍然存在太多。只有递归调用得到新的数据块，顶级的呼叫保持持久的值块就像我说的，两轮牛车。更糟的是，顶层值块不被清除函数返回时，所以你最好确保你没有任何引用敏感或要回收当函数返回时（使用也函数进行清理，这就是我做它）。

In R2, function! contexts still exist when the function isn't running, but the value block of the top-level call of the function still persists too. Only recursive calls get the new value blocks, the top-level call keeps a persistent value block Like I said, hackery. Worse, the top-level value block isn't cleared when the function returns, so you better make sure that you aren't referencing anything sensitive or that you want recycled when the function returns (use the also function to clean up, that's what I made it for).

在R3，还是功能不运行时存在功能！上下文，但该值块不存在的。所有的函数调用像递归调用在R2，因为它是这样设计的一路下跌，引用堆栈帧，而不是做了，除了更好。该堆栈帧的范围是动态的（秆Lisp的风扇，如果你需要的是历史），所以只要功能是当前堆栈上运行（是的，当前，我们会到达那个），你可以使用它的一个关键词来获得在该函数的的最近通话的值。一旦所有的函数返回的嵌套调用的，不会有在范围内的任何值，你只触发一个错误（错误的错误，但我们会解决这个问题）。

In R3, the function! contexts still exist when the function isn't running, but the value block doesn't exist at all. All function calls act like recursive calls did in R2, except better because it's designed that way all the way down, referencing the stack frame instead. The scope of that stack frame is dynamic (stalk a Lisp fan if you need the history of that), so as long as the function is running on the current stack (yes, "current", we'll get to that), you can use one of its words to get at the values of the most recent call of that function. Once all of the nested calls of the function return, there won't be any values in scope, and you'll just trigger an error (the wrong error, but we'll fix that).

还有绑定到我的待办事项列表，以尽快修复一个超出范围的虚词一个无用的限制。请参见错误＃1893年了解详情。

There's also a useless restriction on binding to an out-of-scope function word that is on my todo list to fix soon. See bug #1893 for details.

有关关闭！功能，封闭运行前的的背景完全不的存在。一旦封闭件开始运行，上下文创建并持续存在。如果再次调用关闭，或递归的其他的创建持久的上下文。从封闭泄漏任何文字只是指关闭特定运行期间产生的背景。

For closure! functions, before the closure runs the context doesn't exist at all. Once the closure starts running, the context is created and exists persistently. If you call the closure again, or recursively, another persistent context is created. Any word that leaks from a closure only refers to the context created during that particular run of the closure.

您无法获得绑定到R3函数或封闭环境功能或关闭不运行时的一句话。对于函数，这是一个安全问题。对于倒闭，这是一个定义问题。

You can't get a word bound to a function or closure context in R3 when the function or closure isn't running. For functions, this is a security issue. For closures, this is a definitional issue.

瓶盖被认为是非常有用，所以拉吉斯拉夫和我都移植他们R2，独立于导致类似code，古怪足够不同的时间。我认为，拉吉斯拉夫的版本predated R3，并担任灵感R3的关闭键入！;我的版本是基于测试该类型的外部行为，并试图复制它在R2为R2 /转发，所以它的有趣，对于关闭解决方案最终被如此相似到拉吉斯拉夫的原创，我没有看到，直到很久以后。我的版本得到了包括在R2本身开始2.7.7，如关闭，来闭合和封？的功能，而关闭！词被赋予了相同类型的值功能！ R2中。

Closures were considered so useful that Ladislav and I both ported them to R2, independently at different times resulting in similar code, weirdly enough. I think Ladislav's version predated R3, and served as the inspiration for R3's closure! type; my version was based on testing the external behavior of that type and trying to replicate it in R2 for R2/Forward, so it's amusing that the solution for closure ended up being so similar to Ladislav's original, which I didn't see until much later. My version got included in R2 itself starting with 2.7.7, as the closure, to-closure and closure? functions, and the closure! word is assigned the same type value as function! in R2.

的这里的事情变得很有趣。的

在 Bindology 有相当大量的文章在谈论全球化背景下的区别（这原来是系统/字）和本地的背景下，为R2相当重要的区别。在R3，的这样的区分是不相干的

In Bindology there was a fairly large amount of the article talking about the distinction between the "global" context (which turned out to be system/words) and "local" contexts, a fairly important distinction for R2. In R3, that distinction is irrelevant.

在R3，系统/字是消失的。没有一个全球范围内。所有常规上下文是在在R2意味着感，这使得本地无用的意思是本地。对于R3，我们需要一套新的条款。

In R3, system/words is gone. There is no one "global" context. All regular contexts are "local" in the sense that was meant in R2, which makes that meaning of "local" useless. For R3, we need a new set of terms.

有关R3，唯一重要的区别是上下文是否任务相对的，所以对于唯一有用的意思是全球性语境是不直接任务相对的那些，和地方环境是有任务的，相对的。 A任务，在这种情况下，将是任务！类型，它基本上是在当前模型的操作系统线程。

For R3, the only difference that matters is whether contexts are task-relative, so the only useful meaning for "global" contexts are the ones that are not directly task-relative, and "local" contexts are the ones that are task-relative. A "task" in this case would be the task! type, which is basically an OS thread in the current model.

在R3，此刻，迄今为止唯一的事情是任务相对（勉强）是堆栈变量，这意味着该堆栈相对功能上下文应该是的任务相对的太。这就是为什么堆栈步是必要的，否则我们就需要保持和维护TLS三分球的每一个功能背景的。所有的常规的背景是全球性的。

In R3, at the moment, the only things so far that are task-relative (barely) are the stack variables, which means that stack-relative function contexts are supposed to be task-relative too. This is why the stack walk is necessary, because otherwise we'd need to keep and maintain TLS pointers in every single function context. All regular contexts are global.

另一个要考虑的是，根据该计划（其中大部分是未实现到目前为止），用户上下文系统/环境/用户和系统本身也意欲是任务相对，因此，即使由R3标准它们将被认为是局部。而且，由于系统/环境/用户基本上是R3有R2的系统/字最接近，这意味着什么脚本的认为的是他们的全局上下文实际上应该是的任务局部的在R3。

Another thing to consider is that according to the plan (which is mostly unimplemented so far), the user context system/contexts/user and system itself are also intended to be task-relative, so even by R3 standards they would be considered "local". And since system/contexts/user is basically the closest thing that R3 has to R2's system/words, that means that what scripts think of as being their "global" context is actually supposed to be task-local in R3.

R3确实有一对夫妇的系统，称为全球背景 SYS 和 LIB ，虽然他们使用完全不同的R2的全球背景。此外，所有模块的上下文是全球性的。

R3 does have a couple of system global contexts called sys and lib, though they are used quite differently from R2's global context. Also, all module contexts are global.

这是可能的（普通）为了有全局定义只能从任务的本地根引用引用的语境，这样就会使实际上这些方面的间接任务局部的。这就是通常结合环时发生，使用，关闭或私人模块从用户code，这基本上意味着非模块脚本，坐上开往称为到系统/环境/用户。从技术上讲，这也是从模块以及调用的函数的情况下（因为函数栈本地），但这些引用往往最终会分配到模块的话，这是全球性的。

It is possible (and common) for there to be globally defined contexts that are only referenced from task-local root references, so that would make those contexts in effect indirectly task-local. This is what usually happens when binding loops, use, closures or private modules are called from "user code", which basically means non-module scripts, which get bound to system/contexts/user. Technically, this is also the case for functions called from modules as well (since functions are stack-local) but those references often eventually get assigned to module words, which are global.

不，我们还没有同步无论是。然而，就是这样R3的设计应该是最终有模型，并已部分一样。请参阅<一个href=\"http://stackoverflow.com/questions/14420942/how-are-words-bound-within-a-rebol-module/14552755\" title =如何是Rebol的模块中的约束？单词>模块结合文章了解详情。

No, we don't yet have synchronization either. Still, that's the model that R3's design is supposed to eventually have, and partly does already. See the module binding article for more details.

作为奖励，R3有一个真正的符号表现，而不是使用系统/字作为一个特设的符号表。这意味着，一字涨停R2用来击打pretty迅速有效地消失在R3。我不知道，已经达到了新的限制，甚至确定了极限有多高是任何应用程序，虽然它显然远远超过几百万不同的符号。我们应该检查源头上找出答案，现在我们有它，它的访问。

As a bonus, R3 has a real symbol table now instead of using system/words as an ad-hoc symbol table. This means that the word limit R2 used to hit pretty quickly is effectively gone in R3. I'm not aware of any app that has reached the new limit or even determined how high the limit is, though it is apparently well over many million distinct symbols. We should check the source to figure that out, now that we have access it it.

末节。在使用函数初始化它的单词，无，而不是让他们取消设置。而且因为没有全局范围内的方式存在于R2，负荷不一定绑定的话都没有。这方面负荷结合依赖于<一个提到的情况下， href=\"http://stackoverflow.com/questions/14420942/how-are-words-bound-within-a-rebol-module/14552755\" title =如何是Rebol的模块中的约束？单词>模块结合文章，但除非另行指定它明确地结合的话系统/环境/用户。而两者现在夹层功能。

Minor details. The use function initializes its words with none instead of leaving them unset. And because there is no "global" context the way there is in R2, load doesn't necessarily bind words at all. Which context load binds to depends on circumstances mentioned in the module binding article, though unless you specify otherwise it explicitly binds the words to system/contexts/user. And both are now mezzanine functions.

R3是基本相同R2在此，字绑定默认不区分大小写的。文字本身不区分​​preserving，如果你使用的情况下，敏感的方法对它们进行比较，你会看到，不同之处仅在情况单词之间的差异。

R3 is basically the same as R2 in this, word bindings are by default case-insensitive. The words themselves are case-preserving, and if you compare them using case-sensitive methods you will see differences between words that differ only in case.

在对象或函数的上下文不过，当一个字被映射到一个值插槽，另外一个词就是绑定到上下文或在运行时抬头，也就是说，只有大小写不同被认为是有效的同一个词和地图为相同的值槽

In object or function contexts though, when a word is mapped to a value slot, then another word is bound to that context or looked up at runtime, words that differ only by case are considered to be effectively the same word and map to the same value slot.

然而，人们发现用别名函数，其中的别名单词的拼写比其他方式差异作出明确创建别名只是案件的破产对象，功能情境真的大幅的。在R2中，他们解决了系统/话这些问题，这让别名只是太别扭比其他任何使用演示，而不是积极的危险。

However, it was found that explicitly created aliases made with the alias function where the spelling of aliased words differed in other ways than just by case broke object and function contexts really drastically. In R2 they resolved these problems in system/words, which made alias merely too awkward to use in anything other than a demo, rather than actively dangerous.

正因为如此，我们完全删除外部可见的别名功能。内部设施走样仍然有效，因为它仅别名通常会被视为等同上下文查找，这意味着环境不破的话。但是我们现在建议本地化和其他技巧，别名在演示中使用的，如果从来没有在实践中，用另一个字赋值的老式的方法来实现新的拼写。

Because of this, we removed the externally visible alias function altogether. The internal aliasing facility still works because it only aliases words that would normally be considered equivalent for context lookup, which means that contexts don't break. But we now recommend that localization and the other tricks that alias was used for in demos, if never in practice, be done using the old-fashioned method of assigning values to another word with the new spelling.

的的问题！现在类型是字类型。你可以绑定。迄今为止，没有人已经采取了能够结合的问题，而不是只使用操作的提高的速度优势。

The issue! type is now a word type. You can bind it. So far, no-one has taken advantage of being able to bind issues, instead just using the increased speed of operations.

这是pretty多少呢，对于故意改变。大多数的差异其余可能是上述情况，或者甚至错误或还未实现的功能的副作用。甚至有可能在R3中一些R 2样行为，这也是错误或还未实现的功能的结果。如有疑问，请第一。

That's pretty much it, for the intentional changes. Most of the rest of the differences might be side effects of the above, or maybe even bugs or not-yet-implemented features. There might even be some R2-like behavior in R3 that is also the result of bugs or not-yet-implemented features. When in doubt, ask first.

这篇关于这是在Rebol的2和3之间的结合行为的差异汇总？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！