RFC515 日本語訳
0515 Specifications for Datalanguage, Version 0/9. R. Winter. June 1973. (Format: TXT=60557 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Winter Request for Comments: 515 Computer Corporation of America NIC 16446 6 June 1973
コメントを求めるワーキンググループR.冬の要求をネットワークでつないでください: 515 アメリカNIC16446 1973年6月6日のコンピュータ社
Specifications for Datalanguage, Version 0/9
Datalanguageのための仕様、バージョン0/9
Preface
序文
Datalanguage is the language processed by the Datacomputer, a data utility system being developed for the Arpanet. The Datacomputer performs data storage and data management functions for the benefit of computers on the network.
DatalanguageはDatacomputerによって処理された言語であり、情報サービスはArpanetのために開発されるシステムです。 Datacomputerはコンピュータの利益のためにデータ保存とデータ管理機能をネットワークに実行します。
Version 0/9 is currently running at CCA. This version is extremely primitive; however, it does offer an opportunity for experience with the Datacomputer and with fundamental Datalanguage concepts.
バージョン0/9は現在、CCAで稼働しています。 このバージョンは非常に原始的です。 しかしながら、それはDatacomputerと基本的なDatalanguage概念の経験の機会を提供します。
Subsequent versions will provide greater portions of the full Datalanguage capability, which has been described earlier (Datalanguage, Working Paper No. 3, Datacomputer Project, October, 1971, NIC 8028). For example, one of the primary restrictions in 0/9--elementary data items must be fixed-length ASCII strings--will be eliminated in Version 0/10, which is currently being implemented.
その後のバージョンは完全なDatalanguage能力(Datalanguage、Working Paper No.3、1971年NIC8028年10月のDatacomputer Project)のより大きい部分を提供するでしょう。(能力は、より早く説明されます)。 例えば、基本のデータ項目が固定長ASCIIストリングであるに違いないという0/9におけるプライマリ制限の1つはバージョン0/10で排除されるでしょう。(それは、現在、実装されています)。
Based on the experience gained in the implementation of these early versions, and based on the feedback from their use, a revised specification of the full language will be issued.
これらの早めのバージョンの実装で獲得されて、彼らの使用からフィードバックに基づく経験に基づいて、完全な言語に関する訂正明細書を発行するでしょう。
1. Introduction
1. 序論
This document presents a precise and complete specification of Datalanguage, Version 0/9. It is organized into 11 sections, of which this introduction is the first. Section 2 discusses the capabilities of Version 0/9 in general terms. Sections 3 and 4 are concerned with data description and the directory. Sections 5 through 8 cover the expression of data management operations. Section 9 discusses the recognition of names. Section 10 covers miscellaneous topics and Section 11 specifies the syntax in BNF.
このドキュメントはDatalanguage、バージョン0/9の正確で完全な仕様を提示します。 それは11のセクションに組織化されます。(そこでは、この序論が1番目です)。 セクション2はあいまいな言葉でバージョン0/9の能力について論じます。セクション3と4はデータ記述とディレクトリに関係があります。 セクション5〜8はデータ管理操作の式をカバーします。 セクション9は名前の認識について論じます。 セクション10は種々雑多な話題をカバーします、そして、セクション11はBNFの構文を指定します。
This specification is to be followed with a user manual, which will present the language in tutorial form and treat components of the Datacomputer-user interface other than the language.
この仕様は利用者マニュアルで続かれることです。(それは、個人指導用のフォームに言語を提示して、言語を除いて、Datacomputer-ユーザーインタフェースのコンポーネントを扱うでしょう)。
Winter [Page 1] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[1ページ]のRFC515仕様、バージョン0/9 1973年6月6日
2. Capabilities of Version 0/9
2. バージョン0/9の能力
Version 0/9 of Datalanguage has capabilities for the storage of files; for addition of data to existing files, and for the deletion of files. Retrievals can output whole files as well as subsets of files. Data can be selected from files by content, using expressions formed from boolean and inequality operators.
Datalanguageのバージョン0/9には、ファイルのストレージのための能力があります。 既存ファイルへのデータの追加、およびファイルの削除のために。 Retrievalsはファイルの部分集合と同様に全体のファイルを出力できます。 論理演算子から形成された式と不等式オペレータを使用して、内容はファイルからデータを選択できます。
At the option of the file creator, an inversion is constructed and maintained by the Datacomputer. The inversion increases the efficiency of selective retrieval, at the cost of storage space and file maintenance effort. Users other than the file creator need not be aware of the existence of the inversion, or of which fields are inverted file keys. The language is designed so that they state the desired result of a retrieval, and the Datacomputer uses the inversion as much as the request permits.
ファイルクリエイターの選択のときに、逆は、Datacomputerによって構成されて、維持されます。 逆は集積スペースとファイルメインテナンス取り組みの費用で選択している検索の効率を増強します。 ファイルクリエイター以外のユーザは逆の存在、またはどの分野が転置ファイルキーであるかを意識している必要はありません。 言語は彼らが検索の必要な結果を述べるように、設計されています、そして、要求が可能にするほどDatacomputerは逆を使用します。
Elementary data items are fixed-length ASCII strings. Files are a restricted class of hierarchical structures.
基本のデータ項目は固定長ASCIIストリングです。 ファイルは制限されたクラスの階層構造です。
Many of the restrictions mentioned in this memo will be short-lived. In particular, those statements followed with 3 asterisks (***) refer to restrictions that will be considerably weakened or eliminated entirely in the next version of the software.
このメモで言及された制限の多くが短命になるでしょう。 特に、3つのアスタリスク(***)で従われたそれらの声明は完全なソフトウェアの次のバージョンでかなり弱められるか、または排除される制限を示します。
3. Data Description
3. データ記述
A container is a variable whose value is a data object of general character and arbitrary size (In Version 0/9, size is restricted. See section 3.4). Examples of containers which are implemented in other systems are files, records, fields, groups, and entries.
コンテナは値が一般的なキャラクタと任意のサイズのデータ・オブジェクトである変数です。(バージョン0/9では、サイズは制限されます。 セクション3.4を見てください。). 他のシステムで実装されるコンテナに関する例は、ファイルと、レコードと、分野と、グループと、エントリーです。
The container is distinct from the data in the container. For example, space allocation is an operation on a container, while changing the unit price field from 25 to 50 is an operation on data in a container.
コンテナはコンテナのデータと異なっています。 例えば、スペース割当てはコンテナにおける操作です、商品単価分野を25〜50に変えるのが、コンテナのデータにおける操作ですが。
A container may enclose other containers. When a container is not enclosed by another container, it is said to be outermost. If container A encloses container B, and no other container in A also encloses B, then A immediately encloses B.
コンテナは他のコンテナを同封するかもしれません。 コンテナが別のコンテナによって同封されないとき、それは一番はずれであると言われます。 コンテナAがコンテナBを同封して、また、Aで他のどんなコンテナもBを同封しないなら、Aはすぐに、Bを同封します。
A Datalanguage description is a statement of the properties of a container.
Datalanguage記述はコンテナの特性の声明です。
All containers have the attributes ident and type. Ident is a character string by which users refer to the container. Type determines the form of the container's value; the value can be
すべてのコンテナには、属性identとタイプがあります。 Identはユーザがコンテナについて言及する文字列です。 タイプはコンテナの価値のフォームを決定します。 値はそうであることができます。
Winter [Page 2] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[2ページ]のRFC515仕様、バージョン0/9 1973年6月6日
elementary, or it can consist of other containers. There are 3 types: LIST, STRUCT, and STRING(***). A LIST contains a group of containers having the same description. A STRUCT contains a group of containers, each of which has its own description. A STRING is a sequence of ASCII characters. While a STRING is not really an elementary item, it is handled as one in Version 0/9.
基本である、それは他のコンテナから成ることができます。 3つのタイプがあります: STRUCT、記載してください、そして、(***)を結んでください。 LISTは同じ記述を持っているコンテナのグループを含みます。 STRUCTはコンテナのグループを含みます。それはそれぞれそれ自身の記述を持っています。 STRINGはASCII文字の系列です。 STRINGが本当に基本項目でない間、それは1としてバージョン0/9で扱われます。
Certain containers can have other attributes. An outermost container has a function. The function attribute specifies whether the container is to be used for storage or for transmission.
あるコンテナは他の属性を持つことができます。 一番はずれのコンテナには、機能があります。 機能属性は、コンテナがストレージかトランスミッションに使用されることになっているかどうか指定します。
Size is some meaningful dimension of the container, which is type- dependent. It is used for space allocation and data stream parsing.
サイズはコンテナの何らかの重要な寸法です。(その寸法はタイプ扶養家族です)。 それはスペース割当てとデータ・ストリーム構文解析に使用されます。
An aggregate container (i.e., one that contains other containers) has as an attribute the description or descriptions of its components. Thus if S is a STRUCT containing A, B, and C, then the descriptions of A, B, and C are attributes of S.
集合コンテナ(すなわち、他のコンテナを含むもの)には、属性としてコンポーネントの記述か記述があります。 したがって、SがA、Bを含むSTRUCTとCであるなら、A、B、およびCの記述はSの属性です。
A STRING defined in certain contexts can have an inversion attribute. This is an access property that is not really local to the STRING, but is associated with it for convenience.
ある文脈で定義されたSTRINGは逆属性を持つことができます。 これは本当にSTRINGに地方ではありませんが、便宜のためにそれに関連づけられるアクセスの特性です。
3.1 Ident
3.1 Ident
The ident of a container is composed of alphanumeric characters,
the first of which is alphabetic. It may not consist of more than
100 characters.
コンテナのidentは英数字で構成されます。その第1はアルファベットです。 それは100以上のキャラクタから成らないかもしれません。
The elements of a STRUCT must have idents unique in the STRUCT.
STRUCTの要素で、identsはSTRUCTでユニークにならなければなりません。
3.2 Function
3.2 機能
The function of a container is either FILE, PORT, or TEMPORARY
PORT. When the function is FILE, then the container is used for
storage of data at the Datacomputer. When the function is PORT,
then the container is used for transmission of data into or out of
the Datacomputer. When the function is TEMPORARY PORT (which may
be abbreviated TEMP PORT), the container behaves like a PORT;
however, its description is not retained in the Datacomputer
beyond the session in which it is created.
コンテナの機能は、FILE、PORTかTEMPORARY PORTのどちらかです。 そして、機能がFILEであるときに、コンテナはデータ記憶にDatacomputerで使用されます。 そして、機能がPORTであるときに、コンテナはデータの伝達にDatacomputerの中、または、Datacomputerから使用されます。 機能がTEMPORARY PORT(簡略化されたTEMP PORTであるかもしれない)であるときに、コンテナはPORTのように反応します。 しかしながら、記述はそれが作成されるセッションのときにDatacomputerで保有されません。
Winter [Page 3] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[3ページ]のRFC515仕様、バージョン0/9 1973年6月6日
3.3 Type
3.3 タイプ
Type is one of: LIST, STRUCT, or STRING. These are defined on the
preceding page.
タイプ、以下が1つがあります。 リスト、STRUCT、またはストリング。 これらは前のページで定義されます。
In an occurrence of a STRUCT, the elements appear in the order in
which their descriptions appear in the STRUCT description. All
elements are present in each occurrence of the STRUCT.
STRUCTの発生では、要素は彼らの記述がSTRUCT記述に現れるオーダーに現れます。 すべての要素がSTRUCTの各発生で存在しています。
An element of a STRUCT or LIST can be a container of any datatype.
However, the outermost container must be a LIST(***).
STRUCTかLISTの要素はどんなデータ型式のコンテナであるかもしれません。 しかしながら、一番はずれのコンテナはLISTであるに違いありません(***)。
3.4 Size
3.4 サイズ
The size of a STRING is the number of characters in it. The size
of a STRUCT is not defined (***). The meaning of the size of a
LIST depends upon other properties of the LIST (***).
STRINGのサイズはそれのキャラクタの数です。 STRUCTのサイズは定義されません(***)。 LISTのサイズの意味はLIST(***)の他の特性に依存します。
Ordinarily, the size of a LIST is the number of LIST-members. An
exception is the case of the outermost-LIST. In an outermost-LIST
with a function of FILE, the size is the number of LIST-members
for which space should be allocated. When no size is present in
this case, the system computes a default. In an outermost-LIST
with a function of PORT, the size is ignored (***).
通常、LISTのサイズはLIST-メンバーの数です。 例外は一番はずれのLISTに関するケースです。FILEの機能がある一番はずれのLISTでは、サイズはスペースが割り当てられるべきであるLIST-メンバーの数です。 どんなサイズもこの場合存在していないとき、システムはデフォルトを計算します。 PORTの機能がある一番はずれのLISTでは、サイズは無視されます(***)。
Only outermost containers may be larger than a TENEX page (2560
ASCII characters)(***).
一番はずれのコンテナだけがTENEXページ(2560人のASCII文字)(***)より大きいかもしれません。
3.5 Inversion
3.5 逆
An inversion is an auxiliary data structure used to facilitate
retrieval by content.
逆は内容で検索を容易にするのに使用される補助のデータ構造です。
Its basic application is the fast retrieval of sets of outermost-
LIST-members (this can be extended to other container sets, and
will be after release 1). Consider a list of weather
observations, stored as a file on the Datacomputer. If quick
retrieval of observations by COUNTRY is desired, then this is
indicated in the description of the COUNTRY container. According
to common usage in information retrieval, this makes COUNTRY a key
in the retrieval of observations.
基本出願は一番はずれのLIST-メンバーのセットの速い検索(これは、他のコンテナセットに広げることができて、リリース1の後に、ある)です。 Datacomputerのファイルとして保存された気象観測のリストを考えてください。 COUNTRYによる観測の迅速な検索が望まれているなら、これはCOUNTRYコンテナの記述で示されます。 情報検索による一般的な用法によると、これは観測の検索でCOUNTRYをキーにします。
Note that the inversion option only affects the efficiency of
retrieval by COUNTRY, not the ability to retrieve by COUNTRY.
逆オプションがCOUNTRYで検索する能力ではなく、COUNTRYによる検索の効率に影響するだけであることに注意してください。
Winter [Page 4] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[4ページ]のRFC515仕様、バージョン0/9 1973年6月6日
There are restrictions on use of the inversion option. First, it
can be applied only to STRINGs. Second a STRING having the
inversion option must occur only once in each
outermost-LIST-member. Third, it is ignored when applied to
STRINGs in PORT descriptions.
逆オプションの使用には制限があります。 まず最初に、それをSTRINGsだけに適用できます。 逆オプションを持っているSTRINGがそれぞれの一番はずれのLISTメンバーに一度だけ起こらなければならない秒。 3番目に、PORT記述でSTRINGsに適用されると、それは無視されます。
Eventually there will be several types of inversion option; in
Version 0/9 there is only the 'D' option (for distinct).
結局、いくつかのタイプの逆オプションがあるでしょう。 バージョン0/9には、'D'オプションしかない、(異なる、)
3.6 Syntax
3.6構文
The description is simply an enumeration of properties; these
properties are specified in the order:
記述は単に特性の列挙です。 これらの特性はオーダーで指定されます:
<ident> <function> <type> <size> <other>
><他の<ident><機能><タイプ><サイズ>。
Properties which do not apply are omitted. An example:
適用されない特性は省略されます。 例:
F FILE LIST (25) A STR (10)
Fファイルは(25) STRを記載します。(10)
Here 'F' is the <ident>, 'FILE' is the <function>, 'LIST' is the
<type>, '(25)' is the size, and 'A STR (10)' is the <other> of one
description. Of course, 'A STR (10)' is itself another
description: the description for members of the LIST named F.
ここで、'F'は<ident>です、そして、'FILE'は<機能>です、そして、'LIST'<はタイプ>です'(25)'はサイズです、そして、'STR(10)'は1つの記述の<他の>です。 もちろん、'STR(10)'はそれ自体で別の記述です: LISTのメンバーのための記述はFを命名しました。
An example of a complete description for a file of weather
observations keyed on location:
位置で合わせられた気象観測のファイルのための完全な記述に関する例:
WEATHER FILE LIST
OBSERVATION STRUCT
LOCATION STRUCT
CITY STR (10), I=D
COUNTRY STR (10), I=D
END
TIME STRUCT
YEAR STR (2)
DAY STR (3)
HOUR STR (2)
END
DATE STRUCT
TEMPERATURE STR (3)
RAINFALL STR (3)
HUMIDITY STR (2)
END
END
The ENDs are needed to delimit the list of elements of a STRUCT.
`, I=D' indicates that the string is to be an inversion key for
the retrieval of outermost-LIST-members.
WEATHER FILE LIST OBSERVATION STRUCT LOCATION STRUCT CITY STR(10)、I=D COUNTRY STR(10)、I=D END TIME STRUCT YEAR STR(2)DAY STR(3)HOUR STR(2)END DATE STRUCT TEMPERATURE STR(3)RAINFALL STR(3)HUMIDITY STR(2)END END ENDsがSTRUCTの要素のリストを区切るのが必要です。 '、I=D、'ストリングが一番はずれのLISTメンバーの検索に、主要な逆であることであることを示します。
Winter [Page 5] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[5ページ]のRFC515仕様、バージョン0/9 1973年6月6日
4. Directory
4. ディレクトリ
The directory is a system file in which the names and descriptions of all user-defined containers are kept.
ディレクトリはすべてのユーザによって定義されたコンテナの名前と記述が保たれるシステムファイルです。
The directory is structured as a tree. Each node has an ident, which need not be unique. There is a single path from the root of the tree to any node. The idents of the nodes along this path are concatenated, separated by periods, to form a pathname, which unambiguously identifies the node (e.g., A.B.C could be a pathname for node with an ident of C).
ディレクトリは木として構造化されます。 各ノードにはidentがあります。(identはユニークである必要はありません)。 木の根からどんなノードまでもただ一つの経路があります。 この経路に沿ったノードのidentsは、周期的にパス名を形成するために連結されて、切り離されます(例えば、A.B.CはCのidentがあるノードのためのパス名であるかもしれません)。(明白に、パス名はノードを特定します)。
In a later version of the software, the directory will be generalized to provide for links between nodes, so that it will not properly be a tree. For now, however, the tree model is convenient and adequate.
ソフトウェアの後のバージョンでは、ディレクトリはノードの間のリンクに備えるために広められるでしょう、適切に木にならないように。 しかしながら、当分、木のモデルは、便利であって、適切です。
A node may represent a container, or it may simply hold a place in the space of pathnames. When it represents a container, it cannot (currently) have subordinate nodes.
ノードがコンテナを表すかもしれませんか、またはそれはパス名のスペースに単に場所を保持するかもしれません。 (現在)コンテナを表すとき、それは下位のノードを持つことができません。
Eventually, it is planned to model the directory as a structure of containers, with its description distributed throughout the structure. Most operations defined on the directory will be defined on user data, and vice versa. Access privileges and privacy locks will be part of the data description and will likewise be applicable both to directory nodes and data structures below the node level.
結局、記述が構造中に広げられている状態でコンテナの構造としてディレクトリをモデル化するのは計画されています。 ディレクトリの上で定義されたほとんどの操作が利用者データで定義されるでしょう、そして、逆もまた同様です。 アクセス権とプライバシー錠は、データ記述の一部であり、ノードレベルの下で同様にディレクトリノードとデータ構造に適用されるようになるでしょう。
4.1 CREATE
4.1は作成します。
A CREATE-request either; (a) adds a node to the directory,
optionally associating the description of either a PORT or a FILE
with the node, or (b) creates a temporary container which is not
entered in the directory, but has a description and can be
referenced in requests. If the description defines a file, CREATE
causes space to be allocated for the file.
AはどちらかをCREATE要求します。 (a) ディレクトリ、任意にノードによるPORTかFILEのどちらかの記述を関連づけるか、または(b)へのノードがディレクトリに入れられない一時的なコンテナを作成すると言い足しますが、記述を持って、要求で参照をつけることができます。 記述がファイルを定義するなら、CREATEはファイルのためにスペースを割り当てさせます。
To create a node with a description:
CREATE <pathname> <description> ;
To create a node with no description:
CREATE <pathname> ;
Note that the description determines whether or not the container
is temporary (see section 3.2 for details).
記述でノードを作成するために: <パス名><記述>を作成してください。 記述なしでノードを作成するために: <パス名>を作成してください。 記述が、コンテナが一時的であるかどうか(詳細に関してセクション3.2を見てください)決定することに注意してください。
Winter [Page 6] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[6ページ]のRFC515仕様、バージョン0/9 1973年6月6日
A CREATE-request adds a single node to the directory. Thus to add
CCA.RAW.F to an empty directory, three requests are needed:
CREATE CCA ;
CREATE CCA.RAW ;
CREATE CCA.RAW.F ;
Notice that the last ident of the pathname doubles as the first
ident of the description:
CREATE CCA.RAW.G FILE LIST A STR (5) ;
CREATE-要求はただ一つのノードをディレクトリに追加します。 したがって、空のディレクトリにCCA.RAW.Fを追加するために、3つの要求が必要です: CCAを作成してください。 CCA.RAWを作成してください。 CCA.RAW.Fを作成してください。 パス名の最後のidentを記述の最初のidentの役目も兼ねるのに注意してください: CCA.RAW.Gを作成してください。ファイルはSTR(5)を記載します。
That is, G is both the ident of a node and the ident of an
outermost container of type LIST.
すなわち、GはノードのidentとタイプLISTの一番はずれのコンテナのidentの両方です。
4.2 DELETE
4.2は削除します。
A DELETE-request deletes a tree of nodes and any associated
descriptions or data. The syntax is:
DELETE <pathname> ;
The named node and any subordinates are deleted.
DELETE-要求はどんなノードと関連記述やデータの木も削除します。 構文は以下の通りです。 <パス名>を削除してください。 命名されたノードとどんな部下も削除されます。
Note that to delete data while retaining the directory entry and
description, DELETE should not be used (see section 6.3 for the
proper method).
ディレクトリエントリと記述を保有している間、データを削除するのに、DELETEが使用されるべきでないことに注意してください(適切なメソッドに関してセクション6.3を見てください)。
4.3 LIST
4.3 リスト
The LIST-request is used to display system data of interest to a
user. It causes the data specified to be transmitted through the
Datalanguage output port.
LIST-要求は、ユーザにとって、興味深いシステムデータを表示するのに使用されます。 それはDatalanguage出力ポートを通して送られるために指定されたデータを引き起こします。
Several arguments of LIST apply to the directory. LIST %ALL
transmits all pathnames in the directory. LIST %ALL.%SOURCE
transmits all descriptions in the directory. Instead of %ALL, a
pathname can be used:
LIST <pn>.%ALL
Lists pathnames subordinate to <pn>.
LIST <pn>.%SOURCE
lists descriptions subordinate to the node represented by <pn>.
LISTのいくつかの議論がディレクトリに適用されます。 LIST%はディレクトリのすべてのパス名をすべて伝えます。 LIST%. %SOURCEはディレクトリにおけるすべての記述を伝えます。 %の代わりに、すべて、パス名を使用できます: LIST<pn>すべてのListsパス名が<pn>に下位に置かせる%。 LIST<pn>%SOURCEは<pn>によって表されたノードへの下位の記述を記載します。
For details about the LIST-request, see section 10.1.
LIST-要求に関する詳細に関しては、セクション10.1を見てください。
5. Opening and closing containers
5. コンテナを開けて、閉じます。
Containers must be open before they can be operated on.
それらで作動できる前にコンテナは開いているに違いありません。
A container is open when it is first created. It remains open until closed explicitly by a CLOSE-request or implicitly by a DELETE- request or by session end.
それが最初に作成されるとき、容器は開いています。 それはCLOSE-要求で明らかにそれとなくDELETE要求かセッション終わりで閉じられるまで開いたままで残っています。
Winter [Page 7] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[7ページ]のRFC515仕様、バージョン0/9 1973年6月6日
A closed container is opened by an OPEN-request. A temporary container is always open; a CLOSE-request deletes it.
閉じている容器はオープン要求で開けられます。 一時的な容器はいつも開いています。 CLOSE-要求はそれを削除します。
5.1 Modes
5.1のモード
An open container has a mode, which is one of: READ, WRITE, or
APPEND. The mode determines the meaning and/or legitimacy of
certain operations on the container.
ふたなし容器には、以下についてモードがあります。(それは、1です)。 読むか、書くか、または追加します。 モードは容器の上で、ある操作の意味、そして/または、合法性を決定します。
The mode is established by the operation which opens the
container. It can be changed at any time by a MODE-request. A
CREATE leaves the container in WRITE mode. An OPEN either
specifies the mode explicitly or implicitly sets the mode to READ.
モードは容器を開ける操作で確立されます。 いつでも、MODE-要求でそれを変えることができます。 CREATEはWRITEモードで容器を出ます。 オープンは、明らかにモードを指定するか、またはそれとなくREADにモードを設定します。
5.2 Syntax
5.2構文
To open a container:
OPEN <pathname> <mode> ;
or:
OPEN <pathname> ;
where <mode> is defaulted to READ.
容器を開けるために: <パス名><モード>を開いてください。 または、: <パス名>を開いてください。 <モード>がどこにあるかがREADをデフォルトとしました。
To close a container:
CLOSE <ident> ;
where <ident> is the name of an outermost container.
容器を閉じるために: <ident>を閉じてください。 <ident>が一番はずれの容器の名前であるところ。
Two containers with the same outermost <ident> can not be
opened at the same time (***).
同時に(***)、同じ一番はずれの<ident>がある2個の容器を開けることができません。
To change the mode of an open container:
MODE <ident> <newmode> ;
ふたなし容器のモードを変えるために: モード<ident><newmode>。
5.3 LIST
5.3 リスト
LIST %OPEN transmits name, mode and connection status of each open
outermost container through the Datalanguage output port. (The
Datalanguage output port is the destination to which all
Datacomputer diagnostics and replies are sent. It is established
when the user initially connects to the Datacomputer.) For
details of the LIST-request, see section 10.1.
LIST%オープンはDatalanguage出力ポートを通してそれぞれの開いている一番はずれの容器の名前、モード、および接続形態を伝えます。 (Datalanguage出力ポートはすべてのDatacomputer病気の特徴と回答が送られる目的地です。 ユーザが初めはDatacomputerに接続するとき、それは確立しています。) LIST-要求の詳細に関しては、セクション10.1を見てください。
6. Assignment
6. 課題
Assignment transfers data from one container to another.
課題は1個の容器から別の容器までデータを移します。
The equal sign ('=') is the symbol for assignment. The value of the
operand on the right of the equal sign is transferred to the operand
on the left. (Eventually, both operands will be weakly-restricted
等号('=')は課題のシンボルです。 等号の右のオペランドの値を左のオペランドに移します。 (結局、両方のオペランドは弱々しく制限するようになるでしょう。
Winter [Page 8] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[8ページ]のRFC515仕様、バージョン0/9 1973年6月6日
Datalanguage expressions, which may evaluate to sets as well as to single containers. Now, the left must be a container name, the right may be a container name or a constant.)
Datalanguage表現。(その表現はセットと、そして、シングルに容器を評価するかもしれません)。 現在左が容器名であるに違いない、権利は、容器名か定数であるかもしれません。)
Assignment is defined for all types of containers. When the containers are aggregates, their elements are paired and data is transferred between paired elements. Elements of the target container that do not pair with some source element are handled with a default operation (currently they are filled with blanks).
課題はすべてのタイプの容器のために定義されます。 容器が集合であるときに、それらの要素は対にします、そして、対にされた要素の間にデータを移します。 何らかのソース要素と対にされない目標容器の要素はデフォルト操作で扱われます(現在のそれらは空白でいっぱいにされます)。
The operands of an assignment must have descriptions that match. The idea of matching is that the descriptions must be similar enough so that it is obvious how to map one into the other.
課題のオペランドには、合っている記述がなければなりません。 マッチングの考えは記述が十分同様でなければならないのでどのように1つをもう片方に写像するかが明白であるということです。
6.1 Conditions for legitimate assignment
6.1 正統の課題のための状態
Assignment must reference objects, not sets. An object is:
(a) an outermost container, or
(b) a constant, or
(c) in the body of a FOR-loop, either
(c1) a member of a set defined by a FOR-OPERAND, or
(c2) a container which occurs once in such a member
課題はセットではなく、参照物体がそうしなければなりません。 物は以下の通りです。 (a) 一番はずれの容器、(b) 定数、またはFOR-輪のボディーの(c)、1セットの(c1)メンバーはFOR-OPERAND、または(c2)容器でどれがそのようなメンバーに一度起こるかを定義しました。
In the case of a reference of type (c1), the object referenced is
taken to be the current member. In the case of (c2), the object
referenced is that which occurs in the current member. This is
explained further in section 7.
タイプ(c1)の参照の場合では、現在のメンバーになるように参照をつけられる物を取ります。 (c2)の場合では、参照をつけられる物は現在のメンバーに起こるそれです。 これはセクション7で、より詳しく説明されます。
The left operand of an assignment is subject to further
restriction. If it is an outermost container, it must be open in
either WRITE- or APPEND-mode. If it is not an outermost
container, then the reference is of type (c), which means that
some FOR-operand has established a context in which the assign-
operand is an object. The FOR-operand which establishes this
context must be the output-operand of the FOR.
課題の左のオペランドは、制限を促進するためになることがあります。 それが一番はずれの容器であるなら、WRITEかAPPEND-モードのどちらかで開いているに違いありません。 それが一番はずれの容器でないなら、タイプ(c)には参照があります。(タイプは、何らかのFOR-オペランドが案配オペランドが物である文脈を確立したことを意味します)。 この文脈を確立するFOR-オペランドはFORの出力オペランドであるに違いありません。
When the assign-operand is an outermost container, it must be
open. Such an operand must be referenced by its simple container
ident(***), not its directory pathname.
オペランドを割り当てるのが、一番はずれの容器であるときに、それは開いているに違いありません。 ディレクトリパス名ではなく、簡単な容器ident(***)がそのようなオペランドに参照をつけなければなりません。
In the body of a loop nested in one or more other loops,
assignments are further restricted, due to a 0/9 implementation
problem. See section 7.2 for details.
他の1つ以上の輪で入れ子にされた輪のボディーでは、課題はさらに制限されます、0/9実現問題のため。 詳細に関してセクション7.2を見てください。
Winter [Page 9] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[9ページ]のRFC515仕様、バージョン0/9 1973年6月6日
Finally, the descriptions of the operands must match. If one is a
constant, then the other must be a STRING(***). If both are
containers, then in the expression:
A = B;
the descriptions of containers A and B match if:
1. A and B have the same type
2. If A and B are LISTs, then they have equal numbers of
LIST-members, or else A is an outermost-LIST.
3. If A and B are aggregates, then at least one container
immediately enclosed in A matches, and has the same ident as, one
container immediately enclosed in B.
最終的に、オペランドの記述は合わなければなりません。 1つが定数であるなら、もう片方がSTRINGであるに違いありません(***)。 両方がそして、表現で容器であるなら: =B。 容器AとBの記述が合っている、: 1. AとBには、同じタイプ2があります。 彼らがAとBがLISTsであるなら等しい数のLIST-メンバーを持っているか、またはAは持っています。一番はずれのLIST3。 AとBが集合であるなら、当時の少なくとも1個の容器で、すぐにAにマッチを同封して、同じくらいはidentになります、すぐにBに同封されたある容器。
6.2 Result of assignment
6.2 課題の結果
If the operands are STRINGs, then the value of B, left-justified,
replaces the value of A. If B is longer than A, the value is
truncated. If B is shorter than A, then A is filled on the right
with blanks as necessary.
オペランドがSTRINGsであるなら、Bの左で正当な値はA.の値を取り替えます。If BはA、値が端が欠けているより長いです。 BがAより短いなら、空白が必要な状態でAは右にいっぱいにされます。
If the operands are STRUCTs, then assignment is defined in terms
of the STRUCT members. If a member of A, mA, matches and has the
same name as a member of B, mB, then mB is assigned to mA. If no
such mB exists, then mA is filled with blanks.
オペランドがSTRUCTsであるなら、課題はSTRUCTメンバーに関して定義されます。 Aのメンバー(mA)がBのメンバー、mBと同じ名前を合わせて、持っているなら、mBはmAに割り当てられます。 どれかそのようなmBが存在していないなら、mAは空白でいっぱいにされます。
If the operands are LISTs, the result depends on several factors.
First, notice that the descriptions of the LIST-members must
match; otherwise the assignment would not be legitimate by the
matching rules of 6.1.
オペランドがLISTsであるなら、結果はいくつかの要素に依存します。 まず最初に、LIST-メンバーの記述が合わなければならないのに注意してください。 さもなければ、課題は6.1の合っている規則で正統でないでしょう。
If A is an outermost-LIST, then it can be in either of two modes:
WRITE or APPEND. If A is in WRITE-mode, its previous contents are
first discarded; it is then handled as though it were in APPEND-
mode.
Aが一番はずれのLISTであるなら、それは2つのモードのどちらかにあることができます: 書くか、または追加します。 AがWRITE-モードであるなら、前の内容は最初に、捨てられます。 そして、それはまるでAPPENDモードであるかのように扱われます。
If A is not an outermost-LIST, then it is always effectively in
WRITE-mode.
WRITE-モードでAが一番はずれのLIST、いつも有効にその時であるというわけではないなら。
After taking the mode of A into account, as described above, the
procedure is:
for each member of LIST B
(a) add a new member to the end of A
(b) assign the current number of B to the new member of A
上で説明されるようにAのモードを考慮に入れた後に、手順は以下の通りです。 LIST B(a)の各メンバーに関しては、新しいA(b)の終わりまでのメンバーがAの新しいメンバーにBの最新号を割り当てると言い足してください。
Winter [Page 10] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[10ページ]のRFC515仕様、バージョン0/9 1973年6月6日
6.3 Deletion of Data Through Assignment
6.3 課題によるデータの削除
If A is an outermost container in WRITE-mode, and B is a container
with description that matches A, and if B contains no data, then
A=B has the effect of deleting all data from A. Note that if A is
in APPEND-mode in these circumstances, then A=B is a no-operation
(i.e., has no effect).
WRITE-モードでAが一番はずれの容器であり、Bが記述があるAに合っている容器であり、Bがデータを全く含んでいないなら、A=Bには、A.Noteからすべてのデータを削除するというAがAPPEND-モードでこういう事情ですからあるならA=Bが操作でない(すなわち、効き目がない)という効果があります。
7. FOR
7. for
FOR <output set spec>, <input set spec> <body> END ;
FOR<出力は仕様>、<入力セット仕様><ボディー>ENDを設定しました。
The output set is optional: that is, FOR need not produce output. When the output set is omitted, the syntax is:
出力セットは任意です: すなわち、FORは出力を起こす必要はありません。 出力セットが省略されるとき、構文は以下の通りです。
FOR <input set spec> <body> END ;
FOR<はセット仕様><ボディー>ENDを入力しました。
The operations specified in the body are performed once for each member of the input set. References in the body to the input set member are treated as references to the current input set member. When an output set is present, a new member is created and added to the output set for each iteration (i.e., for each input set member). References to the output set member, similarly, are treated as references to the current output set member.
ボディーで指定された操作は入力セットの各メンバーのために一度実行されます。 入力セットメンバーへのボディーでの参照は経常投入量セットメンバーについての言及として扱われます。 出力セットが存在しているとき、新しいメンバーは、各繰り返し(すなわち、それぞれの入力セットメンバーのための)のために出力セットに創造されて、追加されます。 出力セットメンバーについての言及は同様に経常産出高セットメンバーについての言及として扱われます。
The output set spec must be the name of a LIST member. Each iteration of the FOR will create one such member, and add it to its LIST (hereafter called the output LIST). The body terminates the value that the new member receives. Any STRING in the new member which is not given a value by the body receives he default value of all blanks.
出力セット仕様はLISTメンバーの名前であるに違いありません。 FORの各繰り返しは、LIST(今後、出力をLISTと呼ぶ)にそのようなメンバーのひとりを創造して、それを加えるでしょう。 ボディーは新しいメンバーが受ける値を終えます。 値がボディーによって与えられない新しいメンバーでは、彼は受信しています。どんなSTRING、もすべての空白のデフォルト値。
The input set spec must be an expression evaluating to a set of LIST-members (see section 7.1 for details of input set specification). Each iteration for the FOR will input one such member; the FOR will terminate when each member of the set has been processed. The LIST from which the input set members are drawn is called the input LIST.
入力セット仕様は1セットのLIST-メンバーに評価する表現であるに違いありません(入力セット仕様の細目に関してセクション7.1を見てください)。 FORのための各繰り返しはそのようなメンバーのひとりを入力するでしょう。 セットの各メンバーが処理されたとき、FORは終わるでしょう。 入力セットメンバーが引き出されるLISTは入力LISTと呼ばれます。
FOR is effectively a means of accomplishing variants of assignment
between a pair of LISTS. FOR is less concise than assignment, but
offers more flexibility. Its advantages are:
(a) not all the input LIST-members need be transferred to the
output LIST. A subset can be selected by content.
(b) the user has explicit control over the assignment of values to
output LIST-members.
事実上、FORは1組のLISTSの間の課題の異形を達成する手段です。 FORは課題ほど簡潔ではありませんが、より多くの柔軟性を提供します。 利点は以下の通りです。 (a) すべての入力LIST-メンバーが出力LISTに転勤にならなければならないというわけではありません。内容は部分集合を選択できます。 (b) ユーザは、LIST-メンバーを出力するために値の課題の上に明白なコントロールを持っています。
Winter [Page 11] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[11ページ]のRFC515仕様、バージョン0/9 1973年6月6日
This is most easily understood by an example:
P PORT LIST F FILE LIST
R STRUCT R STRUCT
B STR A STRUCT
C STR A1 STR
END A2 STR
B STR
C STR
END
これは最も容易に例に解釈されます: STRUCT C STR A1 STR終わりのA2 STR B STR C STRが終わらせるP左舷傾斜FファイルリストR STRUCT R STRUCT B STR
(1) P = F ;
(2) FOR P.R, F.R
P.R = F.R ;
END ;
(3) FOR P.R, F.R WITH A1 EQ 'XY' OR A2 GE 'AB'
B = C ;
C = A2 ;
END
(1) PはFと等しいです。 (2) P.Rに関しては、F.R P.RはF.Rと等しいです。 終わってください。 (3) P.Rに関しては、A1 EQ'XY'かA2ゲー'AB'BがあるF.RはCと等しいです。 CはA2と等しいです。 終わり
Here, (1) and (2) are entirely equivalent requests. However, (3) is quite different and is not expressible as assignment. It selects a subset of F.Rs. The values it gives to the P.Rs could not result from application of the matching rules to F and P.
ここで、(1)と(2)は完全に同等な要求です。 しかしながら、(3)は全く異なって、課題として表現できません。 それはF.Rsの部分集合を選択します。 それがP.Rsに与える値は合っている規則の適用からFとPに生じることができませんでした。
Because FOR is effectively assignment between a pair of LISTs, the LISTs referenced by a legitimate FOR-operation are largely subject to the same restrictions as LISTs referenced in an assignment. One exception is that the descriptions of the LIST-members need not match.
FORが事実上1組のLISTsの間の課題であるので、正統のFOR-操作で参照をつけられるLISTsは課題で参照をつけられるLISTsと同じ制限を主に受けることがあります。 1つの例外はLIST-メンバーの記述が合う必要はないということです。
These restrictions are:
(a) both LISTs must be objects in the context in which the FOR
appears.
(b) both LISTs must be open or contained in open outermost
containers.
(c) if the output LIST is an outermost container, it must be in
WRITE- or APPEND-mode.
(d) If the output LIST is not outermost, the LIST which most
immediately encloses it must be the output LIST of an enclosing
FOR.
これらの制限は以下の通りです。 (a) 両方のLISTsはFORが現れる文脈の物であるに違いありません。 (b) 両方のLISTsは開くか開いている一番はずれの容器に含まなければなりません。 (c) 出力LISTが一番はずれの容器であるなら、それはWRITEかAPPEND-モードであるに違いありません。 (d) 出力LISTが一番はずれでないなら、最もすぐにそれを同封するLISTは同封FORの出力LISTであるに違いありません。
The mode of the output LIST of the FOR affects the result much as it would in an assignment: that is, a FOR outputting to a LIST in WRITE-mode overwrites previous contents, while a FOR outputting to a LIST in APPEND-mode adds to previous contents.
FORの出力LISTのモードは課題で影響するように結果に影響します: すなわち、WRITE-モードでLISTに出力するFORは前のコンテンツを上書きします、APPEND-モードでLISTに出力するFORが前のコンテンツに加えますが。
Winter [Page 12] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[12ページ]のRFC515仕様、バージョン0/9 1973年6月6日
CAUTION TO THE READER: For convenience, these specifications use phrases such as 'LISTs referenced by a FOR'. Recall that such a phrase is not literally correct, in the sense that the operands of a FOR are always LIST members, not LISTs.
読者への警告: 便宜のために、これらの仕様は'FORによって参照をつけられたLISTs'などの句を使用します。 そのような句がFORのオペランドがいつもLISTメンバーであるという意味で文字通り正しくないと思い出してください、LISTsでない。
7.1 Details of input set specification
入力の7.1の詳細が仕様を設定します。
The input set is specified by a Datalanguage expression that
evaluates to a set of LIST-members. Such an expression can be
simply the set of all members of a LIST, or it can be a subset of
the members of a LIST, specified by content. For example, with
the description:
入力セットはそれが1セットのLIST-メンバーに評価するDatalanguage表現で指定されます。 そのような表現は単にLISTのすべてのメンバーのセットであるかもしれませんかそれが内容によって指定されたLISTのメンバーの部分集合であるかもしれません。 例えば記述で:
F FILE LIST
R STRUCT
A STR (1)
B STR (2)
END
STR(1)B STR(2)が終わらせるFファイルリストR STRUCT
the expression:
F.R
references all R's on the LIST F. However:
F.R WITH A EQ '5'
references only those R's containing an A having the value '5'.
The expressions permitted as input set specifications are of the
form:
<list-member-name> WITH <boolexp>
The <boolexp> is constructed of comparison expressions joined by
the Boolean operators AND and OR. Any expression can be negated
with NOT.
表現: F.RはLIST F.Howeverの上のRのすべてのものに参照をつけます: F.R WITH A EQ'5'は、それらのRだけが値'5'を持っているAを含むのに参照をつけます。 入力セット仕様がフォームのものであって、表現は可能にしました: <boolexp>が組み立てられるメンバ名>WITH<boolexp>を記載された<比較表現は論理演算子ANDとORのそばで接合しました。 NOTでどんな表現も否定できます。
Comparison operators have the highest precedence. Next highest is
AND, then OR, then NOT.
比較オペレータには、最も高い先行があります。 次に、最も高いのは、次に、ORの、そして、そしてそうしていないANDです。
The comparison expressions are restricted to the form:
<container name> <comop> <constant>
where:
(a) <constant> is a string constant enclosed in single quotes
(see section 10.2 for a discussion of constants)
(b) <comop> is one of six operators:
EQ equal
NE not equal
LT less than
GT greater than
LE less than or equal to
GE greater than or equal to
(c) <container name> is the name of a STRING that appears once
in each LIST-member.
比較表現はフォームに制限されます: <容器名の<のcomopの>の<の一定の>>、どこ: (a) <定数>はシングル・クォーテション・マーク(定数の議論に関してセクション10.2を見る)(b)<comop>に同封されたストリング定数が6人のオペレータのひとりであるということです: EQの等しいNEがLEよりすばらしいGTほどLTと等しくない、GE、(c) <容器名前>は各LIST-メンバーに一度現れるSTRINGというさらに名前以上です。
Winter [Page 13] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[13ページ]のRFC515仕様、バージョン0/9 1973年6月6日
The constant is truncated or padded with blanks on the right to
make it equal in size to the container to which it is being
compared. Notice that padding on the right is not always
desirable (users will have control over the padding in a future
release). In particular, care must be exercised when using
numbers in Version 0/9. (A number represented as a STRING should
actually be described as a number; eventually it will be possible
to do this).
定数は、先端を切られるか、または空白がそれをサイズにおいてそれが比較されている容器と等しくする権利にある状態で、水増しされます。 右でそっと歩くのがいつも望ましいというわけではないのに注意してください(ユーザは今後のリリースにおける詰め物を管理するでしょう)。 バージョン0/9に数を使用するとき、特に、注意しなければなりません。 (STRINGが実際に数として記述されているべきであるように表された数; 結局、これをするのは可能でしょう)。
7.2 FOR-body
7.2 ボディーのために
Two operations are legitimate in a FOR-body: FOR and assignment.
2つの操作がFOR-ボディーで正統です: FORと課題。
These are subject to the restrictions discussed in Section 6.1 and
in the introduction to Section 7. The restrictions are related to
three requirements: (1) that the names be recognizable (see
Section 9 for details), (2) that a request be consistent regarding
direction of data transfer between containers, both within itself
and with the MODE of outermost containers, and (3) that transfers
occur between objects, not sets of objects. The first two
requirements are permanent, but will become weaker in later
versions of the language. The last requirement is temporary and
will be present only in early versions.
これらはセクション6.1とセクション7への紹介で議論した制限を受けることがあります。 制限は3つの要件に関連します: (1) (3) 名前は認識可能です、そして、(詳細に関してセクション9を見ます)(2) 要求は容器、それ自体、および一番はずれの容器のMODEがあるデータ転送の一貫した関係指示です、そして、転送は物のセットではなく、物の間に起こります。 最初の2つの要件が、永久的ですが、言語の後のバージョンでは、より弱くなるでしょう。 最後の要件は、一時的であり、早めのバージョンだけに存在するでしょう。
Due to an implementation problem associated with Version 0/9,
there is a somewhat bizarre restriction applied to references made
in the body of a loop nested in another loop. This restriction is
not expected to pose any practical problems for users, and is not
part of the language design, but is discussed here for
completeness.
バージョン0/9に関連している実現問題のために、別の輪で入れ子にされた輪のボディーで行われた参照に適用されたいくらか奇妙な制限があります。 この制限について、ユーザのためにどんな実用的な問題も引き起こさないと予想されて、言語デザインの一部ではありませんが、完全性のためにここで議論します。
The restriction is most easily understood by example:
制限は最も容易に例に解釈されます:
given the description
F LIST
R STRUCT
A STR (3)
BL LIST (3)
B STR (3)
C STR (3)
END
and the request fragment:
FOR ...,R
FOR ...,B
... = A ;
... = C ;
END
END
(3) 記述F LIST R STRUCT A STR(3)BL LIST(3)B STRを考えて、C STR(3)ENDと要求は断片化します: …のために…のためのRB… = A。 ... = C。 終わりのエンド
Winter [Page 14] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[14ページ]のRFC515仕様、バージョン0/9 1973年6月6日
observe:
(a) The outer loop processes the set of R's in F.
(b) For each R in F, the inner loop processes the set of B's in
the BL contained in that R.
(c) In the body of the inner loop, there are references to A and
C, which do not occur in B, but do occur in R. That is, the
objects referenced in the inner loop body are defined by the
outer loop, not the inner loop. In general, this is fine;
in the case of C, however, we have a problem.
(d) C occurs beyond the end of BL.
観測します: (a) 外側の輪はFで各RのためのF.(b)でRのセットを処理しますが、内側の輪は内側の輪のボディーにそのR.(c)に含まれたBLでビーズのセットを処理しますが、Bに起こらないAとCの参照がありますが、R.に起こってください。Thatがあって、内側のループ本体で参照をつけられる物は内側の輪ではなく、外側の輪によって定義されます。 一般に、これはすばらしいです。 しかしながら、Cの場合では、私たちは問題を持っています。 (d) CはBLの端のときに起こります。
The 0/9 compiler is capable of neither (1) looking ahead enough to
locate C before it compiles code for the loop, nor (2) while
generating code to loop on the B's in BL, generating a separate
body of code that skips to the end of BL to locate C. Thus it can
handle A, which has been located before it begins loop generation,
but it cannot handle C, which requires a little foresight.
0/9コンパイラは輪のためにコードをコンパイルする前にCの場所を見つけることができるくらいにはどちらの(1)も前を見ることができません、または、コードの別々のボディーを発生させて、それが場所を見つけることができるC.Thusの場所を見つけるBLの端までのスキップがAを扱うのが(2) BLのビーズで輪にするためにコードを発生させている間、Cを扱うことができません(少しの先見を必要とします)。(輪の世代、しかし、それを始める前にAは見つけられました)。
The request fragment shown would not cause problems if the
description were changed to:
以下のことのために記述を変えるなら、見せられた要求断片は問題を起こさないでしょうに。
F LIST
R STRUCT
A STR (3)
C STR (3)
BL LIST (3)
B STR (3)
END
STR(3)C STR(3)BLリスト(3)B STR(3)が終わらせるFリストR STRUCT
Then both A and C would have been found before code for the inner
loop was generated.
そして、内側の輪のためのコードが発生する前にAとCの両方が見つけられたでしょう。
8. Data Transmission
8. データ伝送
Data is transferred from container to container by execution of assignment and FOR operations. The outermost containers involved in transfers can be files or ports. If both are files, then the transfer is internal to the Datacomputer. If either is a port, then an address in the external world is needed to accomplish the data transmission.
課題とFOR操作の実行で容器から容器までデータを移します。 転送にかかわる一番はずれの容器は、ファイルかポートであるかもしれません。 両方がファイルであるなら、転送はDatacomputerに内部です。 どちらかがポートであるなら、外界のアドレスが、データ伝送を達成するのに必要です。
Winter [Page 15] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[15ページ]のRFC515仕様、バージョン0/9 1973年6月6日
Such an address is supplied through a CONNECT-request, which
associates a container (having a function of PORT) with an external
address:
CONNECT <ident> TO <address> ;
Here <address> is either a specifications of host and socket number,
or a TENEX file designator (for CCA's TENEX) enclosed in single
quotes. The host and socket form is:
<socket> AT <host>
where <socket> is a decimal number, and <host> is either a decimal
number or a standard host name (since standard host names don't exist
right now, it has to be the TENEX 'standard' name for the host.
Contact the author for the latest list.) If <host> is omitted, it is
taken to be the host from which the Datalanguage is being
transmitted.
CONNECT-要求でそのようなアドレスを供給します:(要求は容器(PORTの機能を持っている)を外部アドレスに関連づけます)。 <ident>を<アドレス>に接続してください。 ここで、<アドレス>はホストとソケット番号の仕様かシングル・クォーテション・マークに同封されたTENEXファイル指示子(CCAのTENEXのための)のどちらかです。 ホストとソケット用紙は以下の通りです。 <ホスト>が<ソケット>が10進数であり、10進数か標準のホスト名のどちらかである<ソケット>AT<ホスト>。(標準のホスト名がたった今存在しないので、それはホストのためのTENEXの'標準'の名でなければなりません。 最新のリストのために作者に連絡してください。) <ホスト>を省略するなら、Datalanguageが伝えられているホストになるようにそれを取ります。
The address associated with a port can be changed by issuing another CONNECT-request.
別のCONNECT-要求を出すことによって、ポートに関連しているアドレスを変えることができます。
A DISCONNECT-request simply breaks an existing port/address
association without establishing a new one. (A CLOSE-request that
references an open port executes a DISCONNECT.) The syntax of
DISCONNECT is:
DISCONNECT <ident> ;
新しいものを確立しないで、DISCONNECT-要求は単に既存のポート/アドレス協会を壊します。 (戸外が移植する参照がDISCONNECTを実行するというCLOSE-要求。) DISCONNECTの構文は以下の通りです。 <ident>を外してください。
A port is disconnected when: (a) no successful CONNECT-request has ever been issued for it, or (b) a DISCONNECT for the port has been executed since the last successful CONNECT.
ポートが外される、いつ: (a) (b) どんなうまくいっているCONNECT-要求も今までに、それのために出されたことがありませんか、または最後のうまくいっているCONNECT以来ポートへのDISCONNECTは実行されています。
When a disconnected port is referenced in an assignment, it is
connected by default either to:
(a) the connection used for the transmission of Datalanguage to the
Datacomputer, or
(b) the connection used for the transmission of Datacomputer
diagnostics to the user
The choice between (a) and (b), of course, depends on whether the
reference is for input or output. These connections are established
by the network user's ICP to the Datacomputer at the beginning of the
session.
外されたポートが課題で参照をつけられるとき、それは以下のことのためにデフォルトで接続されます。 (a) ユーザへのDatacomputer病気の特徴の送信にもちろん(a)と(b)の選択を使用するか、参照が入力のためのものであるかによるか、または出力されて、接続はDatalanguageのトランスミッションに(b) Datacomputer、または接続に使用しました。 これらの接続はセッションの始めにネットワーク利用者のICPによってDatacomputerに確立されます。
Note that CONNECT and DISCONNECT do not open files or network connections. They simply make address associations within the Datacomputer. The files and connections are opened before each request and closed after each request.
CONNECTとDISCONNECTがファイルかネットワーク接続を開かないことに注意してください。 彼らはDatacomputerの中で単にアドレスを協会にします。 それぞれが各要求して、次々と閉じる前にファイルと接続は開かれます。
Winter [Page 16] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[16ページ]のRFC515仕様、バージョン0/9 1973年6月6日
9. Names in Datalanguage
9. Datalanguageの名前
A name is recognized when it has been associated with a particular data container or set of containers.
それが特定のデータ容器か1セットの容器に関連しているとき、名前は認識されます。
Datalanguage has mechanisms for the recognition of names in contexts. That is, the meaning of the name is related to where it appears.
Datalanguageには、文脈における、名前の認識のためのメカニズムがあります。 すなわち、名前の意味はそれが現れるところで関連します。
This makes it possible to attach natural meanings to partially qualified names.
これで、部分的に適切な名前に自然な意味を付けるのは可能になります。
For example:
例えば:
WEATHER FILE LIST
STATION STRUCT
CITY STR (15)
STATE STR (15)
DATA LIST (24)
OBSERVATION STRUCT
HOUR STR (2)
TEMPERATURE STR (3)
HUMIDITY STR (2)
PRESSURE STR (4)
END
END
気象ファイルリストステーションSTRUCT都市のSTR(15)州のSTR(15)データの並び(24)観測STRUCT時間STR(2)温度STR(3)湿度STR(2)はSTR(4)終わりのエンドに圧力をかけます。
RESULTS PORT LIST
RESULT STRUCT
CITY STR (15)
HOUR STR (2)
TEMPERATURE STR (3)
END
左舷傾斜結果STRUCT都市のSTR(15)時間STR(2)温度STR(3)が終わらせる結果
FOR STATION WITH STATE EQ 'CALIFORNIA'
FOR RESULT, OBSERVATION WITH HOUR GT '12'
AND HUMIDITY LT '75'
CITY = CITY ;
HOUR = HOUR ;
TEMPERATURE = TEMPERATURE ;
END ;
END ;
結果のための'州のEQ'カリフォルニアがあるステーション'、'そして、湿度LT75年の'都市が都市と等しいGT12年の時間との観測。 =一時間の時間。 温度は温度と等しいです。 終わってください。 終わってください。
in the assignment 'CITY = CITY', the first CITY is understood to be RESULT.CITY and the second is understood to be STATION.CITY.
課題'市=市'では、最初の市はRESULT.CITYであることが理解されています、そして、2番目はSTATION.CITYであることが理解されています。
Winter [Page 17] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[17ページ]のRFC515仕様、バージョン0/9 1973年6月6日
9.1 Informal Presentation of Recognition Rules
9.1 認識規則の非公式のプレゼンテーション
'Ident' is used in the sense of section 3. For example, in the
description:
F FILE LIST R STRUCT A STR (1) B STR (1) END
F, R, A and B are idents.
'Ident'はセクション3の意味で使用されます。 例えば記述で: F FILE LIST R STRUCT A STR(1)B STR(1)END F、R、A、およびBはidentsです。
A context is a tree whose nodes are idents. In such a tree, the
terminal nodes are idents of STRINGs. The ident of a LIST is
superior to the ident of the LIST-member. The ident of a STRUCT
is superior to the idents of the STRUCT elements. The context
whose top node is F is said to be the context of F.
文脈はノードがidentsである木です。 そのような木では、端末のノードはSTRINGsのidentsです。 LISTのidentはLIST-メンバーのidentより優れています。 STRUCTのidentはSTRUCT要素のidentsより優れています。 トップノードがFである文脈はFの文脈であると言われています。
+-----+
! F !
+-----+
!
!
+-----+
! R !
+-----+
!
!
+----------+----------+
! !
! !
+-----+ +-----+
! A ! ! B !
+-----+ +-----+
+-----+ F!+-----+ ! ! +-----+ R!+-----+ ! ! +----------+----------+ ! ! ! ! +-----+ +-----+! A!B+!-----+ +-----+
Figure 9.1-1 The context of F
図9.1-1 Fの文脈
A pathname is a sequence of idents, naming nodes along a path from
one node to another. A full pathname in the context starts at the
topmost node. Thus F.R.B is a full pathname in the context of F.
A partial pathname starts at a node other than the topmost node
(e.g. R.B, B).
経路に沿って1つのノードから別のノードまでノードを命名して、パス名はidentsの系列です。 文脈の完全なパス名は最上のノードで始まります。 したがって、F.R.Bは最上のノード(例えば、R.B、B)以外のノードのF.のA部分的なパス名始めの文脈の完全なパス名です。
In Datalanguage, pathnames omitting intermediate nodes, such as
F.B (which omits 'R'), are not permitted. Thus partial pathnames
are partial only in that additional names are implied on the left.
Datalanguageでは、F.B('R'を省略する)などのように、中間的ノードを省略するパス名が受入れられません。 したがって、単に追加名前が暗示しているので、部分的なパス名は左で部分です。
Winter [Page 18] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[18ページ]のRFC515仕様、バージョン0/9 1973年6月6日
Three attempts at recognition of a pathname, PN, in a context, CX,
are made:
パス名の認識、文脈のPNへの3つの試み(CX)をします:
(a) recognition of PN as a full pathname in CX
(b) recognition of PN as a partial pathname in which only the
topmost node of CX is omitted
(c) recognition of PN as an arbitrary partial pathname occurring
only once in CX.
(a) CXの最上の唯一のノードがCXに一度だけ起こる任意の部分的なパス名としてのPNの省略された(c)認識である部分的なパス名としてのPNのCX(b)認識における完全なパス名としてのPNの認識。
The attempts are made in the above order, and the recognition
process halts with the first successful attempt.
上記のオーダーで試みをします、そして、認識の過程は最初のうまくいっている試みで停止します。
As an example, consider the description:
例と、記述を考えてください:
F FILE LIST
R STRUCT
A STR
B STR
S STRUCT
R STR
FファイルリストR STRUCTはSTR B STR S STRUCT R STRです。
which defines the context in Figure 9.1-2.
図9.1-2の文脈を定義します。
+-----+
! F !
+-----+
!
!
+-----+
! R !
+-----+
!
!
+----------------+----------------+
! ! !
! ! !
+-----+ +-----+ +-----+
! A ! ! B ! ! S !
+-----+ +-----+ +-----+
!
!
+-----+
! R !
+-----+
+-----+ F!+-----+ ! ! +-----+ R!+-----+ ! ! +----------------+----------------+ ! ! ! ! ! ! +-----+ +-----+ +-----+! A!B!S+!-----+ +-----+ +-----+ ! ! +-----+ R!+-----+
Figure 9.1-2 Example Context
図9.1-2 例の文脈
Winter [Page 19] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[19ページ]のRFC515仕様、バージョン0/9 1973年6月6日
In this context, F.R.A is a full pathname. Thus, F.R.A is
recognized in attempt (a). R is a partial pathname in which only
the topmost node is omitted. Thus R is recognized in attempt (b).
Note carefully that R is recognized as a reference to F.R, not to
F.R.S.R. Finally, B is an arbitrary partial pathname occurring
only once in the context. Thus B is recognized in attempt (c).
このような関係においては、F.R.Aは完全なパス名です。 したがって、F.R.Aは試み(a)で認識されます。 Rは最上のノードだけが省略される部分的なパス名です。 したがって、Rは試み(b)で認識されます。 RがF.R.S.R.Finallyではなく、F.Rの参照として認識されて、Bが文脈に一度だけ起こる任意の部分的なパス名であることに慎重に注意してください。 したがって、Bは試み(c)で認識されます。
Two stacks of contexts are maintained: one for names used in an
input sense, and one for names used in an output sense. When a
name is to be recognized, it is first decided whether the
reference is an input reference or an output reference. An input
reference is (a) the right hand operand of an assign, or (b) a
name in the input set spec of a FOR. An output reference is (a)
the left operand of an assign, or (b) the output operand of a FOR.
The first context on the appropriate context stack is then
searched, according to the procedure outlined on the previous
page. If the name is neither recognized nor ambiguous in that
context, search continues in the next context on the stack. If
the name can be recognized in none of the contexts on the
appropriate stack, it is unrecognizable.
文脈の2つのスタックが維持されます: 入力意味で使用される名前のためのもの、および出力意味で使用される名前のためのもの。 名前が認識されることであるときに、参照が入力参照かそれとも出力参照であるかが最初に、決められます。 入力参照はそうです。(a) 案配の右手のオペランド、または(b) FORの入力セット仕様の名前。 出力参照はそうです。(a) 案配の左のオペランド、または(b) FORの出力オペランド。 そして、前のページに概説された手順によると、適切な文脈スタックの最初の文脈は捜されます。 名前がその文脈で認識されていなくてまたあいまいでないなら、検索はスタックの次の文脈で続きます。 適切なスタックの文脈のどれかで名前を認識できないなら、認知できません。
When a stack is empty, the recognition procedure is different.
The search is carried on in a special context: The context of
%OPEN. Its top node, %OPEN, is a built in system ident.
Subordinate to %OPEN is a context for each open directory node.
Each such context represents all the idents defined in the
directory nodes having data descriptions:
F FILE LIST R STRUCT A STR (1) B STR (1)
and:
P PORT LIST R STRUCT A STR (1) B STR (1)
then the context of %OPEN would be as in Figure 9.1-3.
スタックが空であるときに、認識手順は異なっています。 検索は特別な関係で運ばれます: %オープンの文脈。 トップノード(%オープン)はシステムidentに建てられたaです。 %オープンへの部下はそれぞれの開いているディレクトリノードのための文脈です。 そのような各文脈はデータ記述を持っているディレクトリノードで定義されたすべてのidentsを表します: そして、F FILE LIST R STRUCT A STR(1)B STR(1)、: いてください。次に、%オープンの文脈がそうするP PORT LIST R STRUCT A STR(1)B STR(1)、図9.1-3のように。
Winter [Page 20] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[20ページ]のRFC515仕様、バージョン0/9 1973年6月6日
+-------+
! %OPEN !
+-------+
!
!
+-----------+-----------+
! !
! !
+-----+ +-----+
! A ! ! S !
+-----+ +-----+
! !
! !
+-----+ +-----+
! R ! ! R !
+-----+ +-----+
! !
! !
+-----+-----+ +-----+-----+
! ! ! !
! ! ! !
+-----+ +-----+ +-----+ +-----+
! A ! ! B ! ! A ! ! B !
+-----+ +-----+ +-----+ +-----+
+-------+ %戸外!+-------+ ! ! +-----------+-----------+ ! ! ! ! +-----+ +-----+! A!S+!-----+ +-----+ ! ! ! ! +-----+ +-----+ R R!+-----+ +-----+ ! ! ! ! +-----+-----+ +-----+-----+ ! ! ! ! ! ! ! ! +-----+ +-----+ +-----+ +-----+! A!B A!B+!-----+ +-----+ +-----+ +-----+
Figure 9.1-3 The Context of %OPEN
図9.1-3 %の開いている文脈
When a directory node is closed, the corresponding context is
removed from the context of %OPEN. When a node is opened, the
associated context is added as the rightmost context subordinate
to %OPEN.
ディレクトリノードが閉じられるとき、対応する文脈は%オープンの文脈から取り除かれます。 ノードが開かれるとき、関連文脈は一番右の文脈部下として%オープンに加えられます。
9.2 Context Stack Maintenance
9.2 文脈スタック維持
The context stacks are always empty between requests. The FOR-
operator adds entries to the stacks. FOR A adds the context of A
to the input context stack. FOR A, B ... adds the context of A to
the output stack and the context of B to the input stack.
文脈スタックは要求の間でいつも空です。 FORオペレータはスタックにエントリーを加えます。 FOR Aは入力文脈スタックにAの文脈を加えます。 FOR A、Bは出力スタックへのAの文脈と入力スタックへのBの文脈を加えます…。
When adding to an empty stack, FOR adds two contexts instead of
one. The second addition to the stack is the context of the
looparg; the first addition is the context of the outermost
container which encloses the looparg.
空のスタックに加えるとき、FORは1の代わりに2つの文脈を加えます。 スタックへの2番目の添加はloopargの文脈です。 最初の添加はloopargを同封する一番はずれの容器の文脈です。
Winter [Page 21] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[21ページ]のRFC515仕様、バージョン0/9 1973年6月6日
For example, given a context of %OPEN as in Figure 9.1-3, and
empty context stacks, the fragment 'FOR F.R ...' adds two
contexts: (1) the context of F, and (2) the context of F.R.
例えば、断片図9.1-3、および空の文脈スタックのように%オープンの文脈を与える場合'FOR F.R'…'2つの文脈を加えます:、' (1) (2) Fの文脈、およびF.Rの文脈。
Contexts are removed from the stacks by the END matching the FOR
which added them.
文脈はそれらを加えたFORに合っているENDによってスタックから取り除かれます。
10. Miscellaneous Topics
10. 種々雑多な話題
10.1 The LIST-request
10.1 リスト要求
The LIST-request provides a means for the user to inspect system
data of interest to him. The user can determine the contents of
the directory, the source or parsed form of any data description
in the system, and the mode and connection status of any open file
or port.
LIST-要求はユーザが彼にとって、興味深いシステムデータを点検する手段を提供します。 ユーザはどんなオープン・ファイルやポートのディレクトリのコンテンツ、システムのどんなデータ記述のソースか分析されたフォーム、モード、および接続形態も決定できます。
The LIST operator has a single operand, which can have any of
several forms. The action of the operator is to output a list of
values on the Datalanguage output port.
LISTオペレータには、ただ一つのオペランドがあります。(オペランドは、いくつかのフォームのどれかを持つことができます)。オペレータの動作はDatalanguage出力ポートの上で値のリストを出力することです。
To output a list of pathnames, the operand used is '%ALL'. When
'%ALL' appears alone, all pathnames in the directory are listed.
When '%ALL' appears after the last ident in a directory pathname,
the full pathnames of all nodes subordinate to the named node are
listed.
'使用されているのが、パス名、オペランドのリストを出力するためには'%である、すべて' ''%である、すべて、'リストアップされたディレクトリのパス名に見えます。 ''%である、すべて、'ディレクトリパス名、すべてのノードの完全なパス名における最後のidentの後にリストアップされた名前付のノードに下位に見えます。
To output one or more source descriptions, the operand '.%SOURCE'
is used. '.%SOURCE' is preceded with one of (a) '%ALL', (b)
'%OPEN', or (c) the ident of an open outermost container. The
output is either (a) all descriptions, (b) all open descriptions,
or (c) a particular open description.
'出力1か、より多くのソース記述に、オペランド'. %SOURCE'は使用されています。 ''. %SOURCE'は(c) (a)'%すべて、'(b) '%オープン'の1つか開いている一番はずれの容器のidentで先行されています。 出力はそうです。(b) (a) すべての記述、すべての開いている記述か(c) 特定の開いている記述のどちらか。
To output a parsed description, the operand '.%DESC' is used
('%DESCRIPTION' is also accepted). This operand is preceded
either with (a) '%OPEN', or (b) the ident of an open outermost
container.
'分析された記述を出力するために、オペランド'. %DESC'は使用されています(また、'%記述'を受け入れます)。 'このオペランドは(a) '%オープン'、または(b) 開いている一番はずれの容器のidentで先行されています。
Winter [Page 22] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[22ページ]のRFC515仕様、バージョン0/9 1973年6月6日
Examples:
例:
Let P be the ident of an open PORT. Let A.B.C be a
directory pathname.
LIST %ALL
LIST A.B.C.%ALL
LIST %OPEN
LIST %ALL.%SOURCE
LIST %OPEN.%SOURCE
LIST P.%SOURCE
LIST %OPEN.%DESC
LIST P.%DESC
Pが開いているPORTのidentであることをさせてください。 A.B.Cがディレクトリパス名であることをさせてください。 すべてのリスト%オープン・リスト%. %ソース・リスト%戸外%ソース・リストP.%ソース・リスト%戸外%DESCリストP.%DESCのときに%をすべてのリストA.紀元前の%記載してください。
Note that 'LIST A.B.C.%SOURCE' is not legal - '.%SOURCE'
must be preceded with the ident of an open container, not a
pathname. A similar restriction applies to '.%DESC'.
''LIST A. B.C.%SOURCE'が法的でないことに注意してください--パス名ではなく、ふたなし容器のidentで'. %SOURCE'に先行しなければなりません。 '同様の制限は'. %DESC'に適用されます。
10.2 Constants in Datalanguage
10.2 Datalanguageの定数
A constant of type STRING can be included in a Datalanguage
request by enclosing it in single quotes:
'ABC'
A single quote is included in a constant by preceding it with a
double quote:
'FATHER"'S'
Likewise, a double quote is included by preceding it with a double
quote:
'JOHN SAID ""HELLO""'
Datalanguage要求にシングル・クォーテション・マークにそれを同封することによって、タイプSTRINGの定数を含むことができます: 'ABC'Aというただ一つの引用文は定数に二重引用文でそれに先行することによって、含まれています: '神父、「aps'Likewise、二重引用文は二重引用文でそれに先行することによって、含まれています」。 '「「こんにちは」」と、ジョンは言いました'
Such constants can be used on the right of comparison operators
and of assignment operators which reference strings.
参照が結ぶ比較オペレータと課題オペレータの右でそのような定数を使用できます。
Eventually, Datalanguage will contain facilities for the inclusion
of constants of all datatypes; such constants are simply a special
case of the Datalanguage expression and will be permitted wherever
such expressions are permitted.
結局、Datalanguageはすべてのデータ型式の定数の包含のための施設を含むでしょう。 そのような定数は、単にDatalanguage表現の特別なケースであり、どこでも、そのような表現が受入れられるところで受入れられるでしょう。
10.3 Character Set
10.3 文字コード
Internally, Version 0/9 of the Datacomputer software operates in
7-bit ASCII characters. Its output to the ARPANET is converted to
8-bit ASCII. On input from the ARPANET, it expects 8-bit
characters, which it converts to 7-bit characters.
本質的に、Datacomputerソフトウェアのバージョン0/9は7ビットのASCII文字で作動します。 アルパネットへの出力は8ビットのASCIIに変換されます。 アルパネットからの入力のときに、それは8ビットのキャラクタを予想します。(それは7ビットのキャラクタにキャラクタを変換します)。
Winter [Page 23] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[23ページ]のRFC515仕様、バージョン0/9 1973年6月6日
To convert from 7- to 8-bit characters, a '0' bit is prefixed. To
convert from 8- to 7-bit characters, the high-order bit is
checked. If the high-order bit is a '0', the bit is discarded and
the character is accepted as a 7-bit character. If the high-order
bit is a '1', then the character is discarded.
7〜8ビットのキャラクタまで変換するために、'0'ビットは前に置かれています。 8〜7ビットのキャラクタまで変換するために、高位のビットはチェックされます。 高位のビットが'0'であるなら、ビットは捨てられます、そして、キャラクタは7ビットのキャラクタとして認められます。 高位のビットが'1'であるなら、キャラクタは捨てられます。
(In the following discussion, as elsewhere in this memo, all
references to numerical character codes are in decimal).
(小数には数字コードのすべての参照が以下の議論、このメモのほかの場所にあるので。)
The remainder of this section discusses treatment of codes 0
through 127, when they appear in Datalanguage requests.
Datalanguage要求に現れると、このセクションの残りは0〜127にコードの処理について議論します。
In general, printing characters are acceptable in requests, while
control characters are not. There are some exceptions, which are
detailed below. The printing characters are codes 32-126. The
control characters are codes 0-31 and 127.
一般に、表示文字は要求で許容できますが、制御文字はそうではありません。 いくつかの例外が以下にあります。(例外は詳細です)。 表示文字はコード32-126です。 制御文字は、コード0-31と127です。
Certain control characters are accepted:
ある制御文字を受け入れます:
Tab(9) is accepted freely in requests. It functions as a
separator (explained below).
要求で自由にタブ(9)を受け入れます。 それは分離符(以下で、説明される)として機能します。
EOL(31), meaning end-of-line, is accepted in requests,
functioning both as a separator and an activator (a). EOL has
a special meaning in data, and should not be introduced into
STRING constants(***).
分離符と活性剤(a)として機能して、要求でEOL(31)(意味行末)を受け入れます。 EOLをデータで格別の意味があって、STRING定数(***)に取り入れるべきではありません。
Control-L(12) is an activator and a high-level request
delimiter. It terminates the test of any request being
processed when it is encounter in the input stream. It is
useful in Datacomputer-user program synchronization.
コントロール-L(12)は活性剤とハイレベルの要求デリミタです。 それはそれが入力ストリームで遭遇であるときに処理されるどんな要求のテストも終えます。 それはDatacomputer-ユーザ・プログラム同期で役に立ちます。
Control-Z(26) means end-of-session when encountered in
Datalanguage. It has the properties of control-L, and in
addition, causes the Datacomputer to execute an end-of-session
procedure, which results in closing the Datalanguage
connections, closing any open files or ports, etc. The effect
is equivalent to a [LOGOUT(which] does not exist yet).
Datalanguageで遭遇すると、コントロール-Z(26)はセッションの終わりを意味します。 それはセッションの終わりの手順やDatalanguage接続であり最後になりましたが、どんな戸外も閉じるのがファイルされるというどの結果やポートなどを実行するかコントロールLの特性、および添加、原因におけるDatacomputerを持っています。 効果がaに同等である、[LOGOUT、(どれ]、まだ存在していないか、)
The two-character sequence <carriage return(13), line feed(10)>
is equivalent to EOL (and is translated to EOL on input from
the network). The reverse sequence, as well as either
character alone, is treated simply as other control characters
(ignored).
2キャラクタシーケンスの<復帰(13)、改行(10)>はEOL(そして、入力のときにネットワークからEOLに翻訳される)に同等です。 逆の系列、および単独などちらのキャラクタも単に他の制御文字(無視される)として扱われます。
All other control characters are ignored.
他のすべての制御文字が無視されます。
Winter [Page 24] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[24ページ]のRFC515仕様、バージョン0/9 1973年6月6日
The printing characters are further divided into four groups:
special characters, uppercase letters, lower case letters, and
digits (the membership of these groups is defined in section 11).
表示文字はさらに4つのグループに分割されます: 特殊文字(大文字)はケース手紙、およびケタを下げます(これらのグループの会員資格はセクション11で定義されます)。
Corresponding upper and lower case letters are equivalent in
requests, except with quoted strings.
引用文字列を除いて、対応する大文字と小文字手紙は要求で同等です。
Certain special characters have a lexical function, which is
either break or separator. A break character terminates the
current lexical item and returned itself as the next item. A
separator character terminates the current item but does not begin
a new item (i.e., its only function is to separate items).
Multiple separators are equivalent to a single separator. A
separator can always be inserted before or after a break
character, without altering the meaning of the request.
ある特殊文字には、語彙機能があります。(それは、中断か分離符のどちらかです)。 区切り文字は次の項目としての現在の語彙項目であって返自体にされるのを終えます。 分離符キャラクタは、現在の項目を終えますが、新商品を始めません(すなわち、唯一の機能は商品を切り離すことです)。 複数の分離符がただ一つの分離符に同等です。 要求の意味を変更しないで、区切り文字の前または後いつも分離符を挿入できます。
The separators are tab(9), space(32), and end-of-line(31).
分離符は、タブ(9)と、スペース(32)と、行末(31)です。
The break characters are left parenthesis(40), right
parenthesis(41), equals(61), semicolon(59), period(46), comma(44),
quote(39), and slash(47).
区切り文字は挿入句(40)、右括弧(41)、同輩(61)、セミコロン(59)、期間(46)、コンマ(44)、引用文(39)、およびスラッシュ(47)に残されます。
(a) An activator character causes the Datacomputer to process
whatever has been received since the previous activator or
the beginning of the request. The meaning of a request is
independent of the presence/absence of activators. However,
a request will not be executed until an activator beyond the
end of the request is received.
(a) 活性剤キャラクタはDatacomputerに前の活性剤か要求の始まり以来受け取られているものなら何でも処理させます。 要求の意味は活性剤の存在/不在から独立しています。 しかしながら、要求の終わりの活性剤が受け取られているまで、要求は実行されないでしょう。
While Version 0/9 defines (carriage return, linefeed) in terms of
EOL, network users should not think in terms of sending EOL's to
the Datacomputer over the network. EOL is not part of the network
ASCII character set, and has no definite permanent place in
Datacomputer implementation plans.
バージョン0/9がEOLに関して(復帰、ラインフィード)を定義する間、ネットワーク利用者はネットワークの上で送付EOLのものに関してDatacomputerと考えるべきではありません。 EOLはネットワークASCII文字の組の一部でなく、またDatacomputer実行計画でどんな明確な永久的な場所も持っていません。
10.4 Comments
10.4 コメント
Comments can be included in Datalanguage requests. A comment is
begun with the two-character sequence '/*', and ended with the
two-character sequence '*/'. Since slash is a break character, a
comment does cause a lexical break; its overall effect is that of
a separator.
Datalanguage要求にコメントを含むことができます。 'コメントは、2キャラクタシーケンス'/*'で始められて、2キャラクタシーケンス'*/'で終わります。 スラッシュが区切り文字であるので、コメントは語彙中断を引き起こします。 総合的な効果は分離符のものです。
Winter [Page 25] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[25ページ]のRFC515仕様、バージョン0/9 1973年6月6日
10.5 Reserved Identifiers
10.5 予約された識別子
Certain identifiers are reserved in Datalanguage, and should not
be used to name containers or directory nodes. These are:
ある識別子をDatalanguageで予約して、容器かディレクトリノードを命名するのに使用するべきではありません。 これらは以下の通りです。
AND
APPEND
AT
CLOSE
CONNECT
CREATE
DELETE
DISCONNECT
END
EQ
FILE
FOR
GE
GT
LE
LIST
LT
NODE
NE
NOT
OPEN
OR
PORT
READ
STR
STRUCT
TO
WITH
WRITE
閉鎖における追加、接続、作成、ゲーへのGT LEがORポートがSTR STRUCTを読み込んだLTノードNe NOT戸外を記載するEQファイルが書く分離終わりを削除してください。
More reserved identifiers will be added in Version 0/10.
より多くの予約済み識別子がバージョン0/10で加えられるでしょう。
Winter [Page 26] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[26ページ]のRFC515仕様、バージョン0/9 1973年6月6日
11. Datalanguage Syntax Expressed in BNF
11. BNFに表されたDatalanguage構文
11.1 Requests
11.1 要求
11.1.01 <request> ::= ;
11.1.02 <request> ::= <create>
11.1.03 <request> ::= OPEN <pn> ;
11.1.04 <request> ::= OPEN <pn> <mode> ;
11.1.05 <request> ::= CLOSE <ident> ;
11.1.06 <request> ::= CONNECT <ident> TO <address> ;
11.1.07 <request> ::= DISCONNECT <ident> ;
11.1.08 <request> ::= MODE <ident> <mode> ;
11.1.09 <request> ::= DELETE <pn> ;
11.1.10 <request> ::= LIST <listarg> ;
11.1.11 <request> ::= <sr-request> ;
11.1.01 <要求>:、:= ; 11.1.02 <要求>:、:= <は>11.1.03<要求>を作成します:、:= <pn>を開いてください。 11.1.04 <要求>:、:= <pn><モード>を開いてください。 11.1.05 <要求>:、:= <ident>を閉じてください。 11.1.06 <要求>:、:= <ident>を<アドレス>に接続してください。 11.1.07 <要求>:、:= <ident>を外してください。 11.1.08 <要求>:、:= モード<ident><モード>。 11.1.09 <要求>:、:= <pn>を削除してください。 11.1.10 <要求>:、:= <listarg>を記載してください。 11.1.11 <要求>:、:= <sr-要求>。
11.2 Data Description and Creation
11.2 データ記述と創造
11.2.01 <create> ::= CREATE <pn>
11.2.02 <create> ::= CREATE <pn> <ftn> LIST <desc>
11.2.03 <create> ::= CREATE <pn> <ftn> LIST <size> <desc>
11.2.01 <は>を作成します:、:= <pn>11.2を作成してください。.02<は>を作成します:、:= <pn><ftn>リスト<desc>11.2を作成してください。.03<は>を作成します:、:= <pn><ftn>リスト<サイズ><desc>を作成してください。
11.2.04 <desc> ::= <ident> <attributes>
11.2.04 <desc>:、:= <ident><属性>。
11.2.05 <attributes> ::= LIST <size> <desc>
11.2.06 <attributes> ::= STRUCT <descs> END
11.2.07 <attributes> ::= STR <size>
11.2.08 <attributes> ::= STR <size> ,I=D
11.2.05 <属性>:、:= <サイズ><desc>11.2.06<属性>を記載してください:、:= STRUCT<descs>エンド11.2.07<属性>:、:= STR<サイズ>11.2.08<属性>:、:= STR<サイズ>、I=D
11.2.09 <descs> ::= <desc>
11.2.10 <descs> ::= <descs> <desc>
11.2.09 <descs>:、:= <desc>11.2.10<descs>:、:= <descs><desc>。
11.2.11 <ftn> ::= PORT
11.2.12 <ftn> ::= FILE
11.2.13 <ftn> ::= TEMP PORT
11.2.14 <ftn> ::= TEMPORARY PORT
11.2.11 <ftn>:、:= ポート11.2.12<ftn>:、:= ファイル11.2.13<ftn>:、:= 臨時ポート11.2.14<ftn>:、:= 一時的なポート
11.2.15 <size> ::= ( <integer constant> )
11.2.15 <サイズ>:、:= (<整定数>)
Winter [Page 27] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[27ページ]のRFC515仕様、バージョン0/9 1973年6月6日
11.3 Data Storage and Retrieval
11.3 データ保存と検索
11.3.01 <sr-request> ::= <assign>
11.3.01 <sr-request> ::= <loop>
11.3.01 <sr-要求>:、:= <案配>11.3.01<sr-要求>:、:= <輪の>。
11.3.03 <assign> ::= <pn> = <object>
11.3.03 <案配>:、:= <pn>は<物の>と等しいです。
11.3.04 <loop> ::= FOR <looparg> <loopbody> END
11.3.04 <輪の>:、:= <looparg><loopbody>エンドのときに
11.3.05 <looparg> ::= <exp>
11.3.06 <looparg> ::= <pn> , <exp>
11.3.05 <looparg>:、:= <exp>11.3.06<looparg>:、:= <pn>、<exp>。
11.3.07 <loopbody> ::= <sr-request>
11.3.08 <loopbody> ::= <loopbody1> <sr-request>
11.3.09 <loopbody> ::= <loopbody1>
11.3.07 <loopbody>:、:= <sr要求>11.3.08<loopbody>:、:= <loopbody1><sr要求>11.3.09<loopbody>:、:= <loopbody1>。
11.3.10 <loopbody1> ::= <sr-request> ;
11.3.11 <loopbody1> ::= <loopbody1> <sr-request> ;
11.3.10 <loopbody1>:、:= <sr-要求>。 11.3.11 <loopbody1>:、:= <loopbody1><sr-要求>。
11.4 Expressions
11.4 表現
11.4.01 <exp> ::= <pn>
11.4.02 <exp> ::= <pn> WITH <boolexp>
11.4.01 <exp>:、:= <pn>11.4.02<exp>:、:= <boolexp>と<pn>。
11.4.03 <boolexp> ::= <pn> <comop> <string constant>
11.4.04 <boolexp> ::= ( <boolexp> )
11.4.05 <boolexp> ::= NOT <boolexp>
11.4.06 <boolexp> ::= <boolexp> AND <boolexp>
11.4.07 <boolexp> ::= <boolexp> OR <boolexp>
11.4.03 <boolexp>:、:= <pn><comop><ストリング一定の>11.4.04<boolexp>:、:= (<boolexp>) 11.4.05 <boolexp>:、:= <boolexp>11.4.06<boolexp>でない:、:= <boolexp>と<は>11.4.07<boolexp>をboolexpします:、:= <boolexp>か<boolexp>。
11.4.08 <comop> ::= EQ
11.4.09 <comop> ::= NE
11.4.10 <comop> ::= GT
11.4.11 <comop> ::= LT
11.4.12 <comop> ::= GE
11.4.13 <comop> ::= LE
11.4.08 <comop>:、:= EQ11.4.09<comop>:、:= Ne11.4.10<comop>:、:= GT11.4.11<comop>:、:= LT11.4.12<comop>:、:= GE11.4.13<comop>:、:= LE
Winter [Page 28] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[28ページ]のRFC515仕様、バージョン0/9 1973年6月6日
11.5 Miscellaneous
11.5 その他
11.5.01 <address> ::= <quote> <TENEX file designator>
<quote>
11.5.02 <address> ::= <socket> AT <host>
11.5.03 <address> ::= <socket>
11.5.01 <アドレス>:、:= <引用文の><TENEXは指示子><引用文>11.5の.02<アドレス>をファイルします:、:= <ホスト>11.5.03<アドレス>の<ソケット>:、:= <ソケット>。
11.5.04 <socket> ::= <integer constant> //INTERPRETED AS
DECIMAL
11.5.04 <ソケット>:、:= <整定数>//INTERPRETED AS DECIMAL
11.5.05 <host> ::= <integer constant> //INTERPRETED AS
DECIMAL
11.5.06 <host> ::= ***** TENEX host names *****
11.5.05 <ホスト>:、:= <整定数>//INTERPRETED AS DECIMAL11.5.06<ホスト>:、:= ***** TENEXホスト名*****
11.5.07 <object> ::= <pn>
11.5.08 <object> ::= <string constant>
11.5.07 <物の>:、:= <pn>11.5.08<物の>:、:= <ストリングの一定の>。
11.5.09 <mode> ::= READ
11.5.10 <mode> ::= APPEND
11.5.11 <mode> ::= WRITE
11.5.09 <モード>:、:= 11.5に.10<モード>を読んでください:、:= 11.5に.11<モード>を追加してください:、:= 書いてください。
11.5.12 <listarg> ::= %ALL
11.5.13 <listarg> ::= <pn>.%ALL
11.5.14 <listarg> ::= %OPEN
11.5.15 <listarg> ::= %ALL.%SOURCE
11.5.16 [<LISTARG>] ::= <IDENT>.%SOURCE
11.5.17 <listarg> ::= %OPEN.%SOURCE
11.5.18 <listarg> ::= %OPEN.%DESC
11.5.19 <listarg> ::= <ident>.%DESC
11.5.12 <listarg>:、:= %、すべての11.5の.13<listargな>:、:= <pn>%、すべての11.5の.14<listargな>:、:= %は11.5に.15<listarg>を開きます:、:= %. %ソース11.5.16[<LISTARG>]:、:= <IDENT>%ソース11.5.17<listarg>:、:= %戸外%ソース11.5.18<listarg>:、:= %戸外%DESC11.5.19<listarg>:、:= <ident>%DESC
11.5.20 <pn> ::= <ident>
11.5.21 <pn> ::= <pn>.<ident>
11.5.20 <pn>:、:= <ident>11.5.21<pn>:、:= <pn><ident>。
11.5.22 <ident> ::= <letter>
11.5.23 <ident> ::= <ident> <letter>
11.5.24 <ident> ::= <ident> <digit>
11.5.22 <ident>:、:= <文字>11.5.23<ident>:、:= <ident><文字>11.5.24<ident>:、:= <ident><ケタ>。
11.5.25 <integer constant> ::= <digit>
11.5.26 <integer constant> ::= <integer constant> <digit>
11.5.25 <整定数>:、:= <ケタ>11.5.26<整定数>:、:= <整定数><ケタ>。
11.5.27 <string constant> ::= <quote> <string conbody>
<quote>
11.5.27 <ストリングの一定の>:、:= <引用文の><ストリングconbody><引用文の>。
11.5.28 <string conbody> ::= <nonquote>
11.5.28 <string conbody> ::= <string conbody> <nonquote>
11.5.28 <ストリングconbody>:、:= <「非-引用文」の>11.5.28<ストリングconbody>:、:= <ストリングconbody><「非-引用文」の>。
Winter [Page 29] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[29ページ]のRFC515仕様、バージョン0/9 1973年6月6日
11.6 Character Set
11.6 文字コード
11.6.01 <separator> ::= //SPACE(32)
11.6.02 <separator> ::= //TAB(9)
11.6.03 <separator> ::= <eol>
11.6.01 <分離符>:、:= //スペース(32)11.6.02<分離符>:、:= //タブ(9)11.6.03<分離符>:、:= <eol>。
11.6.04 <special> ::= <quote>
11.6.05 <special> ::= <superquote>
11.6.06 <special> ::= <special1>
11.6.04 <の特別な>:、:= <引用文の>11.6.05の<の特別な>:、:= <「スーパー-引用文」の>11.6.06の<の特別な>:、:= <special1>。
11.6.07 <letter> ::= A
11.6.08 <letter> ::= B
...............
11.6.09 <letter> ::= Z
11.6.07 <手紙>:、:= A11.6.08<手紙>:、:= B… 11.6.09 <手紙>:、:= Z
11.6.10 <letter> ::= a
11.6.11 <letter> ::= b
...............
11.6.12 <letter> ::= z
11.6.10 <手紙>:、:= a11.6.11<手紙>:、:= b… 11.6.12 <手紙>:、:= z
11.6.13 <digit> ::= 0
11.6.14 <digit> ::= 1
...............
11.6.15 <digit> ::= 9
11.6.13 <ケタ>:、:= 0 11.6 .14<ケタ>:、:= 1 ............... 11.6.15 <ケタ>:、:= 9
11.6.16 <nonquote> ::= <letter>
11.6.17 <nonquote> ::= <digit>
11.6.18 <nonquote> ::= <superquote> <quote>
11.6.19 <nonquote> ::= <superquote> <superquote>
11.6.20 <nonquote> ::= <special1>
11.6.21 <nonquote> ::= <separator>
11.6.16 <「非-引用文」の>:、:= <文字>11.6.17<「非-引用文」の>:、:= <ケタ>11.6.18<「非-引用文」の>:、:= <「スーパー-引用文」の><引用文の>11.6.19<「非-引用文」の>:、:= <「スーパー-引用文」の><「スーパー-引用文」の>11.6.20<「非-引用文」の>:、:= <special1>11.6.21<「非-引用文」の>:、:= <分離符>。
11.6.22 <eol> ::= //EOL (31)
11.6.23 <eol> ::= <carriage return> <line feed>
11.6.22 <eol>:、:= //EOL(31)11.6.23の<のeol>:、:= <復帰><改行>。
11.6.24 <carriage return> ::= //CARRIAGE RETURN (13)
11.6.25 <line feed> ::= //LINE FEED (10)
11.6.24 <復帰>:、:= //CARRIAGE RETURN(13)11.6.25<改行>:、:= //改行(10)
11.6.26 <quote> ::= ' //SINGLE QUOTE(44)
11.6.26 <引用文の>:、:= '//ただ一つの引用文'(44)
11.6.27 <superquote> ::= " //DOUBLE QUOTE(34)
11.6.27 <「スーパー-引用文」の>:、:= 「//二重な引用文」(34)
11.6.28 <special1> ::= ! //EXCLAMATION POINT(33)
11.6.29 <special1> ::= # //NUMBER SIGN(35)
11.6.30 <special1> ::= $ //DOLLAR SIGN(36)
11.6.31 <special1> ::= % //PERCENT SIGN(37)
11.6.32 <special1> ::= & //AMPERSAND(38)
11.6.33 <special1> ::= ( //LEFT PARENTHESIS(40)
11.6.28 <special1>:、:= ! //感嘆符(33)11.6.29<special1>:、:= # //No.サイン(35)11.6.30<special1>:、:= //ドル記号(36)11.6.31ドルの<special1>:、:= %//パーセントサイン(37)11.6.32<special1>:、:= //アンパーサンド(38)11.6.33<special1>:、:= (//左括弧(40)
Winter [Page 30] RFC 515 Specifications for Datalanguage, Version 0/9 6 June 1973
Datalanguageのための冬[30ページ]のRFC515仕様、バージョン0/9 1973年6月6日
11.6.34 <special1> ::= ) //RIGHT PARENTHESIS(41)
11.6.35 <special1> ::= * //ASTERISK(42)
11.6.36 <special1> ::= + //PLUS SIGN(43)
11.6.37 <special1> ::= , //COMMA(44)
11.6.38 <special1> ::= - //MINUS SIGN(45)
11.6.39 <special1> ::= . //PERIOD(46)
11.6.40 <special1> ::= / //SLASH(47)
11.6.41 <special1> ::= : //COLON(58)
11.6.42 <special1> ::= ; //SEMICOLON(59)
11.6.43 <special1> ::= < //LEFT ANGLE BRACKET(60)
11.6.44 <special1> ::= = //EQUAL SIGN(61)
11.6.45 <special1> ::= > //RIGHT ANGLE BRACKET(62)
11.6.46 <special1> ::= ? //QUESTION MARK(63)
11.6.47 <special1> ::= @ //AT-SIGN(64)
11.6.48 <special1> ::= [ //LEFT SQUARE BRACKET(91)
11.6.49 <special1> ::= //BACK SLASH(92)
11.6.50 <special1> ::= ] //RIGHT SQUARE BRACKET(93)
11.6.51 <special1> ::= ^ //CIRCUMFLEX(94)
11.6.52 <special1> ::= _ //UNDERBAR(95)
11.6.53 <special1> ::= ` //ACCENT GRAVE(96)
11.6.54 <special1> ::= { //LEFT BRACE(123)
11.6.55 <special1> ::= | //VERTICAL BAR(124)
11.6.56 <special1> ::= } //RIGHT BRACE(125)
11.6.57 <special1> ::= ~ //TILDE(126)
11.6.34 <special1>:、:= ) //右括弧(41) 11.6.35 <special1>:、:= * //アスタリスク(42) 11.6.36 <special1>:、:= + //プラスサイン(43) 11.6.37 <special1>:、:= , //コンマ(44) 11.6.38 <special1>:、:= - //マイナス記号(45) 11.6.39 <special1>:、:= . //期間の(46) 11.6.40 <special1>:、:= ///スラッシュ(47) 11.6.41 <special1>:、:= : //コロン(58) 11.6.42 <special1>:、:= ; //セミコロン(59) 11.6.43 <special1>:、:= <//は角ブラケット(60)を残しました。 11.6.44 <special1>:、:= = //等号(61) 11.6.45 <special1>:、:= >//直角ブラケット(62) 11.6.46 <special1>:、:= ? //疑問符(63) 11.6.47 <special1>:、:= サイン(64)の@// 11.6.48 <special1>:、:= [//左の正方形のブラケット(91)11.6.49<special1>: : =//後部スラッシュ(92)11.6.50<special1>: : =] //右角括弧(93) 11.6.51 <special1>:、:= ^//曲折アクセント(94) 11.6.52 <special1>:、:= _ //UNDERBAR(95) 11.6.53 <special1>:、:= '//アクセント墓(96)' 11.6.54 <special1>:、:= {//は支柱(123)11.6.55<をspecial1>: : =に残しました| //縦棒(124)11.6.56<special1>: : =}という//正しい支柱(125) 11.6.57 <special1>:、:= ~ //ティルド(126)
<EOF>
<EOF>。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Walter Benton 12/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ウォルター・ベントン12/98によるオンラインRFCアーカイブへの]
Winter [Page 31]
冬[31ページ]
一覧
スポンサーリンク
