RFC83 日本語訳

0083 Language-machine for data reconfiguration. R.H. Anderson, E.Harslem, J.F. Heafner. December 1970. (Format: TXT=22253 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                        R. Anderson
Request for Comments: 83                                      A. Harslem
NIC: 5621                                                     J. Heafner
                                                                    RAND
                                                        18 December 1970

コメントを求めるワーキンググループR.アンダーソン要求をネットワークでつないでください: 83 A.Harslem NIC: 5621 J.Heafner底ならし革1970年12月18日

               LANGUAGE-MACHINE FOR DATA RECONFIGURATION

データ再構成のための言語マシン

Introduction

序論

   In NWG/RFC #80 we mentioned the needs for data reconfiguration along
   with a complier/executor version of a Form Machine to perform those
   manipulations.

NWG/RFC#80では、私たちはForm Machineの承諾者/執行者バージョンに伴うデータ再構成がそれらの操作を実行する必要性について言及しました。

   This note proposes a different approach to the Form Machine.
   Specifically, we describe a syntax-driven interpreter that operates
   on a grammar which is an ordered set of replacement rules.  Following
   the interpreter description are some "real-world" examples of
   required data reconfigurations that must occur between RAND consoles
   and the Remote Job System on the UCLA 360/91.  Lastly, we suggest
   that the Protocol Manager mentioned in NWG/RFC #80 can be simplified
   by using the Form Machine and two system forms (specified a priori in
   the code).

この注意はForm Machineへの異なるアプローチを提案します。 明確に、私たちは1つの順序集合の交換規則である文法を作動させる構文駆動のインタプリタについて説明します。 インタプリタ記述に続いて、何かが「本当の世界」であるというUCLA360/91の上のRANDコンソールとRemote Job Systemの間に起こらなければならない必要なデータ再構成に関する例。 最後に、私たちは、プロトコルマネージャが、NWG/RFCで#Form Machineと2個のシステム用紙(先験的なコードで指定された)を使用することによって80を簡素化できると言及したと示唆します。

   Caveat:  The Form Machine is not intended to be a general purpose
   programming language.  Note the absence of declaration statements,
   etc.

警告: Form Machineは汎用のプログラミング言語であることを意図しません。 宣言声明などの欠如に注意してください。

THE FORM MACHINE

フォームマシン

I.  Forms

I. フォーム

   A form is an ordered set of rules.

フォームは1つの順序集合の規則です。

      F = {R1, ...,Rn}

F=R1、…、Rn

   The first rule (R1) is the rule of highest priority; the last rule
   (Rn) is the rule of lowest priority.

最初の規則(R1)は最優先の規則です。 最後の規則(Rn)は最も低い優先度の規則です。

   The form machine gets as input: 1) a list of addresses and lengths
   that delimit the input stream(s); 2) a list of addresses and lengths
   that delimit the output area(s); 3) a pointer to a list of form(s);
   4) a pointer to the starting position of the input stream; and 5) a
   pointer to the starting position of the output area.  The Form
   Machine applies a form to the input string emitting an output string
   in the output area.  The form is applied in the following manner:

フォームマシンは入力されるように得ます: 1) 住所録と入力を区切る長さが(s)を流します。 2) 住所録と出力領域を区切る長さ。 3) 形式のリストへの指針。 4) 入力ストリームの開始位置への指針。 そして、出力領域の開始位置への1指針あたり5)。 Form Machineは出力領域で出力ストリングを放つ入力ストリングにフォームを適用します。 フォームは以下の方法で適用されます:

Anderson, et. al.                                               [Page 1]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [1ページ] データ1970年12月18日のRFC83言語マシン

      Step 1:  R1 is made the current rule.

ステップ1: R1による作られていて、電流が統治されるということです。

      Step 2:  The current rule is applied to the input data.

ステップ2: 現在の規則は入力データに適用されます。

      Step3:   a) If the rule fails, the rule of priority one lower is
                  made current.

Step3: a) 規則が失敗するなら、1つが下ろす優先権の規則を現在にします。

               b) If the rule succeeds, the rule of highest priority is
                  made current

b) 規則が成功するなら、最優先の規則を現在にします。

               c) When the rule of lowest priority fails, the form fails
                  and application of the form to the input data
                  terminates.

c) 最も低い優先度の規則が失敗すると、フォームは失敗します、そして、入力データへの形式の適用は終わります。

      Step 4:  Continue at Step 2.

ステップ4: ステップ2で続いてください。

   In addition, during Step 2, if the remainder of the input string is
   insufficient to satisfy a rule, then that rule fails and partial
   results are not emitted.  If a rule fills the output string,
   application of the form is terminated.

