forth - 如何在 Forth 中对参数进行排序

Question

在 Forth 中定义单词时选择参数顺序的一般规则(经验法则)是什么？

例如，在控制几个 Helm 机的情况下，让我们定义 SERVO!这将设置伺服 channel 的位置。

关注 !方式，应该是: SERVO! ( val #ch -- ) ，但另一方面，: SERVO! ( #ch val -- ) 看起来不是更本地化吗？ ?

Answer 1

如何选择参数顺序？好问题!在 Forth 中，这个问题也应该涵盖结果的顺序。

显然，任何规则都应该有一些理由。它们可以是一些基本原则的结果，也可以解决一些问题。

我想我们可以从开始便利代码重用(任何源代码片段，包括任何单个单词)。这种便利的基本形式部分是 一致性 和 源代码最小化 .

关于参数顺序，这些部分具有以下含义。

一致性:我们应该在相似的情况下使用相似的顺序(更正式:在相似的情况下保留实质性的同构)。

最小化:我们应该选择一个最小化源代码整体大小的顺序(即更少的堆栈操作)。

因此，首先，我们应该与现有约定(或现有代码)保持一致，其次——找到最佳排序。当然，当一些旧代码使用不一致的约定时，可能会有异常(exception)。

一些已知的约定可以在 Leo Brodie 著名的“ Thinking Forth”中找到:

让地址先于计数。 (提示 4.18)

示例: ERASE ( addr u -- )
让来源先于目的地。 (提示 4.19)

示例: MOVE ( source destination count -- )
还有一个众所周知的规则，它不仅是一种约定，而且是一种优化(经实践证实)。

让较不持久的论据先于较持久的论据。

通常它会导致更少的堆栈操作。这个规则可以在许多标准词中找到。例如， WRITE-FILE ( addr u file-id -- ior )或 SEARCH-WORDLIST ( addr u wid -- 0 | xt flag ) — 那里 file-id和 wid比 addr u 更持久一对。更多的永久参数倾向于保存在顶级变量中，因此更容易将它们作为顶级参数传递。示例: ... GET-CURRENT SEARCH-WORDLIST ...
此规则也隐含地反射(reflect)在 Leo Brodie 的以下提示中

在确定通过数据结构而不是通过堆栈处理哪些参数时，选择更持久或代表当前状态的参数。 (提示 7.3)

在结果的情况下，此规则变为相反。

对于退回的元素，让更多的永久元素在更少的永久元素之前。

例如， ior , flag等 — 通常在顶部返回。

变化

在某些情况下，拥有多个变体是很方便的。
例如标准词 ROT和 -ROT .其他例子:

\ different order of inputs
FOR-LIST-NODE ( list xt -- )
FOREACH-LIST-NODE ( xt list -- )

\ different order of outputs
SPLIT ( d-txt d-key -- d-txt false | d-left d-right true )
SPLIT- ( d-txt d-key -- d-txt false | d-right d-left true )