さらに、入力ストリングの残りが規則を満たすためには不十分であるなら、Step2の間、その規則は失敗します、そして、部分的な結果は放たれていません。 規則が出力ストリングをいっぱいにしているなら、形式の適用は終えられます。

II.  Rules

II。 規則

   A rule is a replacement operation of the form:

規則は形式の交換操作です:

      left-hand-side -> right-hand-side

左側->権利手の側

   Both sides of a rule consists of a series of zero or more _terms_
   (see below) separated by commas.

規則の両側は_用語_(以下を見る)がコンマで切り離した一連のゼロか以上から成ります。

   The left-hand-side of the rule is applied to the input string at the
   current position as a pattern-match operation.  If it exactly
   describes the input, 1) the current input position pointer is
   advanced over the matched input, 2) the right-hand-side emits data at
   the current position in the output string, and 3) the current output
   position pointer is advanced over the emitted data.

規則の左側はパターンマッチ操作として現在の位置の入力ストリングに適用されます。 それはまさに入力、経常投入量位置の指針が進められる1について)説明します。取り組んでいる入力、2) 正しい手の側は経常産出高位置の指針が放たれたデータの上に進められるという出力ストリング、および3の)現在の位置でデータを放ちます。

III.  Terms

III。 用語

   A term is a variable that describes the input string to be matched or
   the output string to be emitted.  A term has three formats.

用語は、合わせられるために入力ストリングについて説明する変数か放たれるべき出力ストリングです。 用語には、3つの形式があります。

Anderson, et. al.                                               [Page 2]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [2ページ] データ1970年12月18日のRFC83言語マシン

Term Format 1
+---------------------------------------------------------------------+
|                                                                     |
|     name ( data  replication  .   value     :    length    )        |
|            type   expression    expression      expression          |
|                                                                     |
|_____________________________________________________________________|

用語形式1+---------------------------------------------------------------------+ | | | 名前(データ模写値: 長さ)| | 式式式をタイプしてください。| | | |_____________________________________________________________________|

   Any of the fields may be absent.

分野のいずれも欠けているかもしれません。

   The _name_ is a symbolic name of the term in the usual programming
   language sense.  It is a single, lower-case alphabetic that is unique
   within a rule.

_という_名は普通のプログラミング言語意味における用語の英字名です。 それがa単一であって、小文字である、アルファベット、それは規則の中でユニークです。

   The _data type_ describes the kind of data that the term represents.
   It is a member of the set:

_データ型_は用語が表すデータの種類について説明します。 それはセットのメンバーです:

         {D, O, X, A, E, B}

D、O、X、A、E、B

      Data types have the following meanings and implied unit lengths:

データ型には、以下の意味と暗示しているユニット長があります:

      Char.       Meaning               Length
      -----       --------              -------
       D          decimal number        1 bit
       O          octal number          3 bits
       X          hexadecimal number    4 bits
       A          ASCII character       8 bits
       E          EBCDIC character      8 bits
       B          binary number         1 bit

焦げてください。 意味の長さ----- -------- ------- 8ビットの8ビットの1ビットの4ビットの3ビットの1ビットのD10進数O8進数X16進数A ASCII文字E EBCDlC文字Bバイナリー番号

   The _replication expression_ is a multiplier of the value expression.
   A replication expression has the formats.

_模写式_は値の式の乗数です。 模写式には、形式があります。

      1)  an arithmetic expression of the members of the set:

1) セットのメンバーの算術式:

          {v(name), L(name) , numerals, programming variables}

v(名前)、L(名前)、数字、プログラミング変数

      The v(name) is a value operator that generates a numeric value of
      the named data type and L(name) is a length operator that
      generates a numeric value of the named string length.

v(名前)は存在という命名されたデータ型とL(名前)の数値が命名されたストリング長の数値を生成する長さのオペレータであると生成する値のオペレータです。

      The programming variable is described under term format three.
      Arithmetic operators are shown below and have their usual
      meanings.

プログラミング変数は用語形式threeの下で説明されます。 算術演算子は、それらの普通の意味を下に示されて、持っています。

         {*, /, +, -}

{*, /, +, -}

Anderson, et. al.                                               [Page 3]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [3ページ] データ1970年12月18日のRFC83言語マシン

   or 2) the terminal '#' which means an arbitrary multiple of the value
           expression.

または、2)価値の任意の倍数を意味する端末の'#'式。

   The _value expression_ is the unit value of a term expressed in the
   format indicated by the data type.  The value expression is repeated
   according to the replication expression.  A value expression has the
   format:

_値の式_はデータ型によって示された書式で表された用語の単価です。 模写式に従って、値の式は繰り返されます。 値の式には、形式があります:

      1) same as part 1) of the replication expression where again
         v(name) produces a numeric value

1)、第1部と同じこと)、模写では、式は再び(名前)に対して生産するところで数値を生産します。

   or 2) a single member of the set

または、セットの2の)a独身のメンバー

         {v(name), quoted literal}

v(名前)、引用されたリテラル

         where v(name) produces a data type (E or A) value).  (Note that
         concatenation is accomplished through multiple terms.)

v(名前)がデータ型(EかA)値)を作り出すところ。 (連結が複数の期間を通して実行されることに注意してください。)

   The _length expression_ is the length of the field containing the
   value expression as modified by the replication expression.  It has
   the same formats as a replication expression.

_長さの式_は変更されるとしての値の式ごとに含む分野の長さです。 それには、模写式と同じ形式があります。

   Thus, the term

その結果、用語

      x(E(7.'F'):L(x)) is named x, is of type EBCDIC, has the value
      'FFFFFFF' and is of length 7.

x、(E(7'F'): L(x))は7にxと命名されて、タイプEBCDICにはあって、値の'FFFFFFF'を持って、長さのものです。

   The term

用語

      y(A:8) on the left-hand-side of a rule would be assigned the next
      64 bits of input as its value; on the right-hand-side it would
      only cause the output pointer to be advanced 64 bit positions
      because is has no value expression (contents) to generate data in
      the output area.

次の64ビットの入力は値として規則の左側のy(A:8)に割り当てられるでしょう。 正しい手の側では、それが、出力指針が高度な64のビット位置であることを引き起こすだけであるだろう、出力領域でデータを生成する値の式(コンテンツ)を全く持っていません。

Anderson, et. al.                                               [Page 4]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [4ページ] データ1970年12月18日のRFC83言語マシン

Term Format 2
+---------------------------------------------------------------------+
|                                                                     |
|           name (label)                                              |
|                                                                     |
+---------------------------------------------------------------------+

用語形式2+---------------------------------------------------------------------+ | | | 名前(ラベル)| | | +---------------------------------------------------------------------+

   The _label_ is a symbolic reference to a previously named term in the
   rule.  It has the same value as the term by that name.

_ラベル_は規則による以前に命名された用語のシンボリックな参照です。 それには、その名前の用語と同じ値があります。

   The identity operation below illustrates the use of the _label_
   notation.

以下での一致演算は_ラベル_記法の使用を例証します。

      a(A:10) -> (a)

(A:10)->。(a)

   The (a) on the right-hand side causes the term a to be emitted in the
   output area.  It is equivalent to the rule below.

右側の(a)は出力領域でaという用語を放たせます。 それは以下の規則に同等です。

      a(A:10) -> (Av(a):L(a))

(A:10)->。(Av(a): L(a))

Term Format 3
+---------------------------------------------------------------------+
|                                                                     |
|   name    (  programming    connective        operand  )            |
|              variable                       expression              |
|                                                                     |
+---------------------------------------------------------------------+

用語形式3+---------------------------------------------------------------------+ | | | 名前(接続的なオペランドをプログラムします)| | 可変式| | | +---------------------------------------------------------------------+

   A _programming variable_ is a user-controlled data item that does not
   explicitly appear in the input/output streams.  Its value can be
   compared to input data, to constants, and used to generate output
   data.  Programming variables are single, lower case Greek symbols.

可変_をプログラムする_は入力/出力ストリームに明らかに現れないユーザによって制御されたデータ項目です。データを定数に入力して、以前はよく出力がデータであると生成していたために値は比較できます。 プログラミング変数はただ一つの小文字のギリシア語シンボルです。

   They are used: to generate indices, counters, etc. in the output
   area; to compare indices, counters, etc. in the input area, and; to
   bind replacement rules where the data is context sensitive (explained
   later).

それらは使用されています: 出力領域でインデックスリスト、カウンタなどを生成するために。 そして、入力領域でインデックスリスト、カウンタなどを比較するために。 交換を縛るのはデータが文脈機密である(後で説明されます)ところで統治されます。

   A _connective_ is a member of the set:

_の接続的な_はセットのメンバーです:

         {<-, =, !=, >=, <=, <, >}

<、=、=、>=、<=、<、>。

   The left arrow denotes replacement of the left part by the right
   part; the other connectives are comparators.

右の部分に従って、左向きの矢は左辺の交換を指示します。 他の接続する物は比較器です。

Anderson, et. al.                                               [Page 5]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [5ページ] データ1970年12月18日のRFC83言語マシン

   The _operand expression_ is an arithmetic expression of members of
   the set:

_オペランド式_はセットのメンバーの算術式です:

         {programming variables, v(name), l(name), numerals}

(名前)、l(名前)、数字に対して変数をプログラムします。

   For example, if the programming variable [alpha] has the value 0 and
   the rule

プログラミング変数[アルファ]には、値0があるかどうか、そして、例えば、規則

      a(H[alpha]:1) -> (a), ([alpha]<-[alpha]+1), (H[alpha]:1)

(H[アルファ]: 1)->(a)、([アルファ]<[アルファ]+1)(H[アルファ]: 1)

   is applied exhaustively to string of hexadecimal digits

16進数字のストリングに徹底的に適用されます。

      0 1 2 3 4 5

0 1 2 3 4 5

   the output would be the hexadecimal string

出力は16進ストリングでしょう。

      0 1 1 2 2 3 3 4 4 5 5 6 .

0 1 1 2 2 3 3 4 4 5 5 6 .

   Note:  the above rule is equivalent to

以下に注意してください。 規則が相当している上記

      a(B[alpha]:4) -> (a), ([alpha]<-[alpha]+1), (B[alpha]:4)

(B[アルファ]: 4)->(a)、([アルファ]<[アルファ]+1)(B[アルファ]: 4)

IV.  Restrictions and Interpretations of Term Functions

IV。 用語機能の制限と解釈

   When a rule succeeds output will be generated.  In the rule

規則が成功するとき、出力は生成されるでしょう。 規則で

      a(A:#),(A'/':1)->(Ev(a):74),(E'?':1)

'a(A:#)、('/': 1)->(Ev(a): 74)(E'?': 1)

   the input string is searched for an arbitrary number of ASCIIs
   followed by a terminal '/'.  The ASCIIs (a) are converted to EBCDIC
   in a 74-byte field followed by a terminal '?'.  This brings out three
   issues:

'入力ストリングは端末の'/'があとに続いたASCIIsの特殊活字の数字を捜されます。 ASCIIs(a)は端末の'?'によって続かれた74バイトの野原の中でEBCDICに変換されます。 これは3冊を持ち出します:

      1. Arbitrary length terms must be separated by literals since the
         data is not type-specific.

1. データがタイプ特有でないので、リテラルで任意の長さの用語を切り離さなければなりません。

      2. The # may only be used on the left-hand-side of a rule.

2. #、は規則の左側で使用されるだけであるかもしれません。

      3. A truncation padding scheme is needed.

3. トランケーション詰め物体系が必要です。

Anderson, et. al.                                               [Page 6]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [6ページ] データ1970年12月18日のRFC83言語マシン

      The truncation padding scheme is as follows:

トランケーション詰め物体系は以下の通りです:

         a. Character to Character (types: A, E)

a。 キャラクターへのキャラクター(タイプ: A、E)

            Output is left-justified with truncation or padding (with
            blanks) on the right.

トランケーションか詰め物(空白がある)が右にある状態で、出力は左で正当です。

         b. Character to Numeric (A, E to D, O, H, B)

b。 数値へのキャラクター(A、EからD、O、H、B)

         c. Numeric to Character (D, O, H, B to A, E)

c。 キャラクターに、数値です。(D、O、H、BからA、E)

         d. Numeric to Numeric (D, O, H, B)

d。 数値に、数値です。(D、O、H、B)

            Output is right-justified with padding or truncation on the
            left.  Padding is zeros if output is numeric.

出力は左で詰め物かトランケーションでまさしく正当です。 出力が数値であるなら、詰め物はゼロです。

EXAMPLES OF SOME DATA RECONFIGURATIONS

いくつかのデータ再構成に関する例

   The following are examples of replacement rule types for specifically
   needed applications.

↓これは明確に必要なアプリケーションのための交換規則タイプに関する例です。

   Literal Insertion

文字通りの挿入

      To insert a literal, separate the left-hand-side terms for its
      insertion on the right.

リテラルを挿入するには、右における挿入のための左側用語を切り離してください。

         a(A:10),b(A:70)->(a),(E'LIT':3),(b)

'(A:10)、b(A:70)>(a)、(E'LIT、': 3)(b)

      The 80 ASCII characters are emitted in the output area with the
      EBCDIC literal LIT inserted after the first 10 ASCII characters.

80人のASCII文字がEBCDICの文字通りのLITが最初の10人のASCII文字の後に挿入されている出力領域で放たれています。

   Deletion

削除

      Terms on the left are separated so that the right side may omit
      unwanted terms.

左に関する用語は、右側が求められていない用語を省略できるように、切り離されます。

         (B:7),a(A:10)->(Ev(a):L(a))

(B: 7)、(A:10)->。(Ev(a): L(a))

      Only the 10 ASCII characters are emitted (as EBCDIC) in the output
      area, the 7 binary digits are discarded.

10人のASCII文字だけが出力領域で放たれていて(EBCDICとして)、7つのバイナリー・ディジットが捨てられます。

   Spacing in the Output Buffer

出力バッファのスペース

      Where a pre-formatted output buffer exists (typically a display
      buffer) spacing can be realized by omitting the replication and
      value functions from a term on the right.

プレフォーマット付き出力バッファが存在する(通常ディスプレイバッファ)ところに、権利に関する用語から模写と値の機能を省略することによって、スペースを実感できます。

Anderson, et. al.                                               [Page 7]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [7ページ] データ1970年12月18日のRFC83言語マシン

         a(A:74)->(E:6),(Ev(a):74)

(A:74)->(E: 6)(Ev(a): 74)

      The (E:6) causes 48 bit positions to be skipped over in the output
      area, then the 74 ASCII characters are converted to EBCDIC and
      emitted at the current output position.

48ビットが出力領域を飛び越えるために置く(E: 6)原因、次に、74人のASCII文字が、EBCDICに変換されて、経常産出高位置で放たれています。

   Arbitrary Lengths

任意の長さ

      Some devices/programs generate a variable number of characters per
      line and it is desirable to produce fixed-length records from
      them.

いくつかのデバイス/プログラムが可変数の1系列あたりのキャラクタを生成します、そして、それらから固定長レコードを作り出すのは望ましいです。

         a(A:#) -> (Ev(a):74)

(A:#)->。(Ev(a): 74)

      The ASCII characters are truncated or padded as required and
      converted to EBCDIC in a 74 character field.

ASCII文字は、74文字フィールドで先端を切られるか、必要に応じて水増しされて、またはEBCDICに変換されます。

   Transposition

転置

      Fields to be transposed should be isolated as terms on the left.

転移するべき野原は左に関する用語として分離されるべきです。

         a(X:2),b(A:#)->(Ev(b):L(b)),(a)

(X: 2)、b(A:#)->、(ev(b): L(b))(a)

   String Length Computation

ストリング長計算

      Some formats require the string length as part of the data stream.
      This can be accomplished by the length function.

いくつかの形式がデータ・ストリームの一部としてストリング長を必要とします。 長さの機能はこれを達成できます。

         a(E:10),b(X'FF':2)->(BL(a)+L(b)+8:8),(Av(a):L(a)),(b)

'(E: 10)、b、(X'FF、': 2) ->(BL(a)+L(b)+8: 8)、(Av(a): L(a))(b)

      The length term is emitted first, in a 8 bit field.  In this case
      the length includes the length field as well as the ASCII
      character field.

長さの用語は最初に、8ビットの分野で放たれています。 この場合、長さはASCII文字フィールドと同様に長さの分野を含んでいます。

   Expansion and Compression of repeated Symbols

繰り返されたSymbolsの拡張とCompression

      The following rule packs repeated symbols.

以下の規則パックはシンボルを繰り返しました。

         a(E:1), b(E#*v(a):L(b)) -> (BL(b)+1:8),(a)

(E: 1)、b、(E#*v(a): L(b))->(BL(b)+1: 8)(a)

      Given the input string below, three successive applications of the
      rule will emit the output string shown.

以下の入力ストリングを考えて、規則の3つの連続した応用が見せられた出力ストリングを放つでしょう。

         Input: XXXXYYZZZZZZZ

以下を入力してください。 XXXXYYZZZZZZZ

         Output: 4X2Y7Z

出力: 4X2Y7Z

Anderson, et. al.                                               [Page 8]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [8ページ] データ1970年12月18日のRFC83言語マシン

   APPLICATION OF THE FORM MACHINE TO PROGRAM PROTOCOLS

プログラムプロトコルへのフォームマシンのアプリケーション

   The Protocol Manager mentioned in NWG/RFC #80 needs several
   interesting features that are properties of the above Form Machine.

NWG/RFC#80で言及したプロトコルマネージャは上のForm Machineの特性であるいくつかのおもしろい特徴を必要とします。

   In certain instances during a protocol dialog it might be acceptable
   to get either an accept on connection A or an allocation on connect
   B, that is, the order is sometimes unimportant.  The defined
   procedure for applying rules allows for order independence.

接続のときにAか配分が進行中であると受け入れてください。得るのが許容できるかもしれないプロトコル対話の間のあるインスタンス、Bを接続してください、そして、すなわち、オーダーは時々重要ではありません。 規則を適用するための定義された手順はオーダー独立を考慮します。

   A logger might send us a socket number embedded in a regular message
   -- the socket number is intended to be the first of a contiguous set
   of sockets that we can use to establish connections with some
   program.  We wish to extract the socket number field from the regular
   message, perhaps convert it to another format, and add to it to get
   the additional socket names.  As a result of the regular message we
   wish to emit several INIT system calls that include the socket
   numbers that we have computed.  The value operator and the arithmetic
   operators of the Form Machine can do this.

きこりは通常のメッセージに埋め込まれたソケット番号を私たちに送るかもしれません--ソケット番号は私たちが、あるプログラムで関係を樹立するのに使用できる隣接のセットのソケットの1番目であることを意図します。 私たちは、追加ソケット名を得るために通常のメッセージからソケットナンバーフィールドを抽出することを願って、恐らく別の形式にそれを変換して、それに言い足します。 通常のメッセージの結果、私たちが計算したソケット番号を含んでいるいくつかのINITシステムコールを放ちたいと思います。 値のオペレータとForm Machineの算術演算子はこれができます。

   A third property of the Form Machine that is applicable to protocols
   is inter- and intra-rule binding to resolve context sensitive
   information.  In general we wish rules to be order independent but in
   certain cases we wish to impose an ordering.  Using the logger in
   NWG/RFC #66 as an example, the close that is sent by the logger can
   have two different meanings depending upon its context.  If the close
   is sent before the regular message containing the socket number then
   it means call refused.  If the regular message precedes the close
   then the call is accepted.  Since the close has contextual meaning,
   we must bind it to the regular message to avoid introducing IF and
   THEN into the Form Machine language.

そして、プロトコルに適切なForm Machineの3番目の特性がそうである、相互、決心に付くイントラ規則文脈機密情報。 一般に、私たちは、オーダーである規則が独立していることを願っていますが、ある場合には、注文を課したいと思います。 例としてNWG/RFC#66にきこりを使用して、きこりによって送られる閉鎖は文脈による2つの異なった意味を持つことができます。 ソケット番号を含む通常のメッセージの前に閉鎖を送るなら、それは、呼び出しが拒否したことを意味します。 通常のメッセージが閉鎖に先行するなら、呼び出しを受け入れます。 閉鎖には文脈の意味があるので私たちが導入するのを避ける通常のメッセージにそれを縛らなければならない、そして、Form Machine言語へのTHEN。

   Assume for a moment that we can express system calls in Form Machine
   notation.  (The notation below is for _illustration only_ and is not
   part of the Form Machine language.)  We have two ways to bind the
   regular message to the close.  By intra-rule binding we insist that
   the close be preceded by a regular message.

ちょっと、私たちがForm Machine記法でシステムコールを言い表すことができると仮定してください。 (以下の記法は、_イラスト_だけのためにあって、Form Machine言語の一部ではありません。) 私たちには、通常のメッセージを閉鎖に縛る2つの方法があります。 イントラ規則結合で、私たちは、通常のメッセージが閉鎖に先行すると主張します。

      Reg. Msg , Close ->

レッジエムエスジー、近い->。

   Now assume for a moment that the remote party must have an echo after
   each transmission.  Since we must emit an echo after receiving the
   regular message and before the close is sent, then we must use
   inter-rule binding.  This can be accomplished with the programming
   variable.  It is assigned a value when the regular message is
   received and the value is tested when the close is received.

今度は、ちょっと、リモートパーティーにはエコーが各トランスミッションの後になければならないと仮定してください。 通常のメッセージを受け取った後と閉鎖を送る前にエコーを放たなければならないので、そして、私たちは相互規則結合を使用しなければなりません。 プログラミング変数でこれを達成できます。 通常のメッセージが受信されているとき、値はそれに割り当てられます、そして、閉鎖が受け取られているとき、値はテストされます。

      Reg. Msg -> Echo , ([lambda]+1)

レッジエムエスジー->は反響します。[λ] +1)

Anderson, et. al.                                               [Page 9]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [9ページ] データ1970年12月18日のRFC83言語マシン

      Close, ([lambda]=1) ->

閉鎖、[λ]=1) ->。

   To illustrate inter-rule binding via the programming variable the
   connection protocol in NWG/RFC #66 could be represented by passing
   the following form to a protocol manager.  (The notation below is for
   _illustration only_ and is not part of the Form Machine language).

プログラミング変数で相互規則結合を例証するために、以下のフォームをプロトコルマネージャに渡すことによって、NWG/RFC#66における接続プロトコルを表すことができるでしょう。 (以下の記法は、_イラスト_だけのためにあって、Form Machine言語の一部ではありません。)

      1. ->INIT(parameters) , ([alpha]<-0)

1. ->イニット(パラメタ)([アルファ]<-0)

      Send an INIT(RTS).

イニット(RTS)を送ってください。

      2.  INIT(parameters) -> ALLOCATE(parameters)

2. (パラメタ)->が割り当てるイニット(パラメタ)

      Send an allocate in response to the connection completion (an STR
      received).

発信、接続に対応して、完成を割り当ててください(STRは受信しました)。

      3.  Reg. Msg (parameters) -> ([alpha]<-1)

3. レッジエムエスジー(パラメタ)->。([アルファ]<-1)

      When the messages bearing link numbers is received, set an
      internal indicator.  (The extraction of the link is not
      illustrated.)

リンク番号に堪えるのが受け取られているというメッセージである、ときには、内部標識を設定してください。 (リンクの抽出は例証されません。)

      4.  CLOSE(parameters),([alpha]=1) ->
                             INIT(parameters),INIT(parameters)

4. 閉鎖(パラメタ)、[アルファ]=1) ->イニット(パラメタ)、イニット(パラメタ)

      When the close is received following the regular message [2] is
      checked to see that the regular message was received before
      establishing the duplex connection.  If the close is received with
      no regular message preceding it (call refused) the form will fail
      (since no rules is satisfied).

通常のメッセージに従って、閉鎖が受け取られているとき、[2]は、重複の接続を確立する前に通常のメッセージが受け取られたのを確実にするためにチェックされます。 どんな通常のメッセージもそれに先行していなく閉鎖を受け取ると(呼び出しは拒否しました)、フォームは失敗するでしょう(規則が全く満たされていないので)。

   This protocol can be handled via a single form containing four
   replacement rules.  We have examined similar representations for more
   complex protocol sequences.  Such protocol sequences, stored by name,
   are an asset to the user; he can request a predefined sequence to be
   executed automatically.

4つの交換規則を含んでいて、ただ一つのフォームでこのプロトコルを扱うことができます。 私たちは、より複雑なプロトコル系列の同様の表現を調べました。 名前によって保存されたそのようなプロトコル系列はユーザへの資産です。 彼は、自動的に実行されるよう事前に定義された系列に要求できます。

Anderson, et. al.                                              [Page 10]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [10ページ] データ1970年12月18日のRFC83言語マシン

Two System Forms to Handle Protocol Statements

2システムは、プロトコル声明を扱うために形成されます。

   Assume that we have a Protocol Manager that manages protocol
   sequences between consoles and the Network.  The consoles generate
   and accept EBCDIC character strings and the Network transmits binary
   digits.  The console user has a language similar to system calls in
   which he can create and store protocol sequences via Protocol
   Manager, and at the same time he can indicate which commands are
   expected to be sent and which are to be received.  Upon command the
   Protocol Manager can execute this sequence with the Network,
   generating commands and validating those received.  Assume also that
   the Protocol Manager displays the dialog for the console user as it
   progresses.

コンソールとNetworkの間には、私たちにプロトコル系列を管理するプロトコルマネージャがいると仮定してください。 コンソールは、EBCDIC文字列を生成して、受け入れます、そして、Networkはバイナリー・ディジットを伝えます。 コンソールユーザには、彼がプロトコルマネージャを通してプロトコル系列を作成して、保存できるシステムコールと同様の言語があります、そして、同時に、彼はどのコマンドが送られるかと予想されて、どれを受け取られていさせることになっているかを示すことができます。 コマンドのときに、コマンドを生成して、プロトコルマネージャはNetworkと共にこの系列を実行できます、そして、それらを有効にするのは受信されました。 また、進歩をするときプロトコルマネージャがコンソールユーザのために対話を表示すると仮定してください。

   In order to translate between console and Network for generating,
   comparing, and displaying commands, the Protocol Manager can use the
   Form Machine.  Two system forms are needed, see Fig. 1.  One is a
   console-to-Network set of rules containing EBCDIC to binary for all
   legal commands; the other is a mirror image for Network-to-console.

コマンドを生成して、比較して、表示するためにコンソールとNetworkの間で翻訳するために、プロトコルマネージャはForm Machineを使用できます。 図1は、2つのシステムフォームが必要であることを見ます。 1つはコンソールからネットワークへのすべての法的なコマンドのためのバイナリーにEBCDICを含む規則のセットです。 もう片方がNetworkからコンソールのための鏡像です。

REQUEST

要求

   Since language design is not our forte, we would like comments from
   those with more experience than we.

言語デザインが得意でないので、私たちは、私たちより多くの経験があるそれらからコメントが欲しいと思います。

Anderson, et. al.                                              [Page 11]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [11ページ] データ1970年12月18日のRFC83言語マシン

                           System form:
                             C -> N
                           +----------+
                           | one rule |
                           | for each |
                           | legal    |
                           | command  |
                   +-------|- - - - - |<----+
                   |       +----------+     |
            Binary |                        | EBCDIC
                   |                        |
   +----------+    |                        |      +----------+
   |          |<---+                        +------|          |
   | Network  |                                    | Consoles |
   |          |----+                        +----->|          |
   +----------+    |                        |      +----------+
                   | Binary          EBCDIC |
                   |                        |
                   |                        |
                   |       System form:     |
                   |          N -> C        |
                   |       +----------+     |
                   +------>|- - - - - |-----+
                           | one rule |
                           | for each |
                           | legal    |
                           | response |
                           +----------+

システムフォーム: C->N+----------+ | 1つの規則| | それぞれのために| | 法的| | コマンド| +-------|- - - - - | <、-、-、--+ | +----------+ | バイナリー| | EBCDIC| | +----------+ | | +----------+ | | <、-、--+ +------| | | ネットワーク| | コンソール| | |----+ +----->|、| +----------+ | | +----------+ | 2進のEBCDIC| | | | | | システムフォーム: | | N->C| | +----------+ | +------>|、- - - - - |-----+ | 1つの規則| | それぞれのために| | 法的| | 応答| +----------+

   Figure 1 -- Application of System Form for Protocol Management

図1--プロトコル管理のためのシステム形式の適用

Anderson, et. al.                                              [Page 12]

RFC 83                 Language Machine For Data        18 December 1970

etアンダーソン、アル。 [12ページ] データ1970年12月18日のRFC83言語マシン

Distribution List
-----------------

発送先リスト-----------------

   Alfred Cocanower - MERIT
   Gerry Cole - SDC
   Les Earnest - Stanford
   Bill English - SRI
   James Forgie - Lincoln Laboratory
   Jennings Computer Center - Case
   Nico Haberman - Carnegie-Melon
   Robert Kahn - BB&N
   Peggy Karp - MITRE
   Benita Kirstel - UCLA
   Tom Lawrence - RADC/ISIM
   James Madden - University of Illinois
   George Mealy - Harvard
   Thomas O'Sullivan - Raytheon
   Larry Roberts - ARPA
   Ron Stoughton - UCSB
   Albert Vezza- MIT
   Barry Wessler - Utah

Alfred Cocanower - MERIT Gerry Cole - SDC Les Earnest - Stanford Bill English - SRI James Forgie - Lincoln Laboratory Jennings Computer Center - Case Nico Haberman - Carnegie-Melon Robert Kahn - BB&N Peggy Karp - MITRE Benita Kirstel - UCLA Tom Lawrence - RADC/ISIM James Madden - University of Illinois George Mealy - Harvard Thomas O'Sullivan - Raytheon Larry Roberts - ARPA Ron Stoughton - UCSB Albert Vezza- MIT Barry Wessler - Utah

   [The original document included non-ASCII characters.  The Greek
   letters Alpha and Lambda have been spelled out and enclosed in
   square brackets "[ ]".  A curly "l" character
   has been replaced by capital L.  Left and right arrows have been
   replaced by "<-" and "->" respectively.  RFC-Editor]

[正本は非ASCII文字を含んでいました。 角括弧"[ ]"にギリシアの手紙アルファーとLambdaを詳しく説明して、同封しました。巻き毛の「l」キャラクタをあと資本L.に取り替えました、そして、それぞれ右向きの矢を"<"と"->"に取り替えました。 RFC-エディタ]

          [This RFC was put into machine readable form for entry]
          [into the online RFC archives by Lorrie Shiota, 10/01]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田によるオンラインRFCアーカイブへの10/01]

Anderson, et. al.                                              [Page 13]

etアンダーソン、アル。 [13ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Array.unshift

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る