RFC610 日本語訳
0610 Further datalanguage design concepts. R. Winter, J. Hill, W.Greiff. December 1973. (Format: TXT=198692 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Richard Winter, Jeffrey Hill, Warren Greiff RFC # 610 CCA NIC # 21352 December 15, 1973
ネットワークワーキンググループリチャードWinter、ジェフリー・ヒル、ウォレンGreiff RFC#610CCA NIC#21352 1973年12月15日
Further Datalanguage Design Concepts
さらなるDatalanguage設計思想
Richard Winter
Jeffrey Hill
Warren Greiff
リチャードWinterジェフリーヒルウォレンGreiff
Computer Corporation of America
December 15, 1973
1973年12月15日のアメリカのコンピュータ社
Winter, Hill & Greiff [Page 1] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[1ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
Acknowledgment
承認
During the course of the Datacomputer Project, many people have contributed to the development of datalanguage.
Datacomputer Projectのコースの間、多くの人々がdatalanguageの開発に貢献しています。
The suggestions and criticisms of Dr. Gordon Everest (University of Minnesota), Dr. Robert Taylor (University of Massachusetts), Professor Thomas Cheatham (Harvard University) and Professor George Mealy (Harvard University) have been particularly useful.
(ミネソタ大学ゴードンエベレスト)博士、ロバート・テイラー博士(マサチューセッツ大学)、トーマス・チーザム教授(ハーバード大学)、およびジョージMealy教授(ハーバード大学)の提案と批評は特に役に立っています。
Within CCA, several people in addition to the authors have participated in the language design at various stages of the project. Hal Murray, Bill Bush, David Shipman and Dale Stern have been especially helpful.
CCAの中では、作者に加えた数人はプロジェクトの様々な段階で言語デザインに参加しました。 ハル・マレー、ビル・ブッシュ、デヴィッド・シップマン、およびデール・スターンは特に助けになっています。
Winter, Hill & Greiff [Page 2] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[2ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
1. Introduction
1. 序論
1.1 The Datacomputer System
1.1 Datacomputerシステム
The datacomputer is a large-scale data utility system, offering data storage and data management services to other computers.
他のコンピュータに対するサービスをデータ保存とデータ管理に提供して、datacomputerは大規模な情報サービスシステムです。
The datacomputer differs from traditional data management systems in several ways.
datacomputerはいくつかの方法で伝統的なデータ管理システムと異なっています。
First, it is implemented on dedicated hardware, and comprises a separate computing system specialized for data management.
まず最初に、それは、専用ハードウェアの上で実装されて、データ管理のために専門にされた別々のコンピューティング・システムを包括します。
Second, the system is implemented on a large scale. Data is intended to be stored on mass storage devices, with capacities in the range of a trillion bits. Files on the order of one hundred billion bits are to be kept online.
2番目に、システムは大規模に導入されます。 能力が1兆ビットの範囲にある状態で大記憶装置の上にデータが保存されることを意図します。 1000億ビットの注文のファイルはオンラインに保たれることです。
Third, it is intended to support sharing of data among processes operating in diverse environments. That is, the programs which share a given data base may be written in different languages, execute on different hardware under different operating systems, and support end users with radically different requirements. To enable such shared use of a data base, transformations between various hardware representations and data structuring concepts must be achieved.
3番目に、さまざまの環境で作動しながらプロセスの中でデータの共有をサポートすることを意図します。 すなわち、与えられたデータベースを共有するプログラムは、異なった言語で書かれていて、異なるところで異なったオペレーティングシステムの下でハードウェアを実行して、根本的に異なった要件でエンドユーザをサポートするかもしれません。 データベースのそのような共有された使用を可能にするために、様々な金物表現と概念を構造化するデータの間の変換を達成しなければなりません。
Finally, the datacomputer is designed to function smoothly as a component of a much larger system: a computer network. In a computer network, the datacomputer is a node specialized for data management, and acting as a data utility for the other nodes. The Arpanet, for which the datacomputer is being developed, is an international network which has over 60 nodes. Of these, some are presently specialized for terminal handling, others are specialized for computation (e.g., the ILLIAC IV), some are general purpose service nodes (e.g., MULTICS) and one (CCA) is specialized for data management.
最終的に、datacomputerははるかに大きいシステムの部品としてスムーズに機能するように設計されています: コンピュータネットワーク。 コンピュータネットワークでは、datacomputerはデータ管理のために専門にされて、他のノードのために情報サービスとして機能するノードです。 Arpanet(datacomputerは開発されている)は60以上のノードがある国際ネットワークです。 これらを或るものは現在端末の取り扱いのために専門にされます、そして、他のものは計算(例えば、ILLIAC IV)のために専門にされます、そして、何かが汎用のサービスノード(例えば、MULTICS)です、そして、1つ(CCA)はデータ管理のために専門にされます。
1.2 Datalanguage
1.2 Datalanguage
Datalanguage is the language in which all requests to the datacomputer are stated. It includes facilities for data description and creation, for retrieval of or changes to stored data, and for access to a variety of auxiliary facilities and services. In datalanguage it is possible to specify any operation the datacomputer is capable of performing. Datalanguage is the only language accepted by the datacomputer and is the exclusive means of access to data and services.
Datalanguageはdatacomputerへのすべての要求が述べられている言語です。 それはデータ記述と作成のための施設を含んでいます、記憶されたデータ、およびさまざまな補助設備とサービスへのアクセスのための検索か変化のために。 datalanguageでは、datacomputerが実行できるどんな操作も指定するのは可能です。 Datalanguageはdatacomputerによって受け入れられた唯一の言語であり、データとサービスへのアクセスの排他的な手段です。
Winter, Hill & Greiff [Page 3] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[3ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
1.3 Present Design Effort
1.3 現在のデザイン取り組み
We are now engaged in developing complete specifications for datalanguage; this is the second iteration in the language design process.
私たちは現在、datalanguageのための展開している完全な仕様に従事しています。 これは言語デザイン過程で2番目の繰り返しです。
A smaller, initial design effort developed some concepts and principles which are described in the third working paper in this series. These have been used as the basis of software implementations resulting in an initial network service capability. A user manual for this system was published as working paper number 7.
より小さくて、初期のデザイン取り組みはこのシリーズにおける3番目の監査調書で説明されるいくつかの概念と原則を開発しました。 これらは初期のネットワーク・サービス能力をもたらすソフトウェア実行の基礎として使用されました。 このシステムのための利用者マニュアルは監査調書No.7として発行されました。
As a result of experience gained in implementation and service, through further study of user requirements and work with potential users, and through investigation of other work in the data management field, quite a few ideas have been developed for the improvement of datalanguage. These are being assimilated into the language design in the iteration now in progress.
潜在的ユーザとのユーザ要件と仕事のさらなる研究を通して実装とサービスと、データ管理分野での他の仕事の調査を通して行われた経験の結果、datalanguageの改良のためにかなり多くの考えを開発してあります。 これらは現在進行中の繰り返しにおける言語デザインに同化されています。
When the language design is complete, it will be incorporated into the existing software (requiring changes to the language compiler, but having little impact on the rest of the system).
言語デザインが完全であるときに、それは既存のソフトウェア(言語コンパイラに釣り銭がいますが、システムの残りのときに少ししか影響を与えさせない)に組み入れられるでしょう。
Datacomputer users will first have access to the new language during 1975.
Datacomputerユーザは最初に、1975の間、新しい言語に近づく手段を持つでしょう。
1.4 Purpose of this Paper
1.4 このPaperの目的
This paper presents concepts and preliminary results, rather than a completed design. There are two reasons for publishing now.
この紙は完成したデザインよりむしろ概念と予備の結果を提示します。 現在発行する2つの理由があります。
The first is to provide information to those planning to use the datacomputer. They may benefit from knowledge of our intentions for development.
1番目はdatacomputerを使用するのを計画しているものに情報を提供することです。 彼らは開発のための私たちの意志に関する知識の利益を得るかもしれません。
The second is to enable system and language designers to comment on our work before the design is frozen.
2番目はデザインが凍っている前にシステムと言語デザイナーが私たちの仕事を批評するのを可能にすることです。
1.5 Organization of the Paper
1.5 紙の組織
The remainder of the paper is divided into four sections.
紙の残りは4つのセクションに分割されます。
Section 2 discusses the most global considerations for language design. This comprises our view of the problem; it has influenced our work to date and will determine most of our actions in completion of the design. This section provides background for section 3, and reviews some
セクション2は言語デザインのために最もグローバルな問題について論じます。 これは私たちの問題の視点を包括します。 それは、私たちのこれまでの仕事に影響を及ぼして、デザインの完成における私たちの動作の大部分を決定するでしょう。 このセクションは、セクション3にバックグラウンドを供給して、いくつかを見直します。
Winter, Hill & Greiff [Page 4] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[4ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
material that will be familiar to those who have been following our work closely.
密接に私たちの仕事に続いている人に身近になる材料。
Section 3 discusses some of the specific issues we have worked on. The emphasis is on solutions and options for solution.
セクション3は私たちが取り組んだ特定の問題のいくつかについて論じます。 ソリューションのための解決とオプションには強調があります。
In sections 2 and 3 we are presenting our "top-down" work: this is the thinking we have done based on known requirements and our conception of the desirable properties of datalanguage.
セクション2と3では、私たちは「トップダウン」仕事を示しています: これは私たちが知られている要件と私たちのdatalanguageの望ましい特性に関する概念に基づいてした考えであることです。
We have also been working from the opposite end, developing the primitives from which to construct the language. Section 4 presents our work in this area: a model datacomputer which will ultimately provide a precise semantic definition of datalanguage. Section 4 explains that part of the model which is complete, and relates this to our other work.
また、言語を構成する基関数を開発して、私たちは反対端から働いています。 セクション4はこの領域に私たちの仕事を提示します: 結局datalanguageの正確な意味定義を提供するモデルdatacomputer。 セクション4は、完全なモデルのその部分について説明して、私たちの他の仕事にこれに関連します。
Section 5 discusses work that remains, both on the model and in our top-down analysis.
セクション5はモデルと私たちのトップダウン解析に留まる仕事について論じます。
Winter, Hill & Greiff [Page 5] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[5ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
2. Considerations for Language Design
2. 言語デザインのための問題
2.1 Introduction
2.1 序論
Data management is the task of managing data as a resource, independent of hardware and applications programs. It can be divided it into five major sub-tasks:
データ管理がリソースとしてデータを管理するタスクである、プログラムそれがハードウェアとアプリケーションであることができることの如何にかかわらず、分割されて、5に専攻しますサブ仕事を課して:
(1) _creating_ databases in storage,
(2) making the data _available_ (e.g., satisfying queries),
(3) _maintaining_ the data as information is added, deleted and
modified,
(4) assuring the _integrity_ of the data (e.g., through backup and
recovery systems, through internal consistency checks),
(5) _regulating_access_, to protect the databases, the system, and
the privacy of users.
(1) _(2) (3) _情報が加えられるので_がデータであることを支持して、データ_を利用可能な_(例えば、質問を満たす)にして、_ストレージにおけるデータベースを作成するのは、_データベース、システム、およびユーザのプライバシーを保護するために_アクセス_を規制しながら、(5)を(4) データ(例えば、バックアップと回復システム、内的整合性チェックを通した)を_保全_に保証して、削除して、変更しました。
These are the major data-related functions of the datacomputer; while the system will ultimately provide other services (such as accounting for use, monitoring performance) these are really auxiliary and common to all service facilities.
これらはdatacomputerの主要なデータ関連の機能です。 システムは結局、他のサービス(仕事ぶりを監視して、使用を説明などなどの)を提供するでしょうが、これらは、すべてのサービス施設に本当に補助していて共通です。
This section presents global considerations for the design of datalanguage, based on our observations about the problem and the environment in which it is to be solved. The central problem is data management, and the datacomputer shares the same goals as many currently available data management systems. Several aspects of the datacomputer create a unique set of problems to be solved.
このセクションはdatalanguageのデザインのためにグローバルな問題を提示します、問題に関する私たちの観測とそれが解決されることになっている環境に基づいて。 主要な問題はデータ管理です、そして、datacomputerは多くの現在利用可能なデータ管理システムと同じ目標を共有します。datacomputerのいくつかの局面が、解決されるためにユニークなセットの問題を生じさせます。
2.2 Hardware Considerations
2.2 ハードウェア問題
2.2.1 Separate Box
2.2.1 別々の箱
The datacomputer is a complete data management utility in a separate, closed box. That is, the hardware, the data and the data management software are segregated from any general-purpose processing facilities. There is a separate installation dedicated to data management. Datalanguage is the only means users have for communicating with the datacomputer and the sole activity of the datacomputer is to process datalanguage requests.
datacomputerは別々の、そして、閉じている箱の中の完全なデータ管理ユーティリティです。 すなわち、ハードウェア、データ、およびデータ管理ソフトウェアはどんな汎用処理施設からも隔離されます。 データ管理に捧げられた別々のインストールがあります。 Datalanguageはユーザがdatacomputerとコミュニケートするために持っている唯一の手段です、そして、datacomputerの唯一の活動はdatalanguage要求を処理することです。
Dedicating hardware provides an obvious advantage: one can specialize it for data management. The processor(s) can be modified to have data management "instructions"; common low-level software functions can be built into the hardware.
ハードウェアを捧げると、明白な利点は提供されます: 1つはデータ管理のためにそれを専門にすることができます。 データ管理「指示」を持つようにプロセッサを変更できます。 ハードウェアを一般的な低レベルであるソフトウェア機能に組み込むことができます。
Winter, Hill & Greiff [Page 6] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[6ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
A less obvious, but possibly more significant, advantage is gained from the separateness itself. The system can be more easily protected. A fully-developed datacomputer on which there is only maintenance activity can provide a very carefully controlled environment. First, it can be made as physically secure as required. Second, it needs to execute only system software developed at CCA; all user programs are in a high-level language (datalanguage) which is effectively interpreted by the system. Hence, only datacomputer system software processes the data, and the system is not very vulnerable to capture by a hostile program. Thus, since there is the potential to develop data privacy and integrity services that are not available on general-purpose systems, one can expect less difficulty in developing privacy controls (including physical ones) for the datacomputer than for the systems it serves.
単独自体からそれほど明白でない、しかし、ことによるとより重要な利点を獲得します。 より容易にシステムを保護できます。 メインテナンス活動しかない完全に開発されたdatacomputerは非常に慎重に制御された環境を提供できます。 まず最初に、必要に応じてそれを肉体的に同じくらい安全にすることができます。 2番目に、CCAで開発されたシステムソフトだけを実行するのが必要です。 事実上、システムによって解釈される高位言語(datalanguage)にはすべてのユーザ・プログラムがあります。 datacomputerシステムソフトだけがデータを処理します、そして、システムは、敵軍のプログラムでキャプチャするためにそれほど害を被りやすくはありません。 したがって、汎用システムの上で利用可能でないデータプライバシーと保全サービスを開発する可能性があるので、人はdatacomputerのために、プライバシーコントロール(物理的なものを含んでいる)を開発することにおけるそれが役立つシステムより少ない苦労を予想できます。
2.2.2 Mass Storage Hardware
2.2.2 大容量記憶ハードウェア
The datacomputer will store most of its data on mass storage devices, which have distinctive access characteristics. Two examples of such hardware are Precision Instruments' Unicon 690 and Ampex Corporation's TBM system. They are quite different from disks, and differ significantly from one another.
datacomputerは特有のアクセスの特性を持っている大記憶装置に関するデータの大部分を保存するでしょう。 そのようなハードウェアに関する2つの例が、Precision InstrumentsのUnicon690とアンペックス社のTBMシステムです。 彼らは、ディスクと全く異なって、お互いから有意差があります。
However, almost all users will be ignorant of the characteristics of these devices; many will not even know that the data they use is at the datacomputer. Finally, as the development of the system progresses, data may be invisibly shunted from one datacomputer to another, and as a result be stored in a physical format quite different from that originally used.
しかしながら、ほとんどすべてのユーザがこれらのデバイスの特性に無知になるでしょう。 多くが、それらが使用するデータがdatacomputerにあるのを知ってさえいないでしょう。 システムの開発が進歩をするとき、最終的に、データは、1datacomputerから別のdatacomputerまで目につかないほど転じて、元々使用されたそれと全く異なった物理的な形式でその結果保存されるかもしれません。
In such an environment, it is clear that requests for data should be stated in logical, not physical terms.
そのような環境で、少しの物理的な期間も論理的にデータに関する要求を述べないのは明確です。
2.3 Network Environment
2.3 ネットワーク環境
The network environment provides additional requirements for datacomputer design.
ネットワーク環境はdatacomputerデザインのための追加要件を提供します。
2.3.1 Remote Use
2.3.1 リモート使用
Since the datacomputer is to be accessed remotely, the requirement for effective data selection techniques and good mechanisms for the expression of selection criteria is amplified. This is because of the narrow path through which network users communicate with the datacomputer. Presently, a typical process-to-process transfer rate over the Arpanet is 30 kilobits per second. While this can be increased through optimization of software and protocols, and through additional
datacomputerが離れてアクセスされることになっているので、選択評価基準の式のための効果的なデータ選択のテクニックと良いメカニズムのための要件は増幅されます。 ネットワーク利用者がdatacomputerとコミュニケートする狭い経路のためにこれはそうです。 現在、Arpanetの上のプロセスからプロセスへの典型的な転送レートは1秒あたり30のキロビットです。 ソフトウェアとプロトコルの最適化を通して追加を通してこれを増強できますが
Winter, Hill & Greiff [Page 7] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[7ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
expenditure for hardware and communications lines, it seems safe to assume that it will not soon approach local transfer rates (measured in the megabits per second).
ハードウェアとコミュニケーションのための費用は立ち並んでいて、すぐ地方の転送レート(1秒あたりのメガビットでは、測定される)にアプローチしないと仮定するのは安全に思えます。
A typical request calls for either transfer of part of a file to a remote site, or for selective update to a file already stored at the datacomputer. In both of these situations, good mechanisms for specifying the parts of the data to be transmitted or changed will reduce the amount of data ordinarily transferred. This is extremely important because with the low per bit cost of storing data at the datacomputer, transmission costs will be a significant part of the total cost of datacomputer usage.
典型的な要求はリモートサイト、または選択しているアップデートのためのファイルの一部の転送をdatacomputerに既に保存されたファイルに求めます。 これらの状況の両方では、伝えるか、または変えるためにデータの部分を指定するための良いメカニズムは通常、移されたデータ量を減少させるでしょう。 トランスミッションコストがdatacomputerにデータを保存する噛み付いている費用あたりの安値でdatacomputer用法の総費用のかなりの部分になるので、これは非常に重要です。
2.3.2 Interprocess Use of the Datacomputer System
2.3.2 Datacomputerシステムのインタプロセス使用
Effective use of the network requires that groups of processes, remote from one another, be capable of cooperating to accomplish a given task or provide a given service. For example, to solve a given problem which involves array manipulation, data retrieval, interaction with a user at a terminal, and the generalized services of a language like PL/I, it may be most economical to have four cooperating processes. One of these could execute at the ILLIAC IV, one at the datacomputer, one at MULTICS, and one at a TIP. While there is overhead in setting up these four processes and in having them communicate, each is doing its job on a system specialized for that job. In many cases, the result of using the specialized system is a gain of several orders of magnitude in economy or efficiency (for example, online storage at the datacomputer has a capital cost two orders of magnitude lower than online costs on conventional systems). As a result, there is considerable incentive to consider solutions involving cooperating processes on specialized systems.
ネットワークの有効な使用は、プロセスのお互いからリモートなグループが協力していて、与えられたタスクを達成できるか、または与えられたサービスを提供するのを必要とします。 データの検索、端末のユーザとの相互作用、およびPL/Iのような言語の一般化されたサービス、例えば配列操作にかかわる与えられた問題を解決するなら、4つの協調処理を持つために最も経済的であるかもしれません。 これらの1つはdatacomputer、MULTICSの1、およびTIPの1のときにILLIAC IV、1のときに実行するかもしれません。 これらの4つのプロセスをセットアップして、交信させるのにおいてオーバーヘッドがある間、それぞれがその仕事のために専門にされたシステムに仕事しています。 多くの場合、専門化しているシステムを使用するという結果は経済か効率が数桁の獲得(例えば、datacomputerのオンラインストレージで、資本コストは従来のシステムの上でオンラインコストより2桁低くなる)です。 その結果、プロセスと協力することを伴うソリューションがシステムを専門にしたと考えるかなりの誘因があります。
To summarize: the datacomputer must be prepared to function as a component of small networks of specialized processes, in order that it can be used effectively in a network in which there are many specialized nodes.
まとめるために: 専門化しているプロセスの小さいネットワークの成分として機能するようにdatacomputerを準備しなければなりません、多くの専門化しているノードがあるネットワークに有効にそれを使用できるように。
2.3.3 Common Network Data Handling
2.3.3 一般的なネットワークデータハンドリング
A large network can support enough data management hardware to construct more than one datacomputer. While this hardware can be combined into one even larger datacomputer, there are advantages to configuring it as two (or possibly more) systems. Each system should be large enough to obtain economies of scale in data storage and to support the data management software. Important data bases can be duplicated, with a copy at each datacomputer; if one datacomputer fails, or is cut off by
大きいネットワークは1datacomputerを組み立てることができるくらいのデータ管理ハードウェアを支えることができます。 1さらに大きいdatacomputerにこのハードウェアを結合できますが、2台(ことによるとさらに)のシステムとしてそれを構成する利点があります。それぞれのシステムはデータ保存で規模の経済を得て、データ管理ソフトウェアを支えることができるくらい大きいはずです。 コピーが各datacomputerにある状態で、重要なデータベースをコピーできます。 1datacomputerが失敗するか、またはオフに切られるなら
Winter, Hill & Greiff [Page 8] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[8ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
network failure, the data is still available. Even if duplicating the file is not warranted, the description can be kept at the different datacomputers so that applications which need to store data constantly can be guaranteed that at least one datacomputer is available to receive input.
失敗をネットワークでつないでください、そして、データはまだ利用可能です。 コピーしても、ファイルを保証しないで、少なくとも1datacomputerが入力を受け取るために利用可能であることをデータを保存する必要があるアプリケーションは絶えず保証できるように異なったdatacomputersに記述を保つことができます。
These kinds of failure protection involve cooperation between a pair of datacomputers; in some sense, they require that the two datacomputers function as a single system. Given a system of datacomputers (which one can think of as a small network of datacomputers), it is obviously possible to experiment with providing additional services on the datacomputer-network level. For example, all requests could be addressed simply to the datacomputer-network; the datacomputer-network could then determine where each referenced file was stored (i.e., which datacomputer), and how best to satisfy the request.
失敗保護のこれらの種類は1組のdatacomputersの間の協力にかかわります。 何らかの意味で、彼らは、2datacomputersがただ一つのシステムとして機能するのを必要とします。 datacomputers(ものがdatacomputersの小さいネットワークとして考えることができる)のシステムを考えて、datacomputer-ネットワークレベルで追加サービスを提供するのに実験するのは明らかに可能です。 例えば、単にdatacomputer-ネットワークにすべての要求を扱うことができました。 そして、datacomputer-ネットワークは、それぞれの参照をつけられたファイルがどこに保存されたか、そして、(すなわち、どのdatacomputer)どのように要望に特に応じるかを決定できました。
Here, two kinds of cooperation in the network environment have been mentioned: cooperation among processes to solve a given problem, and cooperation among datacomputers to provide global optimizations in the network-level data handling problem. These are only two examples, especially interesting because they can be implemented in the near term. In the network, much more general kinds of cooperation are possible, if a little farther in the future. For example, eventually, one might want the datacomputer(s) to be part of a network-wide data management system, in which data, directories, services, and hardware were generally distributed about the network. The entire system could function as a whole under the right circumstances. Most requests would use the data and services of only a few nodes. Within this network-wide system, there would be more than one data management system, but all systems would be interfaced through a common language. Because the datacomputers represent the largest data management resource in the network, they would certainly play an important role in any network-wide system. The language of the datacomputer (datalanguage) is certainly a convenient choice for the common language of such a system.
ここに、ネットワーク環境への2種類の協力は言及されました: 与えられた問題を解決するプロセスの中の協力、およびネットワークレベルデータハンドリング問題にグローバルな最適化を提供するdatacomputersの中の協力。 これらは近いうちにそれらを実装することができるので特におもしろい2つの例にすぎません。 ネットワークでは、ずっと多くの一般的な種類の協力は、将来、可能であって、少し遠いです。 例えば、結局、人は、datacomputer(s)にネットワーク全体のデータ管理システムの一部になって欲しいかもしれません。(一般に、そこでは、データ、ディレクトリ、サービス、およびハードウェアがネットワークに関して配布されました)。 全体のシステムは全体で条件さえそろえば機能できました。 ほとんどの要求がほんのいくつかのノードのデータとサービスを利用するでしょう。 このネットワーク全体のシステムの中に、1台以上のデータ管理システムがあるでしょうが、すべてのシステムが共通語を通して連結されるでしょう。 datacomputersがネットワークで最も大きいデータ管理リソースを表すので、確かに、彼らはどんなネットワーク全体のシステムでも重要な役割を果たすでしょう。 確かに、datacomputer(datalanguage)の言語はそのようなシステムの共通語のための便利な選択です。
Thus a final, albeit futuristic, requirement imposed by the network on the design of the datacomputer system, is that it be a suitable major component for network-wide data management systems. If feasible, one would like datalanguage to be a suitable candidate for the common language of a network-wide group of cooperating data management systems.
したがって、datacomputerシステムの設計のネットワークによって課された最終的で、それにしても、未来の要件はそれがネットワーク全体のデータ管理システムのための適当な主要なコンポーネントであるということです。可能であるなら、datalanguageは協力関係を持っているデータ管理システムのネットワーク全体のグループの共通語について1つが適当な候補になりたがっています。
2.4 Different Modes of Datacomputer Usage
2.4 Datacomputer用法の異なったモード
Within this network environment, the datacomputer will play several roles. In this section four such roles are described. Each of them imposes constraints on the design of datalanguage. We can analyze them in terms of four overlapping advantages which the datacomputer provides:
このネットワーク環境の中では、datacomputerはいくつかの役割を果たすでしょう。 このセクションで、そのような4つの役割が説明されます。 それぞれの彼らはdatalanguageのデザインに規制を課します。 私たちはdatacomputerが提供する4つの重ね合わせ利点に関してそれらを分析できます:
Winter, Hill & Greiff [Page 9] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[9ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
1. Generalized data management services
2. Large file handling
3. Shared access
4. Economic volume storage
1. 一般化されたデータ管理は2を修理します。 大きいファイル取り扱3い。 共用アクセス4。 経済ボリュームストレージ
Of course, the primary reason for using the datacomputer will be the data management services which it provides. However, for some applications size will be the dominating factor in that the datacomputer will provide for online access to files which are so large that previously only offline storage and processing were possible. The ability to share data between different network sites with widely different hardware is another feature provided only by the datacomputer. Economies of scale make the datacomputer a viable substitute for tapes in such applications as operating system backup.
もちろん、datacomputerを使用するプライマリ理由はデータそれが提供する経営指導になるでしょう。 しかしながら、datacomputerが以前に、唯一のオフラインストレージと処理が可能であったほど大きいファイルへのオンラインアクセスに備えるので、いくつかのアプリケーションのために、サイズは支配している要素になるでしょう。 異なったネットワークサイトの間のデータをはなはだしく異なったハードウェアと共有する能力は単にdatacomputerによって提供された別の特徴です。 規模の経済はオペレーティングシステムバックアップのようなアプリケーションでdatacomputerをテープの実行可能な代用品にします。
Naturally, a combination of the above factors will be at work in most datacomputer applications. The following subsections describe some possible modes of interaction with the datacomputer.
当然、ほとんどのdatacomputerアプリケーションにおける仕事には上記の要素の組み合わせがあるでしょう。 以下の小区分はdatacomputerとの相互作用のいくつかの可能なモードを説明します。
2.4.1 Support of Large Shared Databases
2.4.1 大きい共有データベースのサポート
This is the most significant application of the datacomputer, in nearly every sense.
これはdatacomputerのほとんどあらゆる意味で最も重要なアプリケーションです。
Projects are already underway which will put databases of over one hundred billion bits online on the Arpanet datacomputer. Among these are a database which will ultimately include 10 years of weather observations from 5000 weather stations located all over the world. As online databases, these are unprecedented in size. They will be of international interest and be shared by users operating on a wide variety of hardware and in a wide variety of languages.
プロジェクトは既に進行中です(Arpanet datacomputerのオンラインの1000億ビット以上のデータベースを置くでしょう)。 このうち、結局世界中に位置した5000の測候所からの10年間の気象観測を含んでいるデータベースがあります。 オンラインデータベースとして、これらはサイズが空前です。 それらは、国際的関心があって、さまざまなハードウェアとさまざまな言語で働いているユーザによって共有されるでしょう。
Because these databases are online in an international network, and because they are expected to be of considerable interest to researchers in the related fields, it seems obvious that there will be extremely broad patterns of use. A strong requirement, then, is a flexible and general approach to handling them. This requirement of providing different users of a database with different views of the data is an overriding concern of the datalanguage design effort. It is discussed separately in Section 2.5.
これらのデータベースが国際ネットワークでオンラインであり、それらが関連分野において、研究者への相当な興味のものであると予想されるので、使用の非常に広いパターンがあるのは明白に見えます。 そして、強い要件はそれらを扱うことへのフレキシブルで一般的なアプローチです。 データの異なった意見をデータベースの異なったユーザに提供するこの要件はdatalanguageデザイン取り組みの最優先の関心です。 別々にセクション2.5でそれについて議論します。
2.4.2 Extensions of Local Data management Systems
2.4.2 Local Data管理Systemsの拡大
We imagine local data handling systems (data management systems, applications-oriented packages, text-handling systems, etc.) wanting to take advantage of the datacomputer. They may do so because of the
私たちは、datacomputerを利用したくしながら、地方のデータハンドリングがシステム(データ管理システム、アプリケーション指向のパッケージ、テキスト取り扱いシステムなど)であると想像します。 彼らはそうするかもしれません。
Winter, Hill & Greiff [Page 10] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[10ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
economics of storage, because of the data management services, or because they want to take advantage of data already stored at the datacomputer. In any case, such systems have some distinctive properties as datacomputer users: (1) most would use local data as well as datacomputer data, (2) many would be concerned with the translation of local requests into datalanguage.
データ経営指導のため、またはそれらがdatacomputerに既に保存されたデータを利用したがっているのでストレージの経済学。 どのような場合でも、そのようなシステムには、datacomputerユーザとしていくつかの特有の特性があります: (1) (2) 大部分はdatacomputerデータと同様にローカルのデータを使用して、多くがdatalanguageへのローカルの要求に関する翻訳に関係があるでしょう。
For example, a system which does simple data retrieval and statistical analysis for non-programming social scientists might want to use a census database stored at the datacomputer. Such a system may perform a range of data retrieval functions, and may need sophisticated interaction with the datacomputer. Its usage patterns would make quite a contrast with those of a single application program whose sole use of the datacomputer involves printing a specific report based on a single known file.
例えば、非プログラミング社会科学者のための簡単なデータの検索と統計分析をするシステムはdatacomputerに保存された国勢調査データベースを使用したがっているかもしれません。 そのようなシステムは、さまざまなデータの検索機能を実行して、datacomputerとの洗練された相互作用を必要とするかもしれません。 用法パターンはdatacomputerの唯一の使用がただ一つの知られているファイルに基づく特定のレポートを印刷することを伴うただ一つのアプリケーション・プログラムのものに対するかなりの対照をなすでしょう。
This social-science system would also use some local databases, which it keeps at its own site because they are small and more efficiently accessed locally. One would like it to be convenient to think of data the same way, whether it is stored locally or at the datacomputer. Certainly at the lower levels of the local software, there will have to be differences in interfacing; it would be nice, however, if local concepts and operations could easily be translated into datalanguage.
また、この社会科学システムはいくつかのローカルのデータベースを使用するでしょう。(それらが小さく効率的に局所的にもう少しアクセスされているので、それはそれ自身のサイトにデータベースを保ちます)。 局所的かdatacomputerに保存されるか否かに関係なく、それは、同じようにデータを考えるために1つが近くなりたがっています。 確かにローカルのソフトウェアの下のレベルでは、そこでは、連結の違いでなければならないでしょう。 しかしながら、容易にローカルの概念と操作をdatalanguageに翻訳できるなら、良いでしょうに。
2.4.3 File Level Use of the Datacomputer
2.4.3 Datacomputerのファイルの平らな使用
In this mode of use, other computer systems take advantage of the online storage capacity of the datacomputer. To these systems, datacomputer storage represents a new class of storage: cheaper and safer than tape, nearly as accessible as local disk. Perhaps they even automatically move files between local online storage and the datacomputer, giving users the impression that everything is stored locally online.
使用のこの方法で、他のコンピュータ・システムはdatacomputerのオンラインストレージ容量を利用します。 これらのシステムに、datacomputerストレージは新しいクラスのストレージを表します: ほとんど同じくらいアクセスしやすいテープよりさらに安くて、ローカルディスクより安全です。 恐らく、彼らは自動的にファイルを地方のオンラインストレージとdatacomputerの間に動かしさえします、すべてが局所的にオンラインで保存されるという印象をユーザに与えて。
The distinctive feature of this mode of use is that the operations are on whole files.
使用のこの方法に関する顕著な特徴は全体のファイルの上に操作があるということです。
A system operating in this mode uses only the ability to store, retrieve, append, rename, do directory listings and the like. An obvious way to make such file level handling easily available to the network community is to make use of the File Transfer Protocol (see Network Information Center document #17759 -- File Transfer Protocol) already in use for host to host file transfer.
このモードで作動するシステムが保存する能力だけを使用する、検索、追加、改名、ディレクトリリストと同様のものはそうします。 そのようなものに容易にネットワーク共同体に利用可能な平らな取り扱いをファイルさせる当たり前の方法はホストには、ホストファイル転送に既に使用中のFile Transferプロトコル(Networkインフォメーション・センタードキュメント#17759を見てください--Transferプロトコルをファイルする)を利用することです。
Although such "whole file" usage of the datacomputer would be motivated primarily by economic advantages of scale, data sharing at the file level could also be a concern. For example, the source files of common network software might reside at the datacomputer. These files have
datacomputerのそのような「全体のファイル」使用法は主として経済規模の利益によって動機づけられるでしょうが、また、ファイルレベルで共有されるデータは関心であるかもしれません。 例えば、一般的なネットワークソフトウェアに関するソースファイルはdatacomputerに住むかもしれません。 これらのファイルはそうしました。
Winter, Hill & Greiff [Page 11] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[11ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
little or no structure, but their common use dictates that they be available in a common, always accessible place. It is taking advantage of the economics of the datacomputer, more than anything else, since most of these services are available on any file system.
しかし、ほとんど構造がない、彼らの一般の使用は、それらが一般的で、いつもアクセスしやすい場所で利用可能であると決めます。 それはdatacomputerの経済学を利用しています、他の何よりも、これらのサービスの大部分がどんなファイルシステムの上でも利用可能であるので。
This mode of use is mentioned here because it may account for a large percentage of datalanguage requests. It requires only capabilities which would be present in datalanguage in any case; the only special requirement is to make sure it is easy and simple to accomplish these tasks.
datalanguage要求の大きな割合を説明するかもしれないので、使用のこの方法はここに言及されます。 どのような場合でも、それはdatalanguageで存在している能力だけを必要とします。 唯一の特別な要件はこれらのタスクを達成するのが確実に簡単で簡単になるようにすることです。
2.4.4 Use of Datacomputer for File Archiving
2.4.4 Datacomputerのファイル格納の使用
This is another economics-oriented application. The basic idea is to store on the datacomputer everything that you intend to read rarely, if ever. This could include backup files, audit trails, and the like.
これは別の経済学指向のアプリケーションです。 基本的な考え方はdatacomputerにあなたがめったに読まないつもりであるすべてを保存することです、かつてなら。これはバックアップファイル、監査証跡、および同様のものを含むかもしれません。
An interesting idea related to archiving is incremental archiving. A typical practice, with regard to backing up data stored online in a time-sharing system, is to write out all the pages which are different than they were in the last dump. It is then possible to recover by restoring the last full dump, and then restoring all incremental dumps up to the version desired. This system offers a lower cost for dumping and storage, and a higher cost for recovery; it is appropriate when the probability of needing a recovery is low. Datalanguage, then, should be designed to permit convenient incremental archiving.
格納に関連するおもしろい考えは増加の格納です。 時分割システムにオンラインで保存されたデータを支援することに関して、典型的な習慣はそれらより最後のダンプにおいて異なったすべてのページを書き上げることになっています。 最後の完全なダンプを復元して、次に、バージョンまでの増加の憂鬱が望んでいたすべてを回復することによって回復するのはその時、可能です。 このシステムは、ダンピングとストレージのために低い費用を提供して、回復のために、より高い費用を提供します。 回復を必要とするという確率が低いときに、それは適切です。 そして、Datalanguageは、便利な増加の格納を可能にするように設計されるべきです。
As in the case of the previous application (file system), archiving is important as a design consideration because of its expected frequency and economics, not because it necessarily requires any extra generality at the language level. It may dictate that specialized mechanisms for archiving be built into the system.
先の出願(ファイルシステム)に関するケースのように、格納はその期待度数と経済学のために設計の検討として重要です、それが必ず言語水準で付加的な一般性を必要とするからであるというわけではありません。 それは、システムが格納のための専門化しているメカニズムに組み込まれると決めるかもしれません。
2.5 Data Sharing
2.5 データ共有
Controlled sharing of data is a central concern of the project. Three major sub-problems in data sharing are: (1) concurrent use, (2) independent concepts of the same database, and (3) varying representations of the same database.
データの制御共有はプロジェクトの中央の関心です。 データ共有における3つの重大なサブ問題は以下の通りです。 (1) (2) 同じデータベース、および(3)の独立している概念が同じデータベースの表現を変える同時発生の使用。
Concurrent use of a resource by multiple independent processes is commonly implemented for data on the file level in systems in which files are regarded as disjoint, unrelated objects. It is sometimes implemented on the page level.
複数の独立しているプロセスによるリソースの同時発生の使用はばらばらになるときファイルが見なされるシステムのファイルレベルに関するデータのために一般的に実装されます、関係ないオブジェクト。 それはページレベルで時々実装されます。
Considerable work on this problem has already been done within the
この問題に対するかなりの仕事が既に完了していました。
Winter, Hill & Greiff [Page 12] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[12ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
datacomputer project. When this work is complete, it will have some impact on the language design; by and large however, we do not consider this aspect of concurrent use to be a language problem.
datacomputerプロジェクト。 この仕事が完全であるときに、言語デザインに何らかの影響力を持つでしょう。 しかしながら、概して、私たちは、同時発生の使用のこの局面が言葉の問題であると考えません。
Other aspects of the concurrent use problem, however, may require more conscious participation by the user. They relate to the semantics of collections of data objects, when such collections span the boundaries of files known to the internal operating system. Here the question of what constitutes an update conflict is more complex. Related questions arise in backup and recovery. If two files are related, then perhaps it is meaningless to recover an earlier state of one without recovering the corresponding state of the other. These problems are yet to be investigated.
同時発生の他の局面は問題を使用して、しかしながら、ユーザによる、より意識的な参加を必要とするかもしれません。 それらはデータ・オブジェクトの収集の意味論に関連します、そのような収集が内部のオペレーティングシステムに知られているファイルの限界にかかるとき。 ここで、アップデート闘争を構成することに関する質問は、より複雑です。 関連質問はバックアップと回復で起こります。 2個のファイルが話されるなら、恐らく、もう片方の対応する状態を回復しないで1人の以前の状態を回復するのは無意味です。 これらの問題はまだ調査されていないことです。
Another problem in data sharing is that not all users of a database should have the same concept of that database. Examples: (1) for privacy reasons, some users should be aware of only part of the database (e.g., scientists doing statistical studies on medical files do not need access to name and address), (2) for program-data independence, payroll programs should access only data of concern in writing paychecks, even though skill inventories may be stored in the same database, (3) for global control of efficiency, simplicity in application programming, and program-data independence each application program should "see" a data organization that is best for its job.
データ共有における別の問題はデータベースのすべてのユーザにはそのデータベースの同じ概念があるべきであるというわけではないということです。 例: (1) (2) プライバシー理由で、何人かのユーザがデータベースの一部だけを意識しているべきである(例えば、医療ファイルに関する統計的な研究をしている科学者が命名するアクセスとアドレスを必要としません)、プログラムデータ独立のために、給料支払名簿プログラムは給料を書くのにおいて重要なデータだけにアクセスするはずです; (3) 技能目録は同じデータベースに保存されるかもしれませんが、効率のグローバルなコントロール、アプリケーションプログラミングにおける簡単さ、およびプログラムデータ独立に関して、各アプリケーション・プログラムは仕事に、最も良いデータ編成を「見るべきです」。
To further analyze example (3), consider a database which contains
information about students, teachers, subjects and also indicates which
students have which teachers for which subjects. Depending on the
problem to be solved, an application program may have a strong
requirement for one of the following organizations:
(1) entries of the form (student,teacher,subject) with no concern about
redundancy. In this organization an object of any of the three
types may occur many times.
(2) entries of the form
(student, (teacher,subject),
(teacher,subject),
.
.
.
(teacher,subject))
(3) entries of the form
(teacher, subject,(student...student),
subject,(student...student),
subject,(student.. .student))
and other organizations are certainly possible.
さらに例(3)を分析するには、学生、教師、問題に関して情報を含んでいて、またどの対象のためにどの学生にどの教師がいるかを示すデータベースを考えてください。 アプリケーション・プログラムには、解決すべき課題によって、以下の組織の1つのための強い要件があるかもしれません: (1) 冗長に関する心配のない形式(学生、教師、対象)のエントリー。 この組織では、3つのタイプのどれかのオブジェクトは何回も現れるかもしれません。 (2) 形成してください。エントリー、(学生、(教師、対象)、(教師、対象)、確かに、フォーム(教師、対象、(学生の…学生)、対象、(学生の…学生)、対象、(学生.. .student))と他の組織の…(教師、対象)(3)エントリーは可能です。
One approach to this problem is to choose an organization for stored data, and then have application programs write requests which organize
この問題への1つのアプローチは、記憶されたデータのための組織を選んで、次に、アプリケーション・プログラムに結団される要求を書かせることです。
Winter, Hill & Greiff [Page 13] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[13ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
output in the form they want. The application programmer applies his ingenuity in stating the request so that the process of reorganization is combined with the process of retrieval, and the result is relatively efficient. There are important, practical situations in which this approach is adequate; in fact there are situations in which it is desirable. In particular, if efficiency or cost is an overriding consideration, it may be necessary for every application programmer to be aware of all the data access and organization factors. This may be the case for a massive file, in which each retrieval must be tuned to the access strategy and organization; any other mode of operation would result in unacceptable costs or response times.
彼らが欲しいフォームにおける出力。 アプリケーション・プログラマーは再編成のプロセスが検索のプロセスに結合されるように、要求を述べる際に彼の巧みさを適用します、そして、結果は比較的効率的です。 このアプローチが適切である重要で、実用的な状況があります。 事実上、それが望ましい状況があります。 すべてのアプリケーション・プログラマーがすべてのデータ・アクセスと組織要素を知るのが効率か費用が最優先の考慮であるなら、特に、必要であるかもしれません。 これは大規模なファイルのためのそうであるかもしれません。(そこではアクセス戦略と組織に各検索を調整しなければなりません)。 いかなる他の運転モードも容認できないコストか応答時間をもたらすでしょう。
However, dependence between application programs and data organization or access strategy is not a good policy in general. In a widely-shared database, it can mean enormous cost in the event of database reorganization, changes to access software, or even changes in the storage medium. Such a change may require reprogramming in hundreds of application programs distributed throughout the network.
しかしながら、アプリケーション・プログラムとデータ編成かアクセス戦略の間の依存は一般に、得策ではありません。 広く共有されたデータベースでは、それはデータベース再編成(記憶媒体でソフトウェア、または変化にさえアクセスする変化)の場合、莫大な費用を意味できます。 そのような変化は、ネットワーク中で配布された何百ものアプリケーション・プログラムでプログラムを変えるのを必要とするかもしれません。
As a result, we see a need for a language which supports a spectrum of operating modes, including: (1) application program is completely independent of storage structure, access technique, and reorganization strategy, (2) application program parametrically controls these, (3) application program entirely controls them. For a widely-shared database, mode (1) would be the preferred policy, except when (a) the application programmer could do a better job than the system in making decisions, and (b) the need for this increment of efficiency outweighed the benefits of program-data independence.
その結果、私たちはオペレーティング・モード、包含のスペクトルをサポートする言語の必要性を認めます: (1) アプリケーション・プログラムが格納構造、アクセスのテクニック、および再編成戦略から完全に独立している、(2) アプリケーション・プログラムはparametricallyにこれらを制御して、(3) アプリケーション・プログラムはそれらを完全に制御します。 広く共有されたデータベースに関しては、モード(1)は都合のよい方針でしょう、(a) アプリケーション・プログラマーが決定をする際にシステムより良い仕事ができて、(b) 効率のこの増分の必要性がプログラムデータ独立の利益より重かった時を除いて。
In evaluating this question for a particular application, it is important to realize the role of global efficiency analysis. When there are many users of a database, in some sense the best mode of operation is that which minimizes the total cost of processing all requests and the total cost of storing the data. When applications come and go, as real-world needs change, then the advantages of centralized control are more likely to outweigh the advantages of optimization for a particular application program.
特定用途のためにこの質問を評価するのにおいて、グローバルな効率分析の役割がわかるのは重要です。 データベースの多くのユーザがいるとき、何らかの意味で、最も良い運転モードはすべての要求と合計がかかるデータを保存する総加工費を最小にするそれです。 本当の世界の必要性が変化するのに応じて、アプリケーションが来て、動いていると、集中制御の利点は特定用途プログラムのための最適化の利点より、より重そうです。
The third major sub-problem arises in connection with item level representations. Because of the environment in which it executes, each application program has a preferred set of formatting concepts, length indicators, padding and alignment conventions, word sizes, character representations, and so on. Once again it is better policy for the application program to be concerned only with the representations it wants and not with the stored data representation. However, there will be cases in which efficiency for a given request overrides all other factors.
3番目の重大なサブ問題は項目レベル表現に関して起こります。 中のそれが実行する環境のために、各アプリケーション・プログラムは形式概念、長さのインディケータ、詰め物、整列コンベンション、語長、文字表示都合のよいなどを開きます。 もう一度、アプリケーション・プログラムは記憶されたデータ表現ではなく、それが欲しい表現だけに関係があるのが、より良い方針です。 しかしながら、与えられた要求のための効率が他のすべての要素に優越する場合があるでしょう。
Winter, Hill & Greiff [Page 14] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[14ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
At this level of representation, there is at least one additional consideration: potential loss of information when conversion takes place. Whoever initiates a type conversion (and this will sometimes be the datacomputer and sometimes the application program) must also be responsible for seeing that the intent of the request is preserved. Since the datacomputer must always be responsible for the consistency and the meaning of a shared database, there are some conflicts to be resolved here.
このレベルの表現には、少なくとも1つの追加的約因があります: 変換がいつ行われるかという情報の潜在的損失。 また、要求の意図が保存されるのがわかるのに型変換(これは、時々時々datacomputerとアプリケーション・プログラムになる)に着手する人なら誰でも責任があるに違いありません。 datacomputerはいつも共有データベースの一貫性と意味に責任があるに違いないので、ここで決議されるために、いくつかの闘争があります。
To summarize, it seems that the result of wide sharing of databases is that a larger system must be considered in choosing a data management policy for a particular database. This larger system, in the case of the datacomputer, consists of a network of geographically distributed applications programs, a centralized database, and a centralized data management system. The requirement for datalanguage is to provide flexibility in the management of this larger system. In particular, it must be possible to control when and where conversions, data re- organizations, and access strategies are made.
まとめるために思える、データベースの広い共有の結果が特定のデータベースのためにデータ経営政策を選ぶ際に、より大きいシステムを考えなければならないということであるように思えます。 datacomputerの場合では、このより大きいシステムは地理的に分配されたアプリケーションプログラム、集中データベース、および集結されたデータ管理システムのネットワークから成ります。 datalanguageのための要件はこのより大きいシステムの管理に柔軟性を提供することです。 変換、データ再組織、およびアクセス戦略がいつ、どこで作られているかを制御するのは特に、可能でなければなりません。
2.6 Need for High Level Communication
2.6 上位通信の必要性
All of the above considerations point to the need for high level communication between the datacomputer and its users. The complex and distinct nature of datacomputer hardware make it imperative that requests be put to the datacomputer so that it can make major decisions regarding the access strategies to be used. At the same time, the large amounts of data stored and the demand of some users for extremely high transmission bandwidths make it necessary to provide for user control of some storage and transmission schemes. The fact that databases will be used by applications which desire different views of the same data and with different constraints means that the datacomputer must be capable of mapping one users request onto another users data. Interprocess use of the datacomputer means that datasharing must be completely controllable to avoid the need for human intervention. Extensive facilities for ensuring data integrity and controlling access must be provided.
上の問題のすべてがdatacomputerとそのユーザの間に上位通信の必要性を示します。 datacomputerハードウェア造の複雑で異なった本質、それ、使用されるというアクセス戦略に関する主たる決定をすることができるようにdatacomputerにつけられるよう要求する命令。 同時に、保存されたデータの多量と非常に高いトランスミッション帯域幅への何人かのユーザの要求で、何らかのストレージとトランスミッション体系のユーザコントロールに備えるのは必要になります。 データベースが同じデータと異なった規制がある異なった視点を望んでいるアプリケーションで使用されるという事実は、datacomputerが1つのユーザ要求を別のユーザデータに写像できなければならないことを意味します。 datacomputerのインタプロセス使用は、datasharingが人間の介入の必要性を避けるのにおいて完全に制御可能でなければならないことを意味します。 データ保全を確実にして、アクセスを制御するための大規模な施設を提供しなければなりません。
2.6.1 Data Description
2.6.1 データ記述
Basic to all these needs is the requirement that the data stored at the datacomputer be completely described in both functional and physical parameters. A high level description of the data is especially important to provide the sharing and control of data. The datacomputer must be able to map between different hardware and different applications. In its most trivial form this means being able to convert between floating point number representations on different machines. On
これらのすべての必要性に基本的であるのは、datacomputerに保存されたデータが機能的なものと同様に物理的なパラメタで完全に説明されるという要件です。 データの高い平らな記述は、データの共有とコントロールを提供するために特に重要です。 datacomputerは異なったハードウェアで異なることの間でアプリケーションを写像できなければなりません。 最も些細なフォームでは、これは、異なったマシンの上で浮動小数点表現の間で変換できることを意味します。 オン
Winter, Hill & Greiff [Page 15] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[15ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
the other extreme it means being able to provide matrix data for the ILLIAC IV as well as being able to provide answers to queries from a natural language program, both addressed to the same weather data base. Data descriptions must provide the ability to specify the bit level representations and the logical properties and relationships of data.
それができることと同様にILLIAC IVが提供するようにマトリクスデータを提供できることを意味する全く正反対は自然言語プログラム(同じ気象データベースに扱われた両方)から質問に対応します。 データ記述はデータの噛み付いている平らな表現、論理的な特性、および関係を指定する能力を提供しなければなりません。
2.6.2 Data integrity and Access Control
2.6.2 データの保全とAccess Control
In the environment we have been describing, the problems of maintaining data integrity and controlling use of data assume extreme importance. Shared use of datacomputer files depends on the ability of the datacomputer to guarantee that the restrictions on data-access are strictly enforced. Since different users will have different descriptions, the access control mechanism must be associated with the descriptions themselves. One can control access to data by controlling access to its various descriptors. A user can be constrained to access a given data base only through one specific description which limits the data he can access. In a system where the updaters of a database may be unknown to each other, and possibly have different views of the data, only the datacomputer can assure data integrity. For this reason, all restrictions on possible values of data objects, and on possible or necessary relationships between objects must be stated in the data description.
私たちが説明している環境で、データ保全を維持して、データの使用を制御するという問題は極端な重要を帯びています。 datacomputerファイルの共有された使用はdatacomputerが、データ・アクセスの制限が厳密に励行されるのを保証する能力に依存します。 異なったユーザには異なった記述があるので、アクセス管理機構は記述自体に関連しているに違いありません。 人は、様々な記述子へのアクセスを制御することによって、データへのアクセスを制御できます。 単に彼が制限できるデータを制限する1つの明確な記述でユーザが与えられたデータベースにアクセスするのを抑制できる、アクセサリー データベースのupdatersが互いにおいて未知であり、ことによるとデータの異なった視点を持っているかもしれないシステムで、datacomputerだけがデータ保全を保証できます。 この理由、可能データの値は反対して、オブジェクトの間の可能であるか必要な関係にデータ記述で述べなければならないのをにおけるすべての制限のために。
2.6.3 Optimization
2.6.3 最適化
The decisions regarding data access strategy must ordinarily be made at the datacomputer, where knowledge of the physical considerations is available. These decisions cannot be made intelligently unless the requests for data access are made at a high level.
datacomputerで通常データ・アクセス戦略に関する決定をしなければなりません。そこでは、物理的な問題に関する知識が利用可能です。 高いレベルでデータ・アクセスを求める要求をしない場合知的にこれらの決定をすることができません。
For example, compare the following two situations: (1) a request calls for output of _all_ weather observations made in California exhibiting certain wind and pressure conditions, (2) a series of requests is sent, each one retrieving California weather observations; when a request finds an observation with the required wind and pressure conditions, it transmits this observation to a remote system. Both sessions achieve the same result: the transmission of a certain set of observations to a remote site for processing. In the first session, however, the datacomputer receives, at the outset, a description of the data that is needed; in the second, it processes a series of requests, each one of which is a surprise.
例えば、以下の2つの状況を比較してください: (1) (2) _すべての_気象観測の出力のための呼び出しが、ある風と圧力状態を示すカリフォルニアでした要求、一連の要求を送ります、各々がカリフォルニアの気象観測を検索して。 要求が必要な風と圧力状態で観測を見つけるとき、それはこの観測をリモートシステムに伝えます。 両方のセッションは同じ結果を獲得します: 処理のためのリモートサイトへのある観測の送信。 しかしながら、最初のセッションのときに、datacomputerは最初に、必要であるデータの記述を受けます。 2番目では、それは一連の要求を処理します。その各々は驚きです。
In the first case, a smart datacomputer has the option of retrieving all of the needed data in one access to the mass storage device. It can then buffer this data on disk until the user is ready to accept it. In
前者の場合、賢いdatacomputerには、大記憶装置への1回のアクセスにおける、必要なデータのすべてを検索するオプションがあります。 そして、ユーザがそれを受け入れる準備ができるまで、それはディスクの上のこのデータをバッファリングできます。 コネ
Winter, Hill & Greiff [Page 16] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[16ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
the second case, the datacomputer lacks the information it needs to make such an optimization.
2番目のケースであり、datacomputerはそれがそのような最適化をするように必要とする情報を欠いています。
The language should permit and encourage users to provide the information needed to do optimization. The cost of not doing it is much higher with mass storage devices and large files than it is in conventional systems.
言語は、ユーザが最適化をするのに必要である情報を提供するよう許可して、奨励するべきです。 それをしない費用はそれよりはるかに大記憶装置と大きいファイルで従来のシステムで高いです。
2.7 Application Oriented Concerns
2.7 アプリケーションの指向の関心
In the above sections we have described a number of features which the datacomputer system must provide. In this section we focus on what is necessary to make these features readily available to users of the datacomputer.
上のセクションで、私たちはdatacomputerシステムが提供しなければならない多くの特徴について説明しました。 このセクションでは、私たちはこれらの特徴をdatacomputerのユーザには容易に利用可能にするのに必要なことに焦点を合わせます。
2.7.1 Datacomputer-user Interaction
2.7.1 Datacomputer-ユーザ相互作用
An application interacts with the datacomputer in a _session_. A session consists of a series of requests. Each session involves connecting to the datacomputer via the network, establishing identities, and setting up transmission paths for both data and datalanguage. Datalanguage is transmitted in character mode (using network standard ASCII) over the datalanguage connection. Error and status messages are sent over this connection to the application program.
アプリケーションは_セッションが一連の要求から成る_セッションのときにdatacomputerと対話します。 各セッションは、ネットワークを通してdatacomputerに接続することを伴います、データとdatalanguageの両方のためにアイデンティティを確立して、トランスミッション経路をセットアップして。 キャラクタ・モード(ネットワークの標準のASCIIを使用する)でDatalanguageはdatalanguage接続の上に伝えられます。 アプリケーション・プログラムとのこの接続の上に誤りとステータスメッセージを送ります。
The data connection (called a PORT) is viewed as a bit stream and is given its own description. These descriptions are similar to those given for stored data. At a minimum this description must contain enough information for the datacomputer to parse the incoming bit stream. It also may contain data validation information as well. To store data at the datacomputer, the stored data must also have a description. The user supplies the mapping between the descriptions of the stored and transmitted data.
データ接続(PORTと呼ばれる)に少し流れるとき見て、それ自身の記述を与えます。 これらの記述は記憶されたデータのために与えられたものと同様です。 最小限では、この記述はdatacomputerが入って来るビットストリームを分析できるくらいの情報を含まなければなりません。 また、それはまた、データ合法化情報を含むかもしれません。 また、datacomputerにデータを保存するために、記憶されたデータには、記述がなければなりません。 ユーザは保存されて伝えられたデータの記述の間にマッピングを提供します。
Winter, Hill & Greiff [Page 17] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[17ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_____________________________________
| | / /
| ______ ___________ | \ \
| | |---| | | / /
| | | | DATA | | \ \
| | | |DESCRIPTION| _______ | DATALANGUAGE ___________
| | | |___________| | |<-------------------->| |
| |STORED| |________| USER | | PATH |APPLICATION|
| | DATA |__________________|REQUEST| | | PROGRAM |
| | | |_______|<----!--------------->|___________|
| | | ___________ | ! DATA PATH
| | | | | | ! / /
| | | | PORT |-----! \ \
| | | |DESCRIPTION| | / /
| |______| |___________| | \ \
|_____________________________________| / /
NETWORK
Figure 2-1
A Model of Datacomputer/User Interaction
_____________________________________ | | / / | ______ ___________ | \ \ | | |---| | | / / | | | | データ| | \ \ | | | |記述| _______ | DATALANGUAGE___________ | | | |___________| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |保存されます。| |________| ユーザ| | 経路|アプリケーション| | | データ|__________________|要求| | | プログラム| | | | |_______| <、-、-、--!--------------->|___________| | | | ___________ | ! データ経路| | | | | | ! / / | | | | ポート|-----! \ \ | | | |記述| | / / | |______| |___________| | \ \ |_____________________________________| //ネットワーク図2-1 Datacomputer/ユーザ相互作用のモデル
2.7.2 Application Features for Data Sharing
2.7.2 データ共有のためのアプリケーション機能
In using data stored at the datacomputer, users may supply a description of the data which is customized to the application. This description is mapped onto the description of the stored data. These descriptions may be at different levels. That is, one may merely rearrange the order of certain items, while another could call for a total restructuring of the stored representation. So that each user may be able to build upon the descriptions of another, data entities should be given named types. These type definitions are of course to be stored along with the data they describe. In addition, certain functions are so closely tied to the data (in fact may be the data in the virtual description case -- see section 3), that they must also reside in the datacomputer and their tie with the data items should be maintained by the datacomputer. For example, one user can describe a data base as made up of structures containing data of the types _latitude_ and _longitude_. He could also describe functions for comparing data of this type. Other users, not concerned with the structure of the _latitude_ component itself, but interested in using this information simply to extract other fields of interest can then use the commonly provided definitions and functions. Furthermore, by adopting this strategy as many users as possible can be made insensitive to changes in the file which are tangential to their main interests. For example, _latitudes_ could be changed from binary representation to a character form and if use of that field were restricted to its definitions and associated functions, existing
datacomputerに保存されたデータを使用する際に、ユーザはアプリケーションにカスタム設計されるデータの記述を供給するかもしれません。 この記述は記憶されたデータの記述に写像されます。 これらの記述が異なったレベルにあるかもしれません。 すなわち、単にある項目の注文を再配列するかもしれません、別のものは保存された表現の総企業再構築を求めるかもしれませんが。 それぞれのユーザが別のものの記述を当てにすることができるかもしれないように、データ実体を命名されたタイプに与えるべきです。 これらの型定義はもちろんそうです。それらが説明するデータと共に保存されるために。 さらに、ある機能が密接にデータにあまりに結ばれる(事実上、仮想の記述ケースの中のデータであるかもしれません--セクション3を見てください)、また、データ項目とのdatacomputerと彼らの繋がりで住んでいなければならないのはdatacomputerによって維持されるはずです。 例えば、1人のユーザがタイプの_緯度_と_経度_に関するデータを含む構造で作られるようにデータベースについて説明できます。また、彼は、このタイプに関するデータを比較するために機能について説明できました。 _の緯度_部品自体の構造に関係がありませんでしたが、次に、単に興味がある他の野原を抽出するのが一般的に提供された定義と機能を使用できるというこの情報を使用したがっていた他のユーザ。 その上、この戦略を採用することによって、できるだけ多くのユーザをファイルにおける彼らの最も関心を持っていることに付随的な変化に神経が鈍くすることができます。 _例えば、地方_はキャラクタフォーム、その分野の使用が定義に制限されたか、そして、および関連2進法表示から機能に変わることができました、既存です。
Winter, Hill & Greiff [Page 18] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[18ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
application systems would be unaffected. Conversion functions could be defined to eliminate the impact on currently operating programs. The ability of such definitional facilities means that groups of users can develop common functions and descriptions for dealing with shared data and that conventions for use of shared data can be enforced by the datacomputer. These facilities are discussed under _extensibility_ in Section 3.
アプリケーション・システムは影響を受けないでしょう。 変換機能は、プログラムを操作しながら現在で影響を排除するために定義されるかもしれません。そのようなdefinitional施設の能力は、ユーザのグループが共有データに対処するための一般的な機能と記述を開発できて、datacomputerが共有データの使用のためのコンベンションを実施できることを意味します。 セクション3で_伸展性_の下でこれらの施設について議論します。
___________________________________________ _______________
| ____________ | | ___________ |
| |APPLICATION | | | |APPLICATION| |
| _| DATA |_|____|_| PROGRAM | |
| | |DESCRIPTIONS| | | |___________| |
| | |____________| | |_______________|
| | ^ | HOST 1
| ______ | | |
| | | | _____|______ |
| | | | | DATA | |
| | | | | FUNCTIONS | |
| | | | |____________| | _______________
| | | ___________ | ____________ | | ___________ |
| | | | STORED |__| | | | | |APPLICATION| |
| | |__| DATA |____| |_|____|_| PROGRAM | |
| |STORED| |DESCRIPTION|__ | | | | |___________| |
| | DATA | |___________| | |____________| | | |
| | | ^ | ____________ | | ___________ |
| | | | | | | | | |APPLICATION| |
| | | _____|_____ | | |_|____|_| PROGRAM | |
| | | | DATA | |_| | | | |___________| |
| | | | FUNCTIONS | |____________| | |_______________|
| |______| |___________| | HOST 2
|___________________________________________|
DATACOMPUTER
___________________________________________ _______________ | ____________ | | ___________ | | |アプリケーション| | | |アプリケーション| | | _| データ|_|____|_| プログラム| | | | |記述| | | |___________| | | | |____________| | |_______________| | | ^ | ホスト1| ______ | | | | | | | _____|______ | | | | | | データ| | | | | | | 機能| | | | | | |____________| | _______________ | | | ___________ | ____________ | | ___________ | | | | | 保存されます。|__| | | | | |アプリケーション| | | | |__| データ|____| |_|____|_| プログラム| | | |保存されます。| |記述|__ | | | | |___________| | | | データ| |___________| | |____________| | | | | | | ^ | ____________ | | ___________ | | | | | | | | | | |アプリケーション| | | | | _____|_____ | | |_|____|_| プログラム| | | | | | データ| |_| | | | |___________| | | | | | 機能| |____________| | |_______________| | |______| |___________| | ホスト2|___________________________________________| DATACOMPUTER
Figure 2-2
Multiple User Interaction with the Datacomputer
図2-2 Datacomputerとの複数のユーザ相互作用
2.7.3 Communication Model
2.7.3 コミュニケーションモデル
We intend that datalanguage, while at a high level conceptually, will be at a low level syntactically. Datalanguage provides a set of primitive functions, and a set of commonly used higher level functions (see section 4 on the datalanguage model). In addition, users can define their own functions so that they can communicate with the datacomputer at a level as conceptually close to the application as possible.
高いレベルにある間、私たちはそのdatalanguageを意図して、概念的に、シンタクス上低レベルにあるでしょう。 Datalanguageは1セットの原始関数、および1セットの一般的に使用されたより高い平らな機能を提供します(datalanguageモデルの上でセクション4を見てください)。 さらに、ユーザは、彼らがアプリケーションの近くでできるだけ概念的にdatacomputerとレベルでコミュニケートできるように、それら自身の機能を定義できます。
Winter, Hill & Greiff [Page 19] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[19ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
There are two reasons for datalanguage being at a low level syntactically. First, it is undesirable to have programs composing requests into an elaborate format only to be decomposed by the datacomputer. Second, by choosing a specific high level syntax, the datacomputer would be imposing a set of conventions and terminology which would not necessarily correspond to those of most users.
シンタクス上低レベルにあるdatalanguageの2つの理由があります。 まず最初に、プログラムに入念な形式に要求をdatacomputerによって分解される構成させるのは、望ましくありません。 2番目に、特定の高い平らな構文を選ぶことによって、datacomputerは必ずほとんどのユーザのものと食い違っている1セットのコンベンションと用語を課しているでしょう。
DATACOMPUTER ENVIRONMENT | OUTSIDE ENVIRONMENT
DATACOMPUTER環境| 外部環境
| _______
| |____
| __|GENERAL|____
| | DMS |____
| | |_______|
_________ ________ _________ |
| | | HIGHER | | |__| _______ ________
|PRIMITIVE|___| LEVEL |___|LOW-LEVEL|_____|COBOL | | COBOL |
|LANGUAGE | |LANGUAGE| | SYNTAX |__ |SERVER |___|PROGRAM |
|_________| |________| |_________| | |_______| |________|
| | _______
|__|ON LINE|
| | QUERY |_______
|_______| |
| ___|____
|TERMINAL|
| | USERS |
|________|
|
APPLICATION APPLICATIONS
| SERVERS
| _______ | |____ | __|一般|____ | | DMS|____ | | |_______| _________ ________ _________ | | | | より高い| | |__| _______ ________ |原始|___| レベル|___|低レベルである|_____|COBOL| | COBOL| |言語| |言語| | 構文|__ |サーバ|___|プログラム| |_________| |________| |_________| | |_______| |________| | | _______ |__|稼働中| | | 質問|_______ |_______| | | ___|____ |端末| | | ユーザ| |________| | アプリケーションアプリケーション| サーバ
Figure 2-3
Datacomputer/User Working Environment
図2-3 Datacomputer/ユーザ作業環境
2.8 Summary
2.8 概要
In this section we have presented the major considerations which have influenced the current datalanguage design effort. The datacomputer has much in common with most large-scale shared data management systems, but also has a number of overriding concerns unique to the datacomputer concept. The most important of these are the existence of a separate box containing both hardware and software, the control of an extremely large storage device, and embedding in a computer network environment. Data sharing in such an environment is a central concern of the design. Both extensive data description facilities and high level communication
このセクションでは、私たちは現在のdatalanguageデザイン取り組みに影響を及ぼした主要な問題を提示しました。 datacomputerはほとんどの大規模な共有データマネージメントシステムと共用して多くを持っていますが、多くの最優先の関心をdatacomputer概念にユニークにまたします。 最も重要なこれらは、ハードウェアとソフトウェアの両方を入れてある別々の箱の存在と、非常に大きい記憶装置のコントロールと、コンピュータネットワーク環境への埋め込みです。 そのような環境を分担するデータはデザインの中央の関心です。 広範な資料記述施設と上位通信の両方
Winter, Hill & Greiff [Page 20] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[20ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
between user and datacomputer are necessary for data integrity and for datacomputer optimization of user requests. In addition, the expected use of the datacomputer involves satisfying several conflicting constraints for different modes of operation. One way of satisfying various user needs is to provide datalanguage features so that users may develop their own application packages within datalanguage.
間に、ユーザとdatacomputerがデータ保全とユーザ要求のdatacomputer最適化に必要です。 さらに、datacomputerの予想された使用は、異なった運転モードのいくつかの闘争規制を満たすことを伴います。 様々なユーザ需要を満たす1つの方法はユーザがdatalanguageの中でそれら自身のアプリケーションパッケージを開発できるようにdatalanguageの特徴を提供することです。
Winter, Hill & Greiff [Page 21] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[21ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
3. Principal Language Concepts
3. 主要言語概念
This section discusses the principal facilities of datalanguage. Specific details of the language are not presented, however, the discussion includes the motivation behind the inclusion of the various language features and also defines, in an informal way, the terms we use.
このセクションはdatalanguageの主要な施設について論じます。 言語の特定の詳細が提示されないで、しかしながら、議論は、様々な言語機能の包含の後ろに動機を含んで、また、非公式の方法で私たちが使用する用語を定義します。
3.1 Basic Data Items
3.1 基礎データ項目
Basic data are the atomic level of all data constructions; they cannot be decomposed. All higher level data structures are fundamentally composed of basic data items. Many types of basic data items will be provided. The type of an item determines what operations can be performed on the item and the meaning of those operations. Datalanguage will provide those primitive types of data items which are commonly used in computing systems to model the real world.
基礎データはすべてのデータ構造の原子レベルです。 それらを分解できません。 基礎データ項目ですべての、より高い平らなデータ構造を基本的に構成します。多くのタイプの基礎データ商品を提供するでしょう。 項目のタイプは、それらの操作の項目と意味にどんな操作を実行できるかを決心しています。 Datalanguageはモデル化するのにコンピューティング・システムで一般的に使用されるそれらのプリミティブ型のデータ項目に本当の世界を提供するでしょう。
The following basic types of data will be available in datalanguage: _fixed_point_numbers_, _floating_point_numbers_, _characters_, _booleans_, and _bits_. These types of items are "understood" by the datacomputer system to the extent that operations are based on the type of an item. Datalanguage will also include an _uninterpreted_ type of item, for data which will only be moved (including transmitted) from one place to another. This type of data will only be understood in the trivial sense that the datacomputer can determine if two items of the uninterpreted type are identical. Standard operations on the basic types of items will be available. Operations will be included so that the datacomputer user can describe a wide range of data management functions. They are not included with the intent of encouraging use of the datacomputer for the solving of highly computational problems.
以下の基本型のデータはdatalanguageで利用可能になるでしょう: __固定_ポイント_数の_、__浮動_ポイント数の_、_キャラクタ_、_ビット_論理演算子_、およびこれらのタイプの項目はdatacomputerシステムによって操作が項目のタイプに基づいているという範囲まで「理解されています」。 また、Datalanguageは_の非解釈された_タイプの項目を含むでしょう、1つの場所から別の場所まで動かされるだけである(包含は伝わりました)データのために。 このタイプに関するデータはdatacomputerが、非解釈されたタイプの2つの項目が同じであるかどうか決定できるという些細な意味で理解されるだけでしょう。 項目の基本型における標準の操作は利用可能になるでしょう。 操作は、datacomputerユーザがさまざまなデータ管理機能について説明できるように、含まれるでしょう。 それらはdatacomputerの非常にコンピュータの問題の解決の使用を奨励する意図をもって含まれていません。
3.2 Data Aggregates
3.2 データ集合体
Data aggregates are compositions of basic data items and possibly other data aggregates. The types of data aggregates which are provided allow for the construction of hierarchical relationships of data. The aggregates which will definitely be available are classified as _structs_, _arrays_, _strings_, _lists_, and _directories_.
データ集合体は基本的なデータ項目とことによると他のデータ集合体の構成です。 提供されるデータ集合体のタイプはデータの上下関係の工事を考慮します。 確実に利用可能になる集合は_structs_として分類されて、_は_を整列させて、_は_を結んで、_は_、および_ディレクトリ_を記載します。
A struct is a static aggregate of data items (called _components_). A struct is static in the sense that the components of a struct cannot be added or deleted from the struct, they are inextricably bound to the struct. Associated with each component of the struct is a name by which that component may be referenced relative to the struct. The struct aggregate may be used to model what is often thought of as a record,
structはデータ項目(_コンポーネント_と呼ばれる)の静的な集合です。 structはstructからstructの部品を加えることができないか、削除できないで、それらが解決できなくstructに縛られるという意味で静的です。 structの各部品に関連づけられているのは、そのコンポーネントがstructに比例して参照をつけられるかもしれない名前です。 struct集合は、記録としてしばしば考えられることをモデル化するのに使用されるかもしれません。
Winter, Hill & Greiff [Page 22] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[22ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
with each component being a field of that record. A struct can also be used to group components of a record which are more strongly related, conceptually, than other components and may be operated on together.
その分野である各コンポーネントで、記録してください。 structはまた、他のコンポーネントより強く概念的に関係づけられた記録の成分を分類するのに使用できて、一緒にいるところで操作されるかもしれません。
Arrays allow for repetition in data structures. An array, like a struct, is a static aggregate of data items (called _members_). Each member of an array is of the same type. Associated with each member is an index by which that member can be referenced relative to the array. Arrays can he used to model repeating data in a record (repeating groups).
配列はデータ構造における反復を考慮します。 structのように、配列はデータ項目(_メンバー_と呼ばれる)の静的な集合です。 同じタイプには配列の各メンバーがいます。 各メンバーに関連づけられているのは、配列に比例してそのメンバーに参照をつけることができるインデックスです。 彼がレコード(繰返し集団)の繰り返しているデータをモデル化するのに使用した缶を整列させます。
The concept of string is actually a hybrid of basic data and data aggregates. Strings are aggregates in that they are compositions (similar to arrays) of more primitive data (e.g., characters). They are, however, generally conceived of as basic in that they are mostly viewed as a unit rather than as a collection of items, where each item has individual importance. Also the meaning of a string is highly dependent on the order of the individual components. In more concrete terms, there are operations which are defined on specific types of strings. For example, the logical operators (_and_, _or_, etc.) are defined to operate on strings of bits. However, there are no operations which are defined on arrays of bits, although there are operations defined on both arrays, in general, and on bits. Strings of characters, bits, and uninterpreted data will be available in datalanguage.
ストリングの概念は実際に基礎データとデータ集合体のハイブリッドです。 それらが、より原始のデータ(例えば、キャラクタ)の構成(配列と同様の)であるので、ストリングは集合です。 しかしながら、一般に、それらは、各個条が個々の重要性を持っている項目の収集としてというよりむしろユニットとしてほとんど見なされるので、基本的であるとして想像されます。 また、ストリングの意味も個々のコンポーネントの注文に非常に依存しています。 より多くの具体名辞には、特定のタイプのストリングの上に定義される操作があります。 例えば、論理演算子、(_と_、_か_、など) ビットのストリングを作動させるために、定義されます。 しかしながら、ビットの配列で定義される操作が全くありません、両方の配列の上と、そして、一般に、そして、ビットの上で定義された操作がありますが。 キャラクタ、ビット、および非解釈されたデータのストリングはdatalanguageで利用可能になるでしょう。
Lists are like arrays in that they are collection of similar members. However, lists are dynamic rather than static. Members of a list can be added and deleted from the list. Although, the members of a list are ordered (in fact more than one ordering can be defined on a list), the list is not intended to be referenced via an index, as is the case with an array. Members of a list can be referenced via some method of sequencing through the list. A list member, or set (see discussion under virtual data) of members, can also be referenced, by some method of identification by content. The list structure can be used to model the common notion of a file. Also restrictive use of lists as components of structs provides power with respect to the construction of dynamic hierarchical data relationships below the file level. For example, the members of a list may themselves be, in part, composed of lists, as in a list of families, where each family contains a list of children as well as other information.
リストは、それらが同様のメンバーの収集であるので、配列に似ています。 しかしながら、静的であるというよりむしろリストはダイナミックです。 リストからリストのメンバーを加えて、削除できます。 リストのメンバーは配列に関してそうであるようにインデックスで参照をつけられて、リストを意図しないよう命令されます(事実上、リストで、ある注文を定義できるより多くの)。 リストを通した配列の何らかのメソッドでリストのメンバーに参照をつけることができます。 また、リストメンバー、またはメンバーのセット(仮想データの下で議論を見る)に参照をつけることができます、内容による識別の何らかのメソッドで。 ファイルの一般的な概念をモデル化するのにリスト構造を使用できます。 また、structsの部品としてのリストの制限的用法はダイナミックな階層データ関係の工事に関して権限をファイルレベルより下であるまで提供します。 例えば、リストのメンバーは記載するかもしれません。自分たちがリストで一部構成されて、aのようにファミリーについて記載してください。そこでは、各ファミリーが他の情報と同様に子供のリストを含みます。
Directories are dynamic data aggregates which may contain any type of data item. Data items contained in a directory are called _nodes_. Associated with each node of a directory is a name by which that data item can be referenced relative to the directory. As with lists, items may be dynamically added to and deleted from a directory. The primary motivation behind providing the directory capability is to allow the user to group conceptually related data together. Since directories
ディレクトリはどんなタイプのデータ項目も含むかもしれないダイナミックなデータ集合体です。 ディレクトリに含まれたデータ項目は_ノード_と呼ばれます。ディレクトリの各ノードに関連づけられているのは、ディレクトリに比例してそのデータ項目に参照をつけることができる名前です。 リストなら、項目は、ダイナミックに加えられて、ディレクトリから削除されるかもしれません。 ユーザがディレクトリ能力で分類することになっていることができる提供の後ろのプライマリ動機は概念的にデータについて一緒に話しました。 ディレクトリ以来
Winter, Hill & Greiff [Page 23] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[23ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
need not contain only file type information, "auxiliary" data can be kept as part of the directory. For example, "constant" information, like salary range tables for a corporation data base; or user defined operations and data types (see below) can be maintained in a directory along with the data which may use this information. Also directories may themselves be part of a directory, allowing for a hierarchy of data grouping.
必要性はファイルの種類情報だけを含んでいなくて、ディレクトリの一部として「補助」のデータは保つことができます。 例えば、会社データベースへの給料こんろ台のような「一定」の情報。 または、この情報を使用するかもしれないデータに伴うディレクトリでユーザの定義された操作とデータ型(以下を見る)を維持できます。 また、自分たちがディレクトリの一部、階層構造を考慮することであって、ディレクトリはそうするかもしれません。データ組分けについて。
Directories will also be defined so that system controlled information can be maintained with some of the subordinate items (e.g. time of creation, time of update, privacy locks, etc.). It may also be possible to allow the data user to define and control his own information which would be maintained with the data. At the least, the design of datalanguage will allow for parametric control over the information managed by the system.
また、ディレクトリは、数個の下位の項目(例えば、作成の時間、アップデートの時間、プライバシー錠など)でシステムの制御情報を保守できるように定義されるでしょう。 また、データユーザがデータで保守される彼自身の情報を定義して、制御するのを許容するのも可能であるかもしれません。 少なくとも、datalanguageのデザインはシステムによって管理された情報のパラメトリックコントロールを考慮するでしょう。
Directories are the most general and dynamic type of aggregate data. Both the name and description (see below) of directory nodes exist with the nodes themselves, rather than as part of the description of the directory. Also the level of nesting of a directory is dynamic since directories can be dynamically added to directories. Directories are the only aggregate for which this is true.
ディレクトリは最も一般的でダイナミックなタイプに関する集合体データです。 名前とディレクトリノードの記述(以下を見る)の両方がノード自体で存在しています、むしろディレクトリの記述の一部より。 また、ディレクトリの巣篭もりのレベルも、ダイナミックにディレクトリをディレクトリに追加できるので、ダイナミックです。 ディレクトリはこれが本当である唯一の集合です。
Datalanguage will also provide some specific and useful variations of the above data aggregates. Structs will be available which allow for optional components. In this case the existence of a component would be based on the contents of other components. It may also he possible to allow for the existence to be based on information found at a higher level of data hierarchy. Similarly, components with _unresolved_ type will be provided. That is the component may be one of a fixed number of types. The type of the component would be based on the contents of other components of the struct. It is also desirable to allow the type or existence of a component to be based on information other than the contents of other components. For instance, the type of one component might be based on the type of another component. In general, we would like for datalanguage to allow for the attributes (see below) of one item to be a function of the attributes of other items.
また、Datalanguageは上記のデータ集合体のいくつかの特定の、そして、役に立つ変化を供給するでしょう。 Structsは利用可能になるでしょう(任意のコンポーネントを考慮します)。 この場合、コンポーネントの存在は他のコンポーネントのコンテンツに基づくでしょう。 また、そうするかもしれない、彼、存在が、より高いレベルのデータ階層構造で見つけられた情報に基づくのを許容するのにおいて、可能です。 同様に、_未定の_タイプがあるコンポーネントを提供するでしょう。 すなわち、コンポーネントはタイプの定数の1つであるかもしれません。 コンポーネントのタイプはstructの他の部品のコンテンツに基づくでしょう。 また、コンポーネントのタイプか存在が他のコンポーネントのコンテンツ以外の情報に基づくのを許容するのも望ましいです。 例えば、1つのコンポーネントのタイプは別のコンポーネントのタイプに基づくかもしれません。 一般に、私たちは、datalanguageに、1つの項目の属性(以下を見る)が他の項目の属性の関数であることを許容して欲しいと思います。
We would also like to provide mixed lists. Mixed lists are lists which contain more than one type of member. In this case the members would have to be self defining. That is, the type of all member would have to be "alike" to the degree that information which defines the type of that member could be found.
また、複雑なリストを提供したいと思います。 Mixedリストは1つ以上のタイプのメンバーを含むリストです。 この場合、メンバーは自己定義でなければならないでしょう。 すなわち、すべてのメンバーのタイプは度合いに、「同じく」そのメンバーのタイプを定義するその情報を見つけることができたということでなければならないでしょう。
Similar to components whose type is unresolved are Arrays with unresolved length. In this case, information defining the length of the array must be carried with the array or perhaps with other components of an aggregate which encompasses the array.
タイプが未定であるコンポーネントと同様であるのは、未定の長さがあるArraysです。 この場合、配列か恐らく配列を取り囲む集合の他の構成要素で配列の長さを定義する情報を運ばなければなりません。
Winter, Hill & Greiff [Page 24] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[24ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
In all of the above cases the type of an item is unresolved to some degree and information which totally resolves the type is carried with the item. It is possible that in some or perhaps all of these cases the datacomputer system could be responsible for the maintenance of this information, making it invisible to the data user.
全部で、上の場合では、項目のタイプはある程度未定です、そして、タイプを完全に決議する情報が項目で運ばれます。 これらのケースのいくつかか恐らくすべてでは、datacomputerシステムがこの情報のメインテナンスに原因となるかもしれないのは、可能です、それをデータユーザにとって目に見えなくして。
3.3 General Relational Capabilities
3.3 一般関係能力
The data aggregates described above allow for the modeling of various relationships among data. All relationships which can be constructed are hierarchical.
上で説明されたデータ集合体はデータの中で様々な関係のモデルを考慮します。 構成できるすべての関係が階層的です。
Two approaches can he taken to provide the capability of modeling non- hierarchical relationships. New types of data aggregates can be introduced which will broaden the range of data relationships expressible in datalanguage. Or, a basic data type of "pointer" can be introduced which will serve as a primitive out of which relations can be represented. Pointer would be a data type which establishes some kind of correspondence from one item to another. That is, it would be a method of finding one item, given another . Providing the ability to have items of type pointer does not necessitate the introduction of the concept of address which we deem to be a dangerous step. For example, an item defined to point to a record in a personnel file could contain a social security number which is contained in each record of the file and uniquely identifies that record. In general a pointer is an item of information which can be used to uniquely identify another item.
2つのアプローチがそうすることができる、彼、非上下関係をモデル化する能力を提供するために、取ります。 datalanguageで表現できるデータ関係の範囲を広げる新しいタイプに関するデータ集合体は紹介できます。 または、どの関係からの原始のaを表すことができるように役立つ「指針」の基本のデータ型は紹介できます。 指針は1つの項目から別のものへのある種の通信を確立するデータ型でしょう。 すなわち、それは1つの項目を見つけるメソッドでしょう、別のものを考えて。タイプ指針の項目を持つ能力を提供する場合、私たちが危険なステップであると考えるアドレスの概念の導入は必要としません。 例えば、人員ファイルでの記録を示すために定義された項目はファイルに関する各記録に含まれていて、唯一その記録を特定する社会保険番号を含むかもしれません。 一般に、指針は唯一別口を特定するのに使用できる情報の項目です。
While the pointer approach provides the greater degree of flexibility, it does this at the price of relegating much of the work to the user as well as severely limiting the amount of control the datacomputer system has over the data. A hybrid solution is possible, where some new aggregate data types are provided as well as a restricted form of pointer data type. While the approach to be taken is still being studied, the datalanguage design will include some method of expressing non-hierarchical data structures.
指針アプローチは、より大きい度合いの柔軟性を提供しますが、それは、仕事の多くをユーザに左遷する価格において厳しくdatacomputerシステムがデータの上に持っているコントロールの量を制限しながら、これをします。 ハイブリッドソリューションは可能です、制限されたフォームのポインタデータタイプと同様に何人かの新しい集合体データタイプを提供するところで。 取られるべきアプローチがまだ研究されている間、datalanguageデザインは非階層データ構造を急送する何らかのメソッドを含むでしょう。
3.4 Ordering of Data
3.4 データの注文
Lists are generally viewed as ordered. It is possible, however, that a list can be used to model a dynamic collection of similar items which are not seen as ordered. The unordered case is important, in that, given this information the datacomputer can be more efficient since new members can be added wherever it is convenient.
一般に、リストは命令されると見なされます。 しかしながら、命令されるのはみなされない同様の項目のダイナミックな収集をモデル化するのにリストを使用できるのが可能です。 順不同のケースは重要です、それで、datacomputerがどこでも、それが便利であるところで新しいメンバーを加えることができるので、より効率的である場合があるというこの情報を考えて。
There are a number of ways a list can be ordered. For instance, the ordering of a list can be based on the contents of its members. In the
リストを注文できる多くの方法があります。 例えば、リストの注文をメンバーのコンテンツに基礎づけることができます。 in
Winter, Hill & Greiff [Page 25] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[25ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
simplest case this involves the contents of a basic data item. For example, a list of structs containing information on employees of a company may be ordered on the component which contains the employee's social security number. More complex ordering criteria are possible. For example, the same list could be ordered alphabetically with respect to the employee's last name. In this case the ordering relation is a function of two items, the last and first names. The user might also want to define his own ordering scheme, even for orderings based on basic data items. An ordering could be based on an employee's job title which might even utilize auxiliary data (i.e. data external to the list). It is also possible to maintain a list in order of insertion. In the most general case, the user could dynamically define his ordering by specification of where an item is to be placed as part of his insertion requests. In all of the above cases, data could be maintained in ascending or descending order.
これをケースに入れてください。簡単である、基礎データ項目のコンテンツにかかわります。 例えば、会社の従業員の情報を含むstructsのリストは従業員の社会保険番号を含むコンポーネントで注文されるかもしれません。 より複雑な注文評価基準は可能です。 例えば、アルファベット順に、従業員の姓に関して同じリストを注文できました。 この場合、注文関係は2つの項目、最終、および名の機能です。 また、ユーザは彼自身の注文体系を定義したがっているかもしれません、基礎データ項目に基づく受注業務のためにさえ。注文は補助のデータ(すなわち、リストへの外部のデータ)を利用さえするかもしれない従業員の役職に基づくことができました。 また、挿入の順にリストを維持するのも可能です。 最も一般的な場合では、ユーザはダイナミックに彼の挿入要求の一部として置かれる項目がことであるところに関する仕様で彼の注文を定義できるでしょう。 上の場合では、全部で、上昇か降順でデータを保守できました。
In addition to maintenance of a list in some order, it is possible to define one or more orderings "imposed" on a list. These orderings must be based on the contents of a list's members. This situation is similar to the concept of virtual data (see below) in that the list is not physically maintained in a given order, but retrieved as if it were. Orderings of this type can be dynamically formed (see discussion of set under virtual data). Imposed orderings can be accomplished via the maintenance of auxiliary structures (see discussion under internal representation) or by utilization of a sorting strategy on retrievals. Much work has been done with regard to effective implementation of the maintenance and imposition of orderings on lists. This work is described in working paper number 2.
何らかのオーダーにおける、リストのメインテナンスに加えて、リストに「課された」1つ以上の受注業務を定義するのは可能です。 これらの受注業務をリストのメンバーのコンテンツに基礎づけなければなりません。 この状況はまるでそれがあるかのようにリストが与えられたオーダーで物理的に維持されているのではなく、検索されているという点において仮想データ(以下を見る)の概念と同様です。 ダイナミックにこのタイプの受注業務を形成できます(仮想データの下でセットの議論を見てください)。 補助の構造(内部の表現で議論を見る)のメインテナンスかretrievalsにおけるソーティング戦略の利用で課された受注業務を達成できます。 メインテナンスの有効な実装とリストへの受注業務の賦課に関して多くの仕事をしました。 この仕事は監査調書No.2で説明されます。
3.5 Data Integrity
3.5 データの保全
An important feature of any data management system is the ability to have the system insure the integrity of the data. Data needs to be protected against erroneous manipulation by people and against system failure.
どんなデータ管理システムの重要な特徴もシステムにデータの保全を保障させる能力です。 データは、人々による誤った操作に対してシステム障害に対して保護される必要があります。
Datalanguage will provide automatic validity checks. Many flavors need to be provided so that appropriate trade-offs can be made between the degree of insurance and the cost of validation. The datalanguage user will be able to request constant validation: where validity checks are made whenever the data is updated; validation on access: where validity checks are performed when data is referenced but before it is retrieved; regularly scheduled validation: where the data is checked at regular intervals; background validation: where the system will run checks in its spare time; and validation on demand. Constant validation and validation on access are actually special cases of the more general concept of event triggered validation. In this case the user specifies
Datalanguageは自動バリディティチェックを提供するでしょう。 多くの風味が、保険の度合いと合法化の費用の間で適切なトレードオフをすることができるように提供される必要があります。 datalanguageユーザは一定の合法化を要求できるでしょう: データをアップデートするときはいつも、バリディティチェックが作られているところで。 アクセスの合法化: バリディティチェックがデータが参照をつけられますが、それの前にどこで実行されるかは検索されます。 定期的に予定されている合法化: データが一定の間隔を置いてチェックされるところ。 バックグラウンド合法化: システムが余暇にチェックを実行するところ。 そして、オンデマンドの合法化。 アクセスの一定の合法化と合法化はイベントの引き起こされた合法化の、より一般的な概念の実際に特別なケースです。 この場合、ユーザは指定します。
Winter, Hill & Greiff [Page 26] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[26ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
an event which will cause data validation procedures to be invoked. This feature can be used to accomplish such things as validation following a "batch" of updates. Also, some mechanism for specifying combinations of these types would be useful.
データ合法化手順を呼び出すイベント。 アップデートの「バッチ」に続いて、合法化のようなものを達成するのにこの特徴を使用できます。 また、これらのタイプの組み合わせを指定するための何らかのメカニズムも役に立つでしょう。
In order for some of the data validation techniques to be effective, it may be necessary to keep some data validation "bookkeeping" information with the data. For example, information which can be used to determine whether an item has been checked since it was last updated might be used to cause validation on access if there has not been a recent background validation. The datacomputer may provide for optional automatic maintenance of such special kinds of information.
データ確認技法のいくつかが効果的であるように、データで何らかのデータ合法化が「簿記」情報であることを保つのが必要であるかもしれません。 例えば、最近のバックグラウンド合法化がなかったなら、それをアップデートして以来項目がチェックされているかどうか決定するのに使用できる情報は、アクセスのときに合法化を引き起こすのに使用されるかもしれません。 datacomputerはそのような特別な種類の情報の任意の自動メインテナンスに備えるかもしれません。
In order for the datacomputer system to insure data validity, the user must define what valid is. Two types of validation can be requested. In the first case the user can tell the datacomputer that a specific data item may only assume one of a specific set of values. For example, the color component of a struct may only assume the values 'red', 'green', or 'blue'. The other case is where some relation must hold between members of an aggregate. For example, if the sex component of a struct is 'male' then the number of pregnancies component must be 0.
オーダー、datacomputerシステムが、データの正当性、ユーザが有効な状態でなにかを定義しなければならないかを保障するのは、中です。 2つのタイプの合法化を要求できます。 前者の場合ユーザは、特定のデータ項目が特定の値の1つを仮定するだけであるかもしれないとdatacomputerに言うことができます。 例えば、structの色の成分は、値が'赤い'か、'緑色'、または'青い'と仮定するだけであるかもしれません。 もう片方のケースは何らかの関係が集合のメンバーの間で成立しなければならないところです。 例えば、structのセックスの部品が'男性である'なら、妊娠コンポーネントの数は0であるに違いありません。
Data validation is only half of the data integrity picture. Data integrity involves methods of restoring damaged data. This requires maintenance of redundant information. Features will be provided which will make the datacomputer system responsible for the maintenance of redundant data and possibly even automatic restoration of damaged data. In section 2 we discussed possible uses of the datacomputer for file backup. All features which are provided for this purpose will also be available as methods of maintaining backup information for restoration of files residing at the datacomputer.
データ合法化はデータ保全画像の半分にすぎません。 データの保全は破損しているデータを回復するメソッドにかかわります。 これは余分な情報のメインテナンスを必要とします。 datacomputerシステムを冗長データのメインテナンスとことによると破損しているデータの自動回復にさえ責任があるようにする特徴を提供するでしょう。 セクション2で、私たちはファイルバックアップのためにdatacomputerの可能な用途について議論しました。 また、提供されるすべての特徴がdatacomputerに住んでいるファイルの修復のためのバックアップ情報を維持するメソッドとしてこのために利用可能になるでしょう。
3.6 Privacy
3.6 プライバシー
Datalanguage will have to provide extensive privacy and protection capabilities. In its simplest form a privacy lock is provided at the file level. The lock is opened with a password key. Associated with this key is a set of privileges (reading, updating, etc.). Two degrees of generality are sought. Privacy should be available at all levels of data. Therefore, groups of related data, including groups of files could be made private by creating private directories. Also, specific fields of records could be made private by having private components of a struct where other components of the struct are visible to a wider (or different) class of users. We would also like the user to be able to define his own mechanism. In this way, very personalized, complex, and hence secure mechanisms can be defined. Also features such as 'everyone can see his own salary' might be possible.
Datalanguageは大規模なプライバシーと保護能力を提供しなければならないでしょう。 最も簡単なフォームに、ファイルレベルでプライバシー錠を提供します。 錠はパスワードキーで開けられます。 このキーに関連づけられているのは、1セットの特権(読書、アップデートなど)です。 一般性の2つの度合いが求められます。 プライバシーはすべてのレベルに関するデータで利用可能であるべきです。 したがって、関連するデータのグループであり、個人用の住所録を作成することによって、ファイルのグループを含んでいるのを個人的にすることができるでしょう。 また、より広くて(異なる)のクラスのユーザにとって、structの他の部品が目に見えるstructの個人的な部品を持っていることによって、記録の特定の分野を個人的にすることができるでしょう。 また、ユーザが彼自身のメカニズムを定義したいと思います。 このように、非常に個人化されて、複雑で、したがって、安全なメカニズムを定義できます。 また、'皆は彼自身の給料を見などであることができることなど'の特徴も可能であるかもしれません。
Winter, Hill & Greiff [Page 27] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[27ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
3.7 Conversion
3.7 変換
Many types of data are related in that some or all of the possible values of one type of data have an "obvious" translation to the values of another. For example, the character '6' has a natural translation to the integer 6, or the six character string 'abc ' (three trailing blanks) has a natural translation to the four character string 'abc ' (one trailing blank). Datalanguage will provide conversion capabilities for the standard, commonly called for, translations. These conversions can be explicitly invoked by the user or implicitly invoked when data of one type is needed for an operation but data of another type is provided. In the case of implicit invocation of conversion of data the user will have control over whether conversion takes place for a given data item. More generally we would like to provide a facility whereby the user could specify conditions which determine when an item is to be converted. Also, the user should be able to define his own conversion operations, either for a conversion between types which is not provided by the datacomputer system or to override the standard conversion operation for some or all items of a given type.
1つのタイプに関するデータの可能な値のいくつかかすべてが「明白な」翻訳を別のものの値に持っているので、多くのタイプに関するデータは話されます。 例えば、キャラクタ'6'が整数6に自然な翻訳を持っているか、または6キャラクタストリング'abc'(3回の引きずっている空白)は4キャラクタストリング'abc'(1つの引きずっている空白)に自然な翻訳を持っています。 Datalanguageは翻訳を一般的に求められて、規格のための変換能力に提供するでしょう。 1つのタイプに関するデータを操作に必要とするとき、明らかにこれらの変換をユーザが呼び出すか、またはそれとなく呼び出すことができますが、別のタイプに関するデータを提供します。 データの変換の暗黙の実施の場合では、変換が与えられたデータ項目のために行われるか否かに関係なく、ユーザはコントロールを家に迎えるでしょう。 より一般にユーザが項目がいつ変換されるかことであることを決定する状態を指定できた施設を提供したいと思います。 また、ユーザは、どちらかタイプの間のdatacomputerシステムによって提供されない変換のための彼自身の変換操作を定義するべきであるか、または与えられたタイプのいくつかかすべての項目のための標準の変換操作をくつがえすことができるべきです。
3.8 Virtual and Derived Data
3.8 仮想の、そして、派生しているデータ
Often, information important to users of data is embedded in that data rather than explicitly maintained. For example, the dollar value of an individual's interest in a company in a file of stock holders. Since the value of the company changes frequently, it is not feasible to maintain this information with each record. It is useful to be able to use the file as if information of this type was part of each record. When referencing the dollar value field of a record, the datacomputer system would automatically use information in the record, such as percentage of ownership in the company, possibly in conjunction with information which is not part of the record but is maintained elsewhere, such as company assets, to compute the dollar value. In this way the data user need not be concerned with the fact that this information is not actually maintained in the record.
しばしば、データのユーザにとって、重要な情報は明らかに維持されるよりむしろそのデータに埋め込まれています。 例えば、株主のファイルの会社への個人の関心のドル値。 会社の値が頻繁に変化するので、各記録があるこの情報を保守するのは可能ではありません。 まるでこの種の情報がそれぞれの記録の一部であるかのようにファイルを使用できるのは役に立ちます。 記録のドル値の分野に参照をつけるとき、datacomputerシステムは自動的に記録の情報を使用するでしょう、会社における、所有権の割合などのように、ことによるとドル値を計算するために記録の一部ではありませんが、会社の資産などのようにほかの場所で保守される情報に関連して。 データユーザが必要とするこのように、この情報が実際に記録で保守されないという事実に関係がしないでください。
The _set_, which is a specific type of virtual container in datalanguage, deserves special mention. A set is a virtual list. For example, suppose there is a real list of people representing some population sample. By real (or actual) data we mean data which is physically stored at the datacomputer. A set could be defined to contain all members of this list who are automobile owners. The set concept provides a powerful feature for viewing data as belonging to more than one collection without physical duplication. Sets are also useful, in that, they can be dynamically formed. Given an actual list, sets based on that list can be created without having been previously described.
_セット_(datalanguageの特定のタイプの仮想のコンテナである)は特記に値します。 セットは仮想のリストです。 例えば、何らかの人口のサンプルを表す人々の本当のリストがあると仮定してください。 本当の、そして、(実際)のデータで、私たちはdatacomputerに物理的に保存されるデータを言っています。 自動車所有者であるこのリストのすべてのメンバーを含むようにセットを定義できました。 セット概念は物理的な複製がなければ1つ以上の収集に属すとデータをみなすための強力な特徴を提供します。 また、セットもそれで役に立つ、ダイナミックにそれらを形成できます。 以前に説明されないで、実際のリストを考えて、そのリストに基づくセットは創設できます。
Winter, Hill & Greiff [Page 28] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[28ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
As mentioned above, virtual data can be very economical. These economies may become most important with respect to the use of sets. Savings are found not only in regard to storage requirements, but also in regard to processing efficiency. Processing time can be reduced as a result of calculations being performed only when the data is accessed. The ability to obtain efficient operation by optimization becomes greater when virtual data is defined in terms of other virtual data. For sets, large savings may be realized by straight forward "optimization" of the nested calculations.
以上のように、仮想データは非常に経済的である場合があります。 これらの経済はセットの使用に関して最も重要になるかもしれません。 貯蓄はストレージ要件に関して見つけられるだけではなく、処理効率に関しても見つけられます。 データがアクセスされているときだけ実行される計算の結果、処理時間を短縮できます。 仮想データが他の仮想データで定義されるとき、最適化で効率的な操作を得る能力は、より大きくなります。 セットにおいて、大きい貯蓄は入れ子にされた計算のまっすぐな前進の「最適化」で実現されるかもしれません。
The above ideas are made more clear by example. Having created a set of automobile owners, A, a set of home owners, HA, can be defined based on A. The members of HA can be produced very efficiently, in one step, by retrieving people who are both automobile owners and home owners. This is more efficient than actually producing the set, A and then using it to create HA. This is true when one or both pieces of information (automobile ownership and home ownership) are indexed (see discussion under internal representation) as well as when neither is indexed.
例は上の考えをより明確にします。 自動車所有者、1セットのAを作成したので、A.に基づいて1セットの世帯主(HA)を定義できます。非常に効率的にHAのメンバーを生産できます、ワンステップで、自動車所有者と世帯主の両方である人々を救済することによって。 これは実際にセット、Aを生産して、次に、HAを作成するのにそれを使用するより効率的です。 情報の1か断片の両方がどちらも索引をつけられない時と同様に索引をつけられるとき(自動車所有権と持ち家)(内部の表現で議論を見てください)、これは本当です。
The same gains are achieved when operations on virtual data are requested. For example, if a set, H, had been defined as the set of homeowners based on the original list of people, the set, HA, could have been defined as the intersection (see discussion on operators) of A and H. In this case too, HA can be calculated in one step. Use of sets allows the user to request data manipulations in a form close to his conceptual view, leaving the problem of effective processing of his request to the datacomputer.
仮想データにおける操作が要求されているとき、同じ利得は獲得されます。 例えば、セット(H)が人々のオリジナルのリストに基づくマイホーム所有者のセットと定義されたなら、AとH.In本件についても交差点(オペレータについての議論を見る)とセット(HA)を定義できるだろうにて、ワンステップでHAについて計算できます。 ユーザは彼の概念視点の近くでフォームでセットの使用からデータ操作を要求できます、彼の要求の有効な処理の問題をdatacomputerに残して。
Another use of virtual data is to accomplish data sharing. An item could be defined, virtually, as the contents of another item. If no restriction is placed on what this item can be, we have the ability to define two paths of access to the same data. Hence, data can be made subordinate to two or more aggregate structures. Stated another way, there are two or more paths of access to the data. This capability can be used to model data which is part of more than one data relationship. For example, two files could have the same records without maintaining duplicate copies.
仮想データの別の使用はデータ共有を達成することです。 実際には別口のコンテンツと項目を定義できました。 制限が全くこの項目が何であるかもしれないかに関して課されないなら、私たちには、同じデータへのアクセスの2つの経路を定義する能力があります。 したがって、データを2つ以上の団粒構造に下位にすることができます。 別の道に述べられていて、データへのアクセスの2つ以上の経路があります。 1つ以上のデータ関係の一部であるデータをモデル化するのにこの能力を使用できます。 例えば、2個のファイルには、写本を維持しないで、同じ記録があるかもしれません。
It will also be possible, via data sharing to look at data in different ways. Shared data might behave differently depending on how (and ultimately by whom) it is accessed. Although, the ability to have multiple paths to the same data and the ability to have data which is calculated on access are both part of the general virtual data capability, datalanguage will probably provide these as separate features, since they have different usage characteristics.
また、データ共有を通して、異なった方法でデータを見るのも可能でしょう。 力が異なってよりながら振る舞わせるデータを共有する、どのように、(結局、だれ、)、それはアクセスされているか。 同じデータに複数の経路を持つ能力とアクセスのときに計算されているのが、両方であるということであるデータを持つ能力は一般的な仮想データ能力を離れさせます、とdatalanguageがたぶん別々の特徴としてこれらを前提とするでしょう、それらには異なった用法の特性があるので。
Derived data is similar to virtual data in that it is redundant data which can be calculated from other information. Unlike virtual data it
派生しているデータはそれが他の情報から計算できる冗長データであるという点において仮想データと同様です。 仮想データ、それ
Winter, Hill & Greiff [Page 29] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[29ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
is physically maintained. The user can choose between virtual and derived data as a result of considering trade-offs based on: estimated cost of calculation; frequency of update; estimated cost of storage; and frequency of access. For example, suppose a file contains a list of budgets for various projects in a department. The departmental budget can be calculated as a function of the individual project budgets. This information might be defined as derived data since it is expected to be updated infrequently (e.g., once a year), while it is expected to be accessed relatively often.
物理的に維持されます。 ユーザは以下に基づいてトレードオフを考えることの結果、仮想の、そして、派生しているデータを選ぶことができます。 計算の予算。 アップデートの頻度。 ストレージの予算。 そして、アクセサリーの頻度 例えば、ファイルが部に様々なプロジェクトのための予算のリストを保管していると仮定してください。 独特のプロジェクト予算の機能として部門別予算を計算できます。 まれに(例えば、かつての1年)アップデートすると予想されて、この情報は派生しているデータと定義されるかもしれません、比較的しばしばアクセスされると予想されますが。
Options will be provided which give the user control with regard to when the calculation of derived data is to be done. These options will be similar to those provided for control of data validity operations. The data validation and derived data concepts are similar in that some operation must be performed on related data. In the case of data validation, the information derived is the condition of data.
される派生しているデータの計算がことである時に関してユーザ支配力を与えるオプションを提供するでしょう。 これらのオプションはデータ正当性操作のコントロールに提供されたものと同様になるでしょう。 データ合法化と派生しているデータ概念は関連するデータに何らかの操作を実行しなければならないという点において同様です。 データ合法化の場合では、引き出された情報はデータの状態です。
3.9 Internal Representation
3.9 内部の表現
To this point, we have discussed only the high level, logical, aspects of data. Since data, at any given time, must reside on some physical device a representation of the data must be chosen. In some cases it is appropriate to leave this choice to the datacomputer system. For example, the representation of information which is used in the process of transmitting other data, but which itself resides solely at the datacomputer may not be of any concern to the user.
この位まで、私たちはデータの高い平らで、論理的な局面だけについて議論しました。 データがその時々でいくらかのフィジカル・デバイスになければならないので、データの表現を選ばなければなりません。 いくつかの場合、この選択をdatacomputerシステムに残すのは適切です。 例えば、他のデータを送ることの途中に使用されますが、唯一datacomputerに住んでいる情報自体の表現はそうではありません。ユーザへのどんな関心についても。
However, it is important that the user be capable of controlling the choice of representation. In any application which requires mostly transmission of data rather than interpretation of the data by the datacomputer, the data should be maintained in a form consistent with the system which communicates with the datacomputer. With respect to basic types of data, datalanguage will provide most representations commonly used in systems with which it interacts. For some types (e.g., fixed point) this will be accomplished by providing for parametric (e.g., sign convention, size) description of the representation. In other cases (e.g., floating point) specific representations will be offered (e.g., system 360 short floating point, system 360 long floating point, pdp-10 floating point, etc.).
しかしながら、ユーザが表現の選択を制御できるのは、重要です。 ほとんどdatacomputerによるデータの解釈よりむしろデータの伝達を必要とするどんなアプリケーションでも、データはdatacomputerとコミュニケートするシステムと一致したフォームで保守されるべきです。 基本型のデータに関して、datalanguageはそれが相互作用するシステムで一般的に使用されるほとんどの表現を提供するでしょう。 何人かのタイプ(例えば、定点)において、これは、表現のパラメトリック(例えば、コンベンションに署名してください、サイズ)記述に備えることによって、達成されるでしょう。 中に、他のケース(例えば、浮動小数点)の特定の表現を提供するでしょう(例えば、システム360の短い浮動小数点、システム360は浮動小数点を切望して、pdp-10は浮動小数点ですなど)。
Another aspect of the internal representation problem regards aggregate structures. The method chosen to represent aggregate structures may largely affect the cost of manipulating the data. The user must have control over this representation since only he has any idea of how the data is to be used. Datalanguage will provide a variety of representational options which will allow for efficient implementation of data structures. This includes the availability of auxiliary
集合が構造化する内部の表現問題あいさつのもう一つの側面。 団粒構造を表すために選ばれたメソッドはデータを操る費用に主に影響するかもしれません。 彼だけにはどう使用されているかに関するデータがことであるどんな考えもあるので、ユーザはこの表現を管理しなければなりません。 Datalanguageはデータ構造の効率的な実装を考慮するさまざまな具象主義のオプションを提供するでしょう。 これは補助物の有用性を含んでいます。
Winter, Hill & Greiff [Page 30] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[30ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
structures, automatically maintained by the data computer system. These structures can be used to effect efficient retrieval of subsets of data collections based on the contents of the members (i.e. the common concept of indices), efficient maintenance of orderings on a collection of data, maintenance of redundant information for the purpose of data integrity, and efficient handling of shared data whose behavioral characteristics are dependent on the path of access. It should be noted here that, the datalanguage design effort, will attempt to provide methods whereby the data user can describe the expected use of his data, so that details of internal representation can be left to the datacomputer.
データコンピュータ・システムによって自動的に維持された構造。 データ収集の部分集合の効率的な検索がメンバー(すなわち、インデックスリストの一般的な概念)のコンテンツ、データの収集の受注業務の効率的なメインテナンス、データ保全の目的のための余分な情報のメインテナンス、および共有データの行動の特性がアクセサリーの経路に依存している効率的な取り扱いに基礎づけた効果にこれらの構造を使用できます。 ここにdatalanguageデザイン取り組み、データユーザが彼のデータの予想された使用について説明できるメソッドを提供するのを試みると述べられるべきです、内部の表現の詳細をdatacomputerに残すことができるように。
3.10 Data Attributes and Data Classes
3.10のデータ属性とデータが属します。
The type of an item determines the operations which are valid on that item and what they mean. _Data_attributes_ are refinements on the type of data. The data attributes affect the meaning of operations. For example, we would like to provide for the option of defining fixed point items to be scaled. The scale factor, in this case, would be an attribute of fixed point data. It effects the meaning of operations on that data. The attribute concept is useful in that it allows information concerning the manipulation of an item to be associated with the item rather than with the invocation of all operations on that item.
項目のタイプはその項目で有効な操作と彼らが意味することを決定します。 _データ_属性_はデータのタイプにおける気品です。 データ属性は操作の意味に影響します。 例えば、スケーリングされるために固定小数点項目を定義するオプションに備えたいと思います。 この場合位取り因数は定点データの属性でしょう。 それはそのデータで操作の意味に作用します。 項目の操作の情報がその項目におけるすべての操作の実施でというよりむしろ項目に関連しているのを許容するので、属性概念は役に立ちます。
The attribute concept can be applied to aggregate as well as basic data. For example, one attribute of a list could define where a new member is to be inserted. Options might be: insert at the beginning of the list; insert at the end of the list; or insert in some order based on the contents of the member. Adding a new member to a list with one of the above attributes could be done by issuing a simple insert request without having to specify where the new member is to be inserted.
基礎データと同様に集めるために属性概念を適用できます。 例えば、リストの1つの属性が、新しいメンバーがどこに挿入されることになっているかを定義するかもしれません。 オプションは以下の通りです。 リストの始めの差し込み。 リストの終わりの差し込み。 または、何らかのオーダーにおける差し込みはメンバーのコンテンツを基礎づけました。 上の属性の1つで新しいメンバーがどこに挿入されることになっているかを指定する必要はなくて簡単な差し込み要求を出すことによって、新しいメンバーをリストに追加できるでしょう。
The _data_class_ concept is actually the inverse of the data attribute concept. A data class is a collection of data types. The data class concept allows for definition of operations, independent of specific type of an item. For example, by defining the data class arithmetic to be composed of fixed point and floating point types of data, the comparison operators (_equal_, _less_than_, etc.) can be defined to operate on arithmetic data, independent of whether it is fixed or floating point. Also the concept of data aggregate can be seen as a class encompassing directories, lists, etc. As there are operations defined on arithmetic data, there are also operations defined on arbitrary aggregates.
_データ_クラス_概念は実際にデータ属性概念の逆です。 データのクラスはデータ型の収集です。 データクラス概念は項目の特定のタイプの如何にかかわらず操作の定義を考慮します。 例えば、データの定点と浮動小数点タイプで構成されるためにデータクラス演算を定義することによって、それが固定されているかどうかの如何にかかわらず算術データか浮動小数点を作動させるために、比較オペレータ(__等しい_、_より少ない_など)を定義できます。 また、データ集合体の概念をディレクトリ、リストなどを取り囲むクラスと考えることができます。 算術データで定義された操作があるとき、任意の集合で定義された操作もあります。
The inverse relationship between data classes and data attributes is very strong. For example, the concept of list can be seen as a data class, encompassing all types of lists (e.g., lists of integers, lists
データのクラスとデータ属性との逆さの関係は非常に強いです。 例えば、リストの概念をデータのクラスと考えることができます、すべてのタイプのリストを包含して(例えば、整数のリスト、リスト
Winter, Hill & Greiff [Page 31] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[31ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
of character strings, etc.), independent of the types of their members. The type of a list's members (e.g., integer, character string, etc.) are then seen as attributes. Data attributes and classes are also relative concepts. While the concept of list can be viewed as a data class, it can also be seen as an attribute, relative to the concept of data aggregate.
文字列など) 彼らのメンバーのタイプから、独立しています。 そして、リストのメンバー(例えば、整数、文字列など)のタイプは属性と考えられます。 また、データ属性とクラスは相対概念です。 また、データのクラスとしてリストの概念を見なすことができる間、それを属性と考えることができます、データ集合体の概念に比例して。
3.11 Data Description
3.11 データ記述
A _data_description_ is a statement of the properties (see discussion of attributes) of a data item. Examples of properties which are recorded in a description are: the name of an item; its size; its data type; its internal representation; privacy information; etc.
_データ_記述_はデータ項目の特性(属性の議論を見る)の声明です。 記述に記録される特性に関する例は以下の通りです。 項目の名前。 サイズ。 データ型。 内部の表現。 プライバシー情報。 など
Datalanguage will contain mechanisms for specifying data descriptions. These descriptions will be processed by the data computer, and used whenever the data item is referenced. The user will be able to physically create data only by first specifying their descriptions. The properties of a description can be divided into groups according to their function. Some have the function of specifying details of representation, which will not be of interest to most users, while others, such as the name are of almost universal interest.
Datalanguageはデータ記述を指定するためのメカニズムを含むでしょう。 データ項目が参照をつけられるときはいつも、これらの記述は、データコンピュータによって処理されて、使用されるでしょう。 ユーザは、彼らの記述を指定しながら、最初にだけで物理的にデータを作成できるでしょう。 それらの機能に応じて、記述の特性をグループに分割できます。 或るものには、ほとんどのユーザにとって興味深くならない表現の詳細を指定する機能があります、名前などの他のものはほとんど普遍的におもしろいのですが。
All user data is a part of some larger (user or system) data structure. The structures containing data establish a path of access to the data. In the process of following this path the datacomputer system must accrue a complete description of the data item. For example, the description of a data item of a directory may be found associated with that node of the directory. Members of a list or array are described as part of the description of the list or array. We must dispose of two seeming exceptions. First, while aspects of data may (on user request) be left to the system, those aspects are still described, they are described by the system. As discussed above, some data will be, to some degree, self describing (e.g. members of mixed lists). However, it is fully described in some encompassing structure, in that a method of determining the full description is described.
すべての利用者データが何らかのより大きい(ユーザかシステム)データ構造の一部です。 データを含む構造はデータへのアクセスの経路を確立します。 この経路に続くことの途中に、datacomputerシステムはデータ項目の完全な記述を生じさせなければなりません。 例えば、ディレクトリのデータ項目の記述がディレクトリのそのノードに関連しているのがわかるかもしれません。 リストか配列のメンバーはリストか配列の記述の一部として記述されています。 私たちは例外に見える2を処分しなければなりません。 データの局面が左では、システムに、それらの局面がまだ説明されているということであるかもしれない(ユーザ要求に関して)間、まず最初に、それらはシステムによって説明されます。 上で議論するように、いくつかのデータが(例えば、複雑なリストのメンバー)について説明するある程度自己になるでしょう。 しかしながら、余すところのない解説を決定するメソッドが説明されるので、それは何らかの取り囲む構造で完全に説明されます。
It is worth noting here that the sooner a complete description is found in the path of access, the more effective the datacomputer is likely to be in processing requests which manipulate a data item. However, the ability to have data whose complete description does not exist at high levels of the access path provides greater flexibility in the definition of data structures.
ここで完全な記述がアクセスの経路で、より早く見つけられれば見つけるほど、datacomputerはデータ項目を操る処理要求におそらくあるのが、より効果的であることに注意する価値があります。 しかしながら、完全な記述がアクセス経路の高いレベルで存在しないデータを持つ能力は、より大きい柔軟性をデータ構造の定義に提供します。
Winter, Hill & Greiff [Page 32] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[32ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
3.12 Data Reference
3.12 データ参照
Data cannot be manipulated unless it can be referenced. In the same way that data cannot exist without its being described, it cannot exist unless there is a path of access to the data. The method of data reference is to define the path of access to the data. As mentioned above, there is a method of referencing any item relative to the data aggregate which contains it. Nodes of directories and components of structs are referenced via the name associated with the node or component. Members of arrays are referenced via the index associated with the member. Members of lists are referenced via some method of specifying the position of the member or by uniquely identifying the member by content. To reference any arbitrary data item the path of access must be fully defined by either explicit or implicit definition of each link in the chain. In the case of virtual data there is an extra implicit link in the chain, that being the method employed to obtain the data from other data items. It should be noted also that if pointers are provided (see discussion on general relational capabilities) they can also serve as a link in the chain of access to an item.
それに参照をつけることができないなら、データを操ることができません。 同様に、そのデータは存在なしで説明されていた状態で存在できないで、データへのアクセスの経路がない場合、それは存在できません。 データ参照のメソッドはデータへのアクセスの経路を定義することです。 以上のように、それを含むデータ集合体に比例してどんな項目にも参照をつけるメソッドがあります。 ノードかコンポーネントに関連している名前でディレクトリのノードとstructsの部品は参照をつけられます。 メンバーに関連しているインデックスで配列のメンバーは参照をつけられます。 内容でメンバーの地位を指定する何らかのメソッドで唯一メンバーを特定することによって、リストのメンバーは参照をつけられます。 参照に、完全に定義されていて、アクセスの経路がそうしなければならないどんな任意のデータ項目もチェーンでそれぞれの明白であるか暗黙の定義でリンクされます。 仮想データの場合には、チェーンに付加的な内在しているリンクがあります、それが他のデータ項目からデータを得るのに使われたメソッドであることで。また、また、指針を提供するなら(一般的な関係能力についての議論を見てください)リンクとして項目へのアクセスのチェーンで機能できることに注意されるべきです。
The design of datalanguage will ease the problem (and reduce the cost) of referencing data items by providing methods whereby part of the access path can be implicitly defined. For example, datalanguage will provide a concept of "context". During the course of interacting with the datacomputer, levels of context can be set up so that data can be referenced directly, in context. For example, on initiating a session the user may (in fact will probably be required to) define a directory which will be the context of that session. All items subordinate to this directory can be referenced directly in this context. Another feature will be partial qualification. Each level of struct need not be mentioned in order to reference an item embedded in a deep nest of structs. Only those intermediate levels which are sufficient to uniquely identify the item need be specified.
datalanguageのデザインはそれとなくアクセス経路の一部を定義できるメソッドを提供することによってデータ項目に参照をつける問題(生産費を切り下げる)を緩和するでしょう。 例えば、datalanguageは「文脈」の概念を提供するでしょう。 datacomputerと対話するコースの間、直接データに参照をつけることができるように文脈のレベルをセットアップできます、状況内において。 例えば、セッションを開始するとき、ユーザはそのセッションの文脈になるディレクトリを定義するかもしれません(事実上、たぶん、必要でしょう)。 直接このような関係においてはこのディレクトリへの下位のすべての項目に参照をつけることができます。 別の特徴は部分的な資格になるでしょう。 structの各レベルは、structsの深い巣に埋め込まれた項目に参照をつけるために言及される必要はありません。 それらの唯一項目を特定するために十分な中間的レベルだけが指定されなければなりません。
3.13 Operations
3.13 操作
In this section we discuss the builtin functions of datalanguage which are of central importance in manipulating data. Functions which operate on items, functions which operate on aggregates, primitive functions and high-level functions are discussed.
このセクションで、私たちはdatalanguageのデータを操作するのにおいて中央に重要な作り付けの機能について議論します。 項目を作動させる機能、集合を作動させる機能、原始関数、およびハイレベルの機能について議論します。
Of the primitives which operate on items, those of most interest are assignment, comparisons, logicals, arithmetics and conversion functions.
項目を作動させる基関数では、ほとんどの関心のものは、課題と、比較と、logicalsと、演算と変換機能です。
Primitive assignment transfers a value from one item to another; these items must be of the same type. When they are of different types,
原始の課題は1つの項目からもう1つの項目まで値を移します。 同じタイプにはこれらの項目があるに違いありません。 それらが異なることのいつかがタイプされます。
Winter, Hill & Greiff [Page 33] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[33ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
either conversion must be performed, or some non-primitive form of assignment is involved.
変換を実行しなければならない、さもなければ、何らかの非原始の形式の課題はかかわります。
The comparison operators accept a pair of items of the same type, and return a boolean object which indicates whether or not a given condition obtains. The type determines how many different conditions can be compared for. A pair of numeric items can be compared to see which is greater, while a pair of uninterpreted items can be compared only for equality. In general, a concept of "greater than" is builtin for a datatype only if it is a very widely applied concept. The comparison operators are used in the construction of inclusion conditions when defining subsets of aggregate data.
比較オペレータが1組の同じタイプの商品を受け入れて、論理演算子オブジェクトを返す、どれ、表示、当然のことの状態は得るか。 タイプは、いくつにおいて異なった状態を比較できるかを決心しています。 どちらが、よりすばらしいかを確認するために1組の数字項目を比較できます、1組の非解釈された項目は平等のためだけに比べることができますが。 一般に、aがコンセプト化する、「すばらしさ、」、データ型式において、それが非常に広く適用された概念である場合にだけ作り付けです。 集合体データの部分集合を定義するとき、比較オペレータは包含状態の構造に使用されます。
The result of a comparison operation is a boolean item: one whose value is either TRUE or FALSE. Logical primitives are provided and generalized boolean functions can be constructed from them. With logical and comparison operators, complex conditions for inclusion of objects in sets can be specified.
比較操作の結果は論理演算子項目です: 値がTRUEかFALSEのどちらかであるもの。 論理的な基関数を提供します、そして、それらから一般化された論理演算子機能を構成できます。 論理的、そして、比較オペレータと共に、セットでのオブジェクトの包含のための複合条件を指定できます。
Arithmetic operators will be available for the manipulation of numeric data. Here, we are not interested in generalized computation, but in applications of arithmetic in data selection, space allocation, subscript calculation, iteration control, etc.
算術演算子は数値データの操作に利用可能になるでしょう。 ここで、私たちは一般化された計算に関心があるのではなく、データ選択、スペース割当て、添字計算、繰り返しコントロールなどにおける、演算の応用で興味を持っています。
Conversion is an important part of generalized data translation, and we are interested in providing a substantial builtin conversion facility. In particular, we will want to provide an efficient system routine for each "standard" or widely-used conversion function. Of particular importance are conversions to and from character string data; in character string representation of, for example, numeric items, there are many possible formats corresponding to a single data type. Conversion between character sets and dealing with padding and truncation are viewed as conversion problems.
変換は一般化されたデータ変換の重要な部分です、そして、かなりの作り付けの変換施設を提供したいと思います。 特に、それぞれの「標準」の、または、広く使用された変換機能に効率的なシステムルーチンを提供したいと思うでしょう。 特別の重要性は列データとキャラクタ列データからの変換です。 例えば、数字項目の文字列表現には、ただ一つのデータ型に対応する多くの可能な形式があります。 文字集合の間の変換、詰め物に対処して、およびトランケーションは変換問題として見なされます。
There are two principal classes of primitive operators defined on aggregates: those related to data reference (see previous section) and those which add and delete components. Changing an existing component is accomplished through assignment, and is an operation on the component, not the aggregate.
集合で定義された2つの主要なクラスの原始のオペレータがいます: ものはデータ参照(前項を見る)とコンポーネントを加えて、削除するものに関連しました。 既存のコンポーネントを変えるのは、課題で達成されて、集合ではなく、コンポーネントにおける操作です。
Addition and deletion of components is defined only for aggregates which are not inherently static in composition. Thus one can add a component to a LIST, but not to an ARRAY. To specify deletion it is necessary to specify which component is to be deleted, and from which aggregate (in the case that it is shared). Addition requires specification of new component, aggregate, and sometimes auxiliary information. For example, some aggregate types would permit addition of new components anywhere in the structure; in these a position must be indicated, relative to any
コンポーネントの追加と削除は本来構成で静的でない集合のためだけに定義されます。 したがって、1は、LISTにコンポーネントを加えますが、ARRAYに加えることができません。 削除を指定するために、どのコンポーネントが削除されるかことであるかと指定して、どの集合から必要であるかが必要です(それが共有されて)。 追加は新しいコンポーネントの仕様、集合の、そして、時々補助の情報を必要とします。 例えば、何人かの集成型が構造でどこでも新しいコンポーネントの追加を可能にするでしょう。 いずれもに比例してこれらの位置を示さなければなりません。
Winter, Hill & Greiff [Page 34] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[34ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
existing components.
既存のコンポーネント。
Often it is desirable to operate on some of the members of a list, or to treat a group of members as a list in its own right. For example, it might be common to transmit to a remote program for analysis, the medical history of patients developing heart disease before the age of 30. These may be just a few of the members of a large list of patients.
しばしば、リストの何人かのメンバーを手術するか、またはそれ自体でメンバーのグループをリストとして扱うのが望ましいです。 例えば、分析のためのリモートプログラムに伝わるのは一般的であるかもしれません、患者が30歳前に心臓病を発生する医学史。 これらはただ大きい患者名簿のメンバーのいくつかであるかもしれません。
In this case, the operation to be performed is transmission to the remote system; this operation is performed on several members of the list of patients. The ones to be transmitted are thought of as a _set_; the set is specified as containing all the members of a given list satisfying two conditions: (1) age less than 30, and (2) has heart disease.
この場合、実行されるべき操作はリモートシステムへのトランスミッションです。 この操作は患者名簿の数人のメンバーに実行されます。 伝えられるべきものは_セット_として考えられます。 セットは2つの状態を満たす与えられたリストのすべてのメンバーを含むと指定されます: (1) 30ほど年をとらないでください。そうすれば、(2)は心臓病にかかっています。
Sets can be defined explicitly, or implicitly simply with appropriate reference mechanisms. _Definition_ of a set is distinct from _identification_of_membership_, which is distinct from _access_to_membership_. Definition involves specifying the candidates for set membership and specifying a rule by which members of the set can be distinguished from non-members; for example, an inclusion condition such as "under 30 with heart disease". Identification involves effective application of the rule to all candidates for membership. When the membership has been identified, it can be counted, but the data itself has not necessarily been accessed. When a member is accessed, its contents can be operated on.
明らかにセットを定義できますか、または適切な参照メカニズム_単にDefinitionについて、それとなく、1セットの_は__会員資格_の識別_と異なっています。定義は、セット会員資格の候補を指定して、非会員とセットのメンバーを区別できる規則を指定することを伴います。_は_アクセス_から_会員資格_まで異なっています。 例えば、「心臓病に伴う30未満」などの包含状態。 識別は規則の有効な適用に会員資格のすべての候補にかかわります。 会員資格が特定されたとき、それを数えることができましたが、データ自体は必ずアクセスされるというわけではありませんでした。 メンバーがアクセスされているとき、コンテンツでは、作動できます。
Primitives to accomplish each of these operations on a set will be provided; however, it will ordinarily be optimal for the datacomputer to determine when each step should be performed. To enable users to operate at a level at which the datacomputer can optimize effectively, higher-level operators on sets will be provided. Some of these are logical operators, such as union and intersection. These input and output sets. Also available is an operator which complements a set (since the definition establishes all possible candidates, a set always has a well-defined complement).
セットでそれぞれのこれらの操作を実行する基関数を提供するでしょう。 しかしながら、通常、datacomputerが、各ステップがいつ実行されるべきであるかを決定するのは、最適でしょう。 ユーザがdatacomputerが有効に最適化されることができるレベルで働いているのを可能にするために、セットの、よりハイレベルのオペレータを提供するでしょう。 これらのいくつかが組合や交差点などの論理演算子です。 これらはセットを入出力します。 また、利用可能であるのは、セットの補足となるオペレータ(定義がすべての可能な候補を確立するので、セットに、明確な補数がいつもある)です。
These higher level operators can be applied to any defined set; the set members need not be identified or accessed. The system will perform such operations without actually accessing members if it can.
これらのより高い平らなオペレータをどんな定義されたセットにも適用できます。 セットメンバーは、特定される必要はありませんし、またアクセスされる必要はありません。 実際にメンバーにアクセスしないで、実行できると、システムはそのような操作を実行するでしょう。
Some of the other operators on sets are counting membership, partitioning a set into a set of sets, uniting a set of sets into a set. A set can be used to reference another set, providing there is a well- defined way to identify members of the second set given the first set. For example, a set C may contain all the children doing poorly in school. A set F may be defined, where the members of F are the records about families having a child in set C.
セットの何人かの他のオペレータが会員資格を数えています、1セットのセットにセットを仕切って、1セットのセットをセットと結合させて。 セットは別のものが設定した参照に慣れることができます、第一セットを考えて、2番目のセットのメンバーを特定するよく定義された方法があれば。 例えば、セットCは学校にすべての子供を不十分に保管するかもしれません。 セットF(セットCに子供がいるファミリーに関して、Fのメンバーは記録です)は定義されるかもしれません。
Winter, Hill & Greiff [Page 35] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[35ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
Some other useful operations on sets are: adding all the members of a set to an aggregate, deleting all the members of a set (frequently such a massive change can be performed far more efficiently than the same set of changes individually requested), changing all the members of a set in a given way.
セットにおけるある他の役に立つ操作は以下の通りです。 与えられた方法で1セットのすべてのメンバーを変えて、1セット(頻繁に、個別に要求された同じセットの変化よりはるかに効率的にそのような大規模な変化を実行できる)のすべてのメンバーを削除して、1セットのすべてのメンバーを集合に追加します。
A set can be made into a list, by actually accessing each member and physically collecting them.
実際に各メンバーにアクセスして、物理的にそれらを集めることによって、セットをリストの中にすることができます。
Some of the operations on lists are: concatenation of lists into larger lists, division of a list into smaller lists, sorting a list, merging a pair of ordered lists (preserving order).
リストにおける操作のいくつかは以下の通りです。 より大きいことへのリストの連結は記載します、より小さいリストの中へのリストの分割、リストを分類して、1組の規則正しいリストを合併して(オーダーを保存して)。
This is not intended to be a full enumeration of high-level operations, but to be suggestive. We are planning to build in high-level functions for operations which are used very commonly, and can be implemented within the system significantly better than they can be implemented by users in the language. For most of the functions mentioned here, considerable knowledge is accumulated on good implementations. In particular, the techniques used for inverted file access provide many set operations to be performed without actual access to the data.
ハイレベルの操作の完全な列挙であることを意図するのではなく、これは、思わせ振りになるように意図します。 私たちは、非常に一般的に使用される操作のためにハイレベルの機能で建てるのを計画していて、言語のユーザがそれらを実装することができるよりかなり良いシステムの中で実装することができます。 ここに言及された機能の大部分において、かなりの知識が良い実装に蓄積されます。 特に、転置ファイルアクセスに使用されるテクニックは、実際のデータへのアクセスなしで実行されるために多くの集合演算を提供します。
3.14 Control
3.14 コントロール
The control features of datalanguage are to the basic operations as data aggregates are to the basic data items. Control features are used to create complex requests out of the basic requests provided by datalanguage.
基礎データ項目にはデータ集合体があるように基本的な操作にはdatalanguageのコントロール機能があります。コントロール機能は、datalanguageによって提供された基本の要求から複雑な要求を作成するのに使用されます。
Conditional requests allow the user to alter the normal request flow by specifying that certain requests are to be executed under certain conditions. In general datalanguage will provide the ability to chose at most one of a number of requests to be made based on some set of conditions or the value of some item. In its simplest form the conditional allows for optional execution of a given request.
条件付き要求で、ある要求が一定の条件の下で実行されることであると指定することによって、ユーザは正常な要求流動を変更できます。 一般に、意志が能力を供給するdatalanguageは何らかのセットの状態か何らかの項目の値に基づいて作られているという多くの要求の1つを高々選びました。 最も簡単なフォームでは、条件付きは与えられた要求の任意の実行を考慮します。
Iterative requests cause a request (called the body) to be executed a fixed or variable number of times or until a given condition is met. Datalanguage will provide iterative requests that will allow for similar manipulations to be performed on all members of some aggregate structure as well as the standard type of iterative request based on counters. By providing a capability of directly expressing manipulations on aggregates which require processing all of the items subordinate to the aggregate, the datacomputer can be more efficient in processing user requests. For example, a user defined conversion process which operates on character strings, can be implemented far more efficiently if the datacomputer is explicitly informed that the process requires sequential
繰り返しの要求は修理されたか可変な回数か与えられた状態まで実行されるのが会われるという要求(ボディーと呼ばれる)を引き起こします。 Datalanguageは同様の操作がカウンタに基づく繰り返しの要求の標準体型と同様に何らかの団粒構造のすべての部材に実行されるのを許容する繰り返しの要求を提供するでしょう。 すべてを処理するのを集合への下位の項目を要求する集合で直接操作を言い表す能力を提供することによって、処理ユーザ要求では、datacomputerは、より効率的である場合があります。 datacomputerが明らかに知らされるならはるかに効率的に例えば文字列を作動させるユーザの定義された変換プロセスは実装することができる、プロセスが必要である、連続する。
Winter, Hill & Greiff [Page 36] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[36ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
processing of the characters. Datalanguage will also provide for parallel iteration. For example, the user will be able to specify operations which require sequencing through two or more lists in parallel. This would be done if the contents of one file were to be updated based on a file of correction information.
キャラクタの処理。 また、Datalanguageは平行な繰り返しに備えるでしょう。 例えば、ユーザは平行な2つ以上のリストを通して配列するのを必要とする操作を指定できるでしょう。 1個のファイルのコンテンツが修正情報のファイルに基づいてアップデートすることであるならこれをします。
Compound requests are collections of requests which act as one. They are primarily provided to allow for the conditional performance of or iteration on more than one statement. Compound requests also provide request reference points which can be used to control the request processing flow. That is, compound requests can be "named". The datalanguage user will be able to specify control information which will conditionally cause a compound request to be exited. By providing naming, the user may cause any number of previously entered compound requests to be exited.
合成要求は1として機能する要求の収集です。 1つ以上の声明における条件付きの性能か繰り返しを考慮するために主としてそれらを提供します。 また、合成要求は要求処理流動を制御するのに使用できる要求基準点を提供します。 すなわち、合成要求を「命名できます」。 datalanguageユーザは条件付きに、出られるという合成要求を引き起こす制御情報を指定できるでしょう。 命名を提供することによって、ユーザは出られるといういろいろな以前に入力された合成要求を引き起こすかもしれません。
We do not intend to provide the traditional _goto_ capability. By not including a goto request, the chances for efficient operation (via optimization) of the datacomputer are increased. We also hope, in this way, to force the datalanguage user to specify his data manipulations in a clear sty1e.
私たちは伝統的な_goto_能力を提供しないつもりです。 goto要求を含んでいないことによって、datacomputerの効率的な操作(最適化を通した)のための可能性は増強されます。 また、私たちは、datalanguageユーザに明確なsty1eで彼のデータ操作を指定させることをこのように望んでいます。
Two forms of the compound request will be provided, ordered and unordered. In the unordered case the user is informing the datacomputer that the requests can be performed in any order. This should allow the datacomputer to perform more efficiently and might even allow for parallel processing.
合成要求の2つのフォームが、提供していて、注文していて順不同のであるなるでしょう。 順不同の場合では、ユーザは、順不同に要求を実行できることをdatacomputerに知らせています。 これは、datacomputerが、より効率的に働くのを許容するべきであり、並列処理を考慮さえするかもしれません。
During a session with the datacomputer it is likely that a user will find a need for temporary data. That is, data which is used to remember, for a short term, information which is needed for the processing of requests. This short term might be a session or a small part of a session. Datalanguage will provide a temporary data facility. Temporary data will be easy to create, use and dispose of. This will be accomplished by allowing the system to (optionally) make many decisions regarding the data. For example the representation of a temporary integer item will often be of no concern to the user. Some features which are provided for permanent data will be deemed irrelevant with regard to temporary data.
datacomputerとのセッションの間、ユーザは一時的なデータの必要性を見つけそうでしょう。 すなわち、短期間(要求の処理に必要である情報)覚えているのに使用されるデータ。 この短期間は、セッションのセッションか小さい部分であるかもしれません。 Datalanguageは一時的なデータ施設を提供するでしょう。 一時的なデータは作成して、使用して、処分しやすいようになるでしょう。 システムが(任意に)データに関する多くの決定をするのを許容することによって、これは達成されるでしょう。 例えば一時的な整数項目の表現はしばしばユーザへの関心の全くものになるというわけではないでしょう。 永久的なデータに提供されるいくつかの特徴が一時的なデータに関して無関係であると考えられるでしょう。
Temporary data will be associated with a collection of requests in what will be called a block. A block will be no different than a compound request with the exception that data is defined with the requests which compose it and is automatically created on entrance to the block and destroyed on exiting the block.
一時的なデータはブロックと呼ばれるものにおける、要求の収集に関連するでしょう。 ブロックはデータがそれを構成する要求で定義されて、入り口で自動的にブロックに作成されて、ブロックを出るとき無効にされるという例外がある合成要求と異ならないでしょう。
Winter, Hill & Greiff [Page 37] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[37ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
3.15 Extensibility
3.15 伸展性
The goals of datalanguage are to provide facilities of data structure at two levels. At one level the user may take advantage of high level data capabilities which will do much of his data management work automatically and which allows for the data computer to operate more effectively in some cases since it has been given control of the data. At another level, however, features are provided which allow the user to describe his application in terms of primitive concepts. In this way the datacomputer user may compose a large variety of data constructs and has great flexibility with respect to the manipulations he can perform on his data. Also by interacting with the datacomputer at the primitive level, the user can exercise a good deal of control over the methods employed by the datacomputer which may result in more effective usage of resources for non-standard applications. Datalanguage will provide features which allow the user to create an environment whereby the datacomputer system appears to provide features especially tailored to his application.
datalanguageの目標は2つのレベルでデータ構造の施設を提供することです。 1つのレベルでは、ユーザは、データの支配力をそれに与えたので、自動的に彼のデータ管理仕事の多くのことをして、いくつかの場合、データコンピュータが、より効果的に動作するのを許容する高い平らなデータ能力の利点を活用するかもしれません。 しかしながら、別のレベルでは、ユーザが原始概念に関して彼のアプリケーションについて説明できる特徴を提供します。 datacomputerユーザがさまざまなデータ構造物を構成するかもしれなくて、操作に関してかなりの柔軟性を持つこのように、彼は彼のデータに働くことができます。 また、原始のレベルでdatacomputerと対話することによって、ユーザは標準的でないアプリケーションのためのリソースの、より効果的な用法をもたらすかもしれないdatacomputerによって使われたメソッドに多くのコントロールを及ぼすことができます。 Datalanguageはユーザがdatacomputerシステムが彼のアプリケーションに特に適合した特徴を提供するように見える環境を作成できる特徴を提供するでしょう。
The control features discussed above allow the user to extend the operations available on data by appropriate composition of the operations. Datalanguage will provide a method of defining a composite request to be a new request (called a _function_). In this way a new operation on specific data can be defined once and then used repeatedly. In order that the user may define general operations, datalanguage will provide functions which can be parameterized. That is, functions will not only be able to operate on specific data but may be defined to work on any data of a specific type. This capability will not be limited to basic data types (e.g. integers) or even specific aggregate types (e.g. array of integers) but will also include the ability to define functions which operate on classes of data. For example, functions can be defined which operate on lists independent of the type of the list members. Also provided, will be the ability to expand and modify existing functions as well as creating new functions. This includes expanding the types of data for which a function is defined or modifying the behavior of a function for certain types of data.
上で議論したコントロール機能で、ユーザはデータで操作の適切な構成で利用可能な操作を広げることができます。 Datalanguageは新しい要求(_機能を_と呼ぶ)であるという合成要求を定義するメソッドを提供するでしょう。 このように、特定のデータにおける新しい操作を一度定義して、次に、繰り返して使用できます。 ユーザが一般的な操作を定義できるように、datalanguageはparameterizedされることができる機能を提供するでしょう。 すなわち、機能は、特定のデータを作動させることができるだけではありませんが、特定のタイプのどんなデータにも取り組むために定義されるかもしれません。 この能力は、基本のデータ型(例えば、整数)か特定の集成型(例えば、整数の勢ぞろい)にさえ制限されませんが、また、データのクラスを経営する機能を定義する能力を含むでしょう。 例えば、機能を定義できます(リストメンバーのタイプの如何にかかわらずリストで作動します)。 また、広げて、変更する能力が従来の機能であるつもりであったなら提供されて、新しい機能を作成します。 これは、データ機能が定義されるか、または確かな機能の振舞いを変更するのがタイプされるデータのタイプを膨張させるのを含んでいます。
As with operations, the data aggregates discussed above allow the user to extend the primitive data types by appropriate composition. For example, a two dimensional array of integers can be created by creating an array of arrays of integers. The situation for data types is analogous to that of operations. Datalanguage will provide the ability to define a composition of data to be a new data type. Also the capability of defining general data structures will be provided by essentially parameterizing the new data definition. This would allow the general concept of two dimensional array to be defined as an array of arrays. Once defined, one could create two dimensional arrays of integers, two dimensional arrays of booleans, etc. As with functions
操作のように、ユーザは上で議論したデータ集合体で適切な構成で基本データ型を広げることができます。 例えば、整数の勢ぞろいの配列を作成することによって、整数の2次元配列を作成できます。 データ型のための状況は操作のものに類似しています。 Datalanguageは新しいデータ型になるようにデータの構成を定義する能力を提供するでしょう。 また、本質的には新しいデータ定義をparameterizingすることによって、一般データ構造を定義する能力を提供するでしょう。 これは、2次元配列に関する一般概念が配列の勢ぞろいと定義されるのを許容するでしょう。 いったん定義されると、1つは整数の2次元配列、論理演算子の2次元配列などを作成するかもしれません。 機能
Winter, Hill & Greiff [Page 38] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[38ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
there is also a need to expand or modify existing data types. One might want to expand the attributes which apply to a given data type, in that he might want to add new attributes, or add new choices for the existing attributes.
また、既存のデータタイプを膨張するか、または変更する必要があります。 人は与えられたデータ型に適用される属性を広げたがっているかもしれません、彼が既存の属性のために新しい属性を加えたいか、または新しい選択を加えたがっているかもしれないので。
The control features can be extended also. Special control features might be needed to process a data structure in a special way or to process a user defined data structure. For example, if a tree type data structure has been defined in terms of lists of lists, the user might like to define a control function which causes a specified operation to be performed on each item of a specified tree. As with data types and functions, there is a need to be able to modify and extend existing control features as well as the ability to create new ones.
また、コントロール機能を広げることができます。 特別なコントロール機能が、特別な方法でデータ構造を処理するか、またはユーザの定義されたデータ構造を処理するのに必要であるかもしれません。 例えば、木のタイプデータ構造がリストのリストで定義されたなら、ユーザは、指定された木に関する各個条に指定された操作を実行するコントロール機能を定義するのが好きであるかもしれません。 データ型と機能のように、新しいものを作成する能力と同様に既存のコントロール機能を変更して、広げることができる必要があります。
Datalanguage will provide the ability to treat data descriptions and operations in much the same way that data is treated. One can describe and manipulate descriptions and operations in the same way that he can describe and manipulate data. It is impossible to talk about data types without consideration of operations and equally as impossible to talk about operations without an understanding of the data types they operate on. In order for the user to be able to effect the behavior of the datacomputer system, the design of datalanguage will include a definition of the operational cycle of the datacomputer. Precise definitions of all aspects of data (data attributes, data classes, relationship of aggregates to their subordinate items, etc.) in terms of their interaction with datalanguage operations will be made. In this way the datacomputer can offer tools which will give the datacomputer user the ability to be an active participant in the design of the datalanguage which he uses.
Datalanguageはデータが似たり寄ったりの道でデータ記述と操作ですが、扱われて、扱う能力を提供するでしょう。 人が記述を説明して、操ることができて、彼がそうすることができる同じようにおける操作は、データを説明して、操ります。 操作に関してそれらが作動させるデータ型の理解なしで話すのは、無償で操作のデータ型に関して話すのが同じくらい不可能であって等しさ同じくらい不可能です。 ユーザがdatacomputerシステムの働きに作用できるように、datalanguageのデザインはdatacomputerの操作上のサイクルの定義を含むでしょう。 datalanguage操作とのそれらの相互作用に関するデータ(データ属性、データのクラス、それらの部下の品目への集合の関係など)の全面の厳密な定義をするでしょう。 datacomputerが彼が使用するdatalanguageのデザインの積極的な参加者である能力をdatacomputerユーザに与えるツールを提供できるこのように。
Winter, Hill & Greiff [Page 39] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[39ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
4. A Model for Datalanguage Semantics
4. Datalanguage意味論のためのモデル
For the purpose of defining and experimenting with language semantics and with language processing techniques, we are developing a model datacomputer.
言語意味論を定義して、実験する目的と言語処理のテクニックで、私たちはモデルdatacomputerを開発しています。
The principal elements of the model are the following:
(1) A set of primitive functions
(2) An environment in which data objects can be created, manipulated and
deleted, using the primitives
(3) A structure for the representation of collections of data values,
their descriptions, their relationships, and their names.
(4) An interpreter which executes the primitives
(5) A compiler which inputs requests in a very simple language, performs
binding and macro expansion operations, and generates calls to the
internal semantic primitives.
モデルの主要な原理は以下です: (1) (2) 1セットの原始関数はデータ・オブジェクトが作成されて、操られて、削除されて、データの収集の表現のための構造が評価する基関数(3)、彼らの記述、それらの関係、およびそれらの名前を使用するのをそうすることができる環境です。 (4) 非常に簡単な言語における要求を入力して、結合とマクロ展開操作を実行して、内部の意味原素に呼び出しを生成する基関数(5)Aコンパイラを実行するインタプリタ。
If our modeling efforts are successful, the model will evolve until it accepts a language like the datalanguage whose properties we have described in sections 2 and 3 of this paper. Then the process of writing the final specification will simply require reconciliation of details not modeled with structure that has been modeled. One rather large detail which we may never handle within the model is syntax; in this case reconciliation will be more involved; however, we firmly believe that the semantic structure should determine the syntax rather than the opposite, so we will be in the proper position to handle the problem.
私たちのモデル取り組みがうまくいくと、私たちがこの紙のセクション2と3で特性について説明したdatalanguageのような言語を受け入れるまで、モデルは発展するでしょう。 そして、最終的な仕様を書くプロセスは単にモデル化された構造でモデル化されなかった詳細の和解を必要とするでしょう。 私たちがモデルの中で決して扱わないかもしれない1つのかなり大きい詳細が構文です。 この場合、和解はさらにかかわるでしょう。 しかしながら、意味構造が正反対よりむしろ構文を決定するはずであると堅く信じているので、私たちは問題を扱う適切な立場にいるでしょう。
By constructing a model for each of the elements listed above, we are "implementing" the language as we design it, in a very loose sense. In effect, we work in a laboratory, rather than working strictly on paper. Since we aren't concerned with the performance or usability of the datacomputer we are building in the laboratory, we are able to build without becoming involved with some of the most time-consuming concerns of an implementor. However, because we are building and tinkering, rather than simply working on paper, we do get some of the advantages that normally come with the experience of implementing one's ideas.
上に記載されたそれぞれの要素のためにモデルを構成することによって、それを設計するとき、私たちは言語を「実装しています」、非常にゆるい意味で。 事実上、私たちは厳密に紙上で働いているより実験室でむしろ働いています。 私たちが実験室に建てることをdatacomputerの性能かユーザビリティに私たちを心配させないので、作成者の最も手間がかかった関心のいくつかにかかわるようにならないで、私たちは建てることができます。 しかしながら、単に紙上で働いているよりむしろ建てて、いじくりまわしているので、私たちは通常、人の考えを実装する経験で来る利点のいくつかを得ます。
The model datacomputer is a program, developed in ECL, using the EL1 language. Presently we are interested in the process of developing the program, not running it. Our primary requirement is to have, in advance of the existence of datalanguage, a well-defined and flexible notation in which to specify data structures, function definitions and examples. EL1 is convenient for this. Having a program which actually works and acts like a simple datacomputer is really a by-product of specifying semantics in a programming language. It is not necessary for the program to work, but it does provide some nice features. It enhances the "laboratory" effect, by doing such things as automatically compiling
モデルdatacomputerはEL1言語を使用するECLで開発されたプログラムです。 それを実行するのではなく、プログラムを開発することの途中に現在の、私たちは興味を持っています。 私たちのプライマリ要件はdatalanguageの存在の前にデータ構造、関数定義、および例を指定する明確でフレキシブルな記法を持つことです。 これはEL1が都合がよいです。 簡単なdatacomputerのように実際に働いて、作動するプログラムを持つのは、本当にプログラミング言語で、指定意味論の副産物です。 プログラムが動作するのは必要ではありませんが、それはいくつかの良い特徴を提供します。 それは、自動的にコンパイルしているようなことをすることによって、「実験室」効果を高めます。
Winter, Hill & Greiff [Page 40] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[40ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
strings of primitives, displaying the state of the environment in complicated examples, automatically discovering inconsistencies (in the form of bugs), and so on.
基関数のストリング、自動的に矛盾を発見して、複雑な例に環境状況を表示して(バグの形の)、など。
There are two major reasons that EL1 is a convenient notation for specifying datalanguage semantics. One is that the languages have a certain amount in common, in both concepts and in goals in data description. (In part, this is because EL1 itself has been a good source of ideas in attacking the datalanguage problem). Both languages emphasize operations on data, independent of underlying representation. A second reason that EL1 is a convenient way to specify datalanguage, is that EL1 is extensible; in fact, many primitive functions could be embedded directly into EL1 by using the extension facilities. At times, we have chosen to embed less than we could, to expose problems of interest to us.
EL1がdatalanguage意味論を指定するための便利な記法である2つの主要な理由があります。 1つは言語が両方の概念とデータ記述における目標で、ある量が共通であるということです。 (これはEL1自身がdatalanguage問題を攻撃することにおける考えの良い源であるから一部です。) 両方の言語は基底表示の如何にかかわらずデータに操作を強調します。 EL1がdatalanguageを指定する便利な方法である2番目の理由はEL1が広げることができるということです。 事実上、多くの原始関数が、拡大施設を使用することによって、直接EL1に埋め込まれるかもしれません。 時には、私たちは、私たちが私たちにとって、興味深い露出問題に選んだことができたより以下を埋め込むのを選びました。
So far, the model has been useful primarily in exposing design issues and relationships between design decisions. Also, because it includes so many of the elements of the full system (compiler, interpreter, environment, etc.), it encourages a fairly complete analysis of any proposal.
今までのところ、デザインがデザイン決定の間の問題と関係であると主として暴露する際にモデルは役に立っています。 また、完全なシステム(コンパイラ、インタプリタ、環境など)のとても多い原理を含んでいるので、それはどんな提案のかなり完全な分析も奨励します。
In presenting the model in this section, we have chosen to emphasize ideas and examples, rather than formal definitions in EL1. This is because the ideas are more permanent and relevant at this point (the formalisms are changing rather frequently) and because we imagine people reading the formal definitions only to get at the ideas. The formal definitions may be interesting in themselves when the language is complete; at this point they are probably of interest only to us.
このセクションのモデルを提示する際に、私たちは、EL1への公式の定義よりむしろ考えと例を強調するのを選びました。 これは考えがここにより永久的であって、関連していて(形式はかなり頻繁に変化します)、私たちが、人々が公式の定義を読むと考えに達する想像するからです。 言語が完全であるときに、公式の定義は自分たちでおもしろいかもしれません。 ここに、私たちだけには、彼らはたぶん興味深いです。
The section is organized into a large number of sub-sections. The first few are concerned with the basic concepts of data objects, descriptions, and relationships between objects. We then discuss primitive semantic functions and present informal definitions and examples in sections 4.7 and 4.8. Section 4.9 is a brief discussion of compilation, interpretation and the execution cycle. Section 4.10 provides a fairly elaborate example of how primitive functions can be combined to do something of interest: a selective retrieval by content. The last two sections wrap up with discussions of high-level functions and some conclusions.
セクションは多くの小区分に組織化されます。 1番目はオブジェクトの間のオブジェクト、記述、および関係がデータに関する基本概念に関係がありました。 そして、私たちはセクション4.7と4.8の原始の意味関数、現在の非公式な定義、および例について議論します。 セクション4.9は編集、解釈、および実行サイクルの簡潔な議論です。 セクション4.10は何か興味があることをするためにどう原始関数を結合できるかに関するかなり入念な例を提供します: 内容による選択している検索。 最後の2つのセクションがハイレベルの議論で機能といくつかの結論を終えます。
4.1 Objects
4.1 オブジェクト
An _object_ has a name, a description, and a value. It can be related to other objects.
_オブジェクト_には、名前、記述、および値があります。 それは他のオブジェクトに関連する場合があります。
The _name_ is a symbol, which can be used to access the object from
_という_名はオブジェクトにアクセスするシンボルです。(そのシンボルを使用できます)。
Winter, Hill & Greiff [Page 41] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[41ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
language functions.
言語は機能します。
The _description_ is a specification of properties of the object, many of which relate to the meaning or the representation of the value.
_記述_はそれの多くが意味に関連するオブジェクトの特性の仕様か価値の表現です。
The _value_ is the information of ultimate interest in the object.
_価値の_は究極にオブジェクトへの関心の情報です。
The relationships between objects are hierarchical. Each object can be related directly to at most four other objects, designated as its _parent_, its _child_, its _left_sibling_, and its _right_sibling_.
オブジェクトの間の関係は階層的です。 _親_、_子供_、_左の_兄弟_、および_権利_兄弟_は、直接高々他の4個のオブジェクトしか各オブジェクトを関係づけることができないのを任じました。
This specific concept of relationship is all that has been built in to the model to date. One of our primary objectives in the future is to experiment with more general relationships among objects.
関係に関するこの種概念はこれまでのモデルにそれを建ててあるすべてです。 未来の私たちの主目的の1つはオブジェクトの中で、より一般的な関係を実験することです。
4.2 Descriptions
4.2 記述
A description has the components _name_, _type_ and _type- dependent_parameters_. It can be related hierarchically to other descriptions, according to a scheme similar to the one described for objects in 4.1.
記述にはコンポーネントの_名前_、_タイプ_、および_タイプ依存する_パラメタ_があります。階層的で他の記述に関連する場合があります、4.1においてオブジェクトのために説明されたものと同様の体系通りに。
The _name_ has a role in referencing, as in the case of objects.
_という_名には、参照箇所における役割がオブジェクトのケースのようにあります。
_Type_ is an undefined, intuitive idea for which we expect to develop a precise meaning within datalanguage(see section 3.10 for some of the ideas about this). In terms of the present model, it simply means one of the following: LIST, STRUCT, STRING, BOOL, DESC, DIR, FUNC, 0PD. Each of these refers to a sort of value corresponding to common ideas in programming (with the exception of OPD, which is explained in section 4.7), and on which certain operations are defined.
_タイプ_は私たちがdatalanguageの中で正確な意味を開発すると予想する未定義の、そして、直感的な考え(考えのいくつかに関してこれに関してセクション3.10を見る)です。 現在のモデルで、単に以下の1つを意味します: リスト、STRUCT、ストリング、ブール、DESC、ディルFUNC、0PD。 それぞれのこれらはプログラミング(セクション4.7で説明されるOPDを除いた)における一般的な考えと、どのある操作が定義されるかに関して対応する一種の値について言及します。
Examples of _type-dependent_parameters are the two items needed to define a STRING: size option and size. A STRING is a sequence of characters; the size of the STRING is the number of characters in it. If a STRING has a fixed size, then size option is FIXED and size is the number of characters it always contains. If a STRING has a varying size, then size option is VARYING, and size is its maximum (clearly, it might also have a minimum in a more refined scheme).
_タイプ依存する_パラメタに関する例はSTRINGを定義するのに必要である2つの項目です: サイズオプションとサイズ。 STRINGはキャラクタの系列です。 STRINGのサイズはそれのキャラクタの数です。 STRINGに固定サイズがあるなら、当時のサイズオプションはFIXEDです、そして、サイズはそれがいつも含むキャラクタの数です。 STRINGに異なったサイズがあるなら、当時のサイズオプションはVARYINGです、そして、サイズはその最大(また、明確に、それは、より洗練された体系で最小限を持っているかもしれない)です。
When the description of an object has a type of STRING, it is commonly said that the object is a STRING.
オブジェクトの記述に一種のSTRINGがあると、オブジェクトがSTRINGであると一般的に言われます。
4.3 Values
4.3 値
The value is the data itself.
値はデータ自体です。
Winter, Hill & Greiff [Page 42] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[42ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
An object of type BOOL can have only either the value TRUE or the value FALSE.
タイプブールのオブジェクトは値のTRUEか値のFALSEのどちらかしか持つことができません。
An object of type STRING has values such as 'ABC', 'JOHN', or 'BOSTON'.
タイプSTRINGのオブジェクトには、'ABC'、'ジョン'、または'ボストン'などの値があります。
Each value has a representation, in bits. Thus a BOOL is represented by a single bit, which will be a 'one' to represent TRUE and a 'zero' to represent FALSE.
各値には、ビットにおける表現があります。 したがって、ブールは1ビットによって代理をされます。(それは、FALSEを表すためにTRUEと'ゼロ'を表すためには'1つ'でしょう)。
4.4 Some examples
4.4 いくつかの例
Here are some examples of structures involving objects, descriptions, and values. In these explanations and drawings, the objective is to convey some ideas about these primitive structures; considerable detail is omitted in the drawings in the interest of clarity.
ここに、構造に関するいくつかの例が、オブジェクト、記述、および値を伴いながら、あります。 これらの説明と図面では、目的はこれらの原始の構造に関するいくつかの考えを伝えることです。 かなりの詳細が明快のために図面で省略されます。
Figure 4-1 shows two objects. X is of type string and has value 'ABC'. Y is of type bool and has value TRUE.
図4-1は2個のオブジェクトを示しています。 Xは、タイプストリングでできていて、値の'ABC'を持っています。 Yには、タイプboolにはあって、値のTRUEがあります。
Winter, Hill & Greiff [Page 43] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[43ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________
| |
| _____________ |
| | X | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | STRING | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | | | DESCRIPTION
| |_________|___| |
| VALUE | | ____________
|___________|_____| | |
OBJECT |____________\| "ABC" |
/|____________|
VALUE
_________________
| |
| _____________ |
| | Y | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | BOOL | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | | | DESCRIPTION
| |_________|___| |
| VALUE | | ____________
|___________|_____| | |
OBJECT |____________\| TRUE |
/|____________|
VALUE
_________________ | | | _____________ | | | X| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | ストリング| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | | | 記述| |_________|___| | | 値| | ____________ |___________|_____| | | オブジェクト|____________\| "ABC"| /|____________| 値_________________ | | | _____________ | | | Y| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | ブール| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | | | 記述| |_________|___| | | 値| | ____________ |___________|_____| | | オブジェクト|____________\| 本当| /|____________| 値
Figure 4-1
Two elementary objects
図4-1 Twoの基本のオブジェクト
Figure 4-2 illustrates an object of type dir (a _directory_) and related objects. The directory has name SMITH. There are two objects entered in this directory, named X and Y.
図4-2はタイプdir(_ディレクトリ_)と関連するオブジェクトのオブジェクトを例証します。 ディレクトリには、名前スミスがいます。 XとYというこのディレクトリに入れられる2個のオブジェクトがあります。
Winter, Hill & Greiff [Page 44] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[44ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________
| _____________ |
| | SMITH | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | DIR | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | | | DESCRIPTION
| |_________|___| |
| CHILD | |
|___________|_____|
OBJECT |
___________V_____
| _____________ |
| | X | |
| |_____________| |
| NAME | _________________
| _____________ | | _____________ |
_____|_|____ | | | | Y | |
| | |_____________| | | |_____________| |
| | DESCRIPTION | | NAME |
| | _____________ | | _____________ |
| __|_|____ | | | | ____|_|_____
| | | |_____________| | | |_____________| | |
| | | VALUE | | DESCRIPTION | |
| | | _____________ | | _____________ | |
| | | | ____|_|_____\| | ____|_|__ |
| | | |_____________| | /| |_____________| | | |
| | | SIBLING | | VALUE | | |
| | |_________________| |_________________| | |
| | OBJECT OBJECT | |
| | _________________ _________________ | |
| |_\| "ABC" | | FALSE |/_| |
| /|_________________| |_________________|\ |
| VALUE VALUE |
| _________________ _________________ |
| | _____________ | | _____________ | |
| | | STRING | | | | BOOL | | |
|____\| |_____________| | | |_____________| |/____|
/| TYPE | | TYPE |\
|_________________| |_________________|
DESCRIPTION DESCRIPTION
_________________ | _____________ | | | スミス| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | ディル| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | | | 記述| |_________|___| | | 子供| | |___________|_____| オブジェクト| ___________V_____ | _____________ | | | X| | | |_____________| | | 名前| _________________ | _____________ | | _____________ | _____|_|____ | | | | Y| | | | |_____________| | | |_____________| | | | 記述| | 名前| | | _____________ | | _____________ | | __|_|____ | | | | ____|_|_____ | | | |_____________| | | |_____________| | | | | | 値| | 記述| | | | | _____________ | | _____________ | | | | | | ____|_|_____\| | ____|_|__ | | | | |_____________| | /| |_____________| | | | | | | 兄弟| | 値| | | | | |_________________| |_________________| | | | | オブジェクトオブジェクト| | | | _________________ _________________ | | | |_\| "ABC"| | 誤る|/_| | | /|_________________| |_________________|\ | | 値の値| | _________________ _________________ | | | _____________ | | _____________ | | | | | ストリング| | | | ブール| | | |____\| |_____________| | | |_____________| |/____| /| タイプ| | タイプ|\ |_________________| |_________________| 記述記述
Figure 4-2: A directory with two members
図4-2: 2人のメンバーがいるディレクトリ
Winter, Hill & Greiff [Page 45] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[45ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
The idea of a dir is similar to the idea of a file directory in most systems. A directory is a place where one can store named objects, freely adding and deleting them. The entries in the directory are all objects whose parent is that directory. Figure 4-3 shows a more rigidly structured group of objects. Here we have R, a struct, and A and B, a pair of strings. Note that the boxes labeled 'object' in figure 4-3 bear precisely the same relationships to one another as those labeled 'object' in 4-2. However, there are two conditions which hold for 4-3 but do not hold for 4-2: (1) the value of R contains the values of A and B, and (2) the descriptions of R, A and B are all related.
dirの考えはほとんどのシステムにおいてファイルディレクトリの考えと同様です。ディレクトリは1つが命名されたオブジェクトを保存できる場所です、自由にそれらを加えて、削除して。 ディレクトリにおけるエントリーはすべて親がそのディレクトリであるオブジェクトです。 図4-3はオブジェクトの、より厳格に構造化されたグループを示しています。 ここに、私たちはRとstructとAとB、1組のストリングを持っています。 ものが4-2を'オブジェクト'をラベルしたとき図4-3を'オブジェクト'とラベルされた箱が正確にお互いとの同じ関係に堪えることに注意してください。 しかしながら、4-3のために成立しますが、4-2のために成立しない2つの状態はあります: (1) (2) Rの値はAとBの値を含んでいます、そして、R、A、およびBの記述はすべて関係づけられます。
Structs have the following properties: (1) name and description of each component in the struct is established when the struct is created, and (2) in a value of the struct, the order of occurrence of component values is fixed.
Structsには、以下の特性があります: (1) (2) structが作成されるとき、structのそれぞれのコンポーネントの名前と記述は確立しています、そして、structの値では、成分値の発生の注文は固定されています。
Winter, Hill & Greiff [Page 46] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[46ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | R | | | | STRUCT | |
| |_____________| | | |_____________| |
| NAME | | TYPE |
| _____________ | | _____________ |
| | ____|_|______\| | | |
| |_____________| | /| |__________|__| |
| DESCRIPTION | | CHILD | |
| _____________ | |____________|____|
_____|_|____ | | DESCRIPTION |
| | |_____________| | ____________V____
| | VALUE | | _____________ |
| | _____________ | | | STRING | |
| | | | | | |_____________| |
| | |_________|___| | ___\| TYPE | _____________
| | CHILD | | | /| _____________ | | _________ |
| |___________|_____| | | | ____|_|______\| | STRING | |
| OBJECT | | | |_____________| | /| |_________| |
| | | | SIBLING | | TYPE |
| ___________V_____ | |_________________| |_____________|
| | _____________ | | DESCRIPTION DESCRIPTION A
| | | A | | | |
| | |_____________| | | _________________ |
| | NAME | | | _____________ | |
| | _____________ | | | | B | | |
| | | ____|_|__| | |_____________| | |
| | |_____________| | | NAME | |
| | DESCRIPTION | | _____________ | |
| | _____________ | | | ____|_|___________________|
| __|_|____ | | | |_____________| |
| | | |_____________| | | DESCRIPTION |
| | | VALUE | | _____________ |
| | | _____________ | | | ____|_|____
| | | | ____|_|______\| |_____________| | |
| | | |_____________| | /| VALUE | |
| | | SIBLING | | _____________ | |
| | |_________________| | | | | |
| | OBJECT | |_____________| | |
| | | SIBLING | |
| | |_________________| |
| |__________ OBJECT _____________|
| _______|__________________________|_______
|____\| _____V_______ _______V_____ |
/| | "ABC" | | FALSE | | Figure 4-3
| |_____________| |_____________| | A STRUCT with
|__________________________________________| two members
_________________ _________________ | _____________ | | _____________ | | | R| | | | STRUCT| | | |_____________| | | |_____________| | | 名前| | タイプ| | _____________ | | _____________ | | | ____|_|______\| | | | | |_____________| | /| |__________|__| | | 記述| | 子供| | | _____________ | |____________|____| _____|_|____ | | 記述| | | |_____________| | ____________V____ | | 値| | _____________ | | | _____________ | | | ストリング| | | | | | | | |_____________| | | | |_________|___| | ___\| タイプ| _____________ | | 子供| | | /| _____________ | | _________ | | |___________|_____| | | | ____|_|______\| | ストリング| | | オブジェクト| | | |_____________| | /| |_________| | | | | | 兄弟| | タイプ| | ___________V_____ | |_________________| |_____________| | | _____________ | | 記述記述A| | | A| | | | | | |_____________| | | _________________ | | | 名前| | | _____________ | | | | _____________ | | | | B| | | | | | ____|_|__| | |_____________| | | | | |_____________| | | 名前| | | | 記述| | _____________ | | | | _____________ | | | ____|_|___________________| | __|_|____ | | | |_____________| | | | | |_____________| | | 記述| | | | 値| | _____________ | | | | _____________ | | | ____|_|____ | | | | ____|_|______\| |_____________| | | | | | |_____________| | /| 値| | | | | 兄弟| | _____________ | | | | |_________________| | | | | | | | オブジェクト| |_____________| | | | | | 兄弟| | | | |_________________| | | |__________ オブジェクト_____________| | _______|__________________________|_______ |____\| _____V_______ _______V_____ | /| | "ABC"| | 誤る| | 図4-3| |_____________| |_____________| | STRUCT|__________________________________________| 2人のメンバー
Winter, Hill & Greiff [Page 47] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[47ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
Figure 4-4 shows a list named L. Here a similar structure of objects is implied, but because of the regularity of the structure, not all the boxes labeled 'object' are actually present.
図4-4は、L.Hereと命名されて、オブジェクトの類似構造物が含意されるのをリストに示しますが、構造の規則性のために、'オブジェクト'とラベルされたというわけではないすべての箱が実際に存在しています。
_________________
| _____________ |
| | L | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | LIST | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | | ________ |
| | | | | | | |
| |_______|_____| | | |______|_| |
| VALUE | | | CHILD | |
|_________|_______| |________|___|
OBJECT | DESCRIPTION |
| |
_________V_______ ________V___
| | | ________ |
| _____________ | | | STRING | |
| | "ABC" | | | |________| |
| |_____________| | | TYPE |
| _____________ | |____________|
| | "XY" | | DESCRIPTION
| |_____________| |
| _____________ |
| | "ZLM" | |
| |_____________| |
| : |
| : |
| _____________ |
| | "BBBF" | |
| |_____________| |
|_________________|
VALUE
_________________ | _____________ | | | L| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | リスト| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | | ________ | | | | | | | | | | |_______|_____| | | |______|_| | | 値| | | 子供| | |_________|_______| |________|___| オブジェクト| 記述| | | _________V_______ ________V___ | | | ________ | | _____________ | | | ストリング| | | | "ABC"| | | |________| | | |_____________| | | タイプ| | _____________ | |____________| | | "XY"| | 記述| |_____________| | | _____________ | | | "ZLM"| | | |_____________| | | : | | : | | _____________ | | | "BBBF"| | | |_____________| | |_________________| 値
Figure 4-4
A LIST
図4-4 リスト
L has a variable number of components, all satisfying the description subordinate to L's description.
Lには、Lの記述に記述部下をすべて満たして、可変数のコンポーネントがあります。
Winter, Hill & Greiff [Page 48] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[48ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
We could imagine an 'object' box for each string in L. Each of these boxes would point to its respective string and to the common description of these strings. Instead, we think in terms of creating such boxes as we need them.
私たちは、これらの箱のL.Eachの各ストリングのための'オブジェクト'箱がそれぞれのストリングと、そして、これらのストリングの一般的な記述に向けられると想像できました。 代わりに、私たちは私たちがそれらを必要としながらそのような箱を作成することに関して考えます。
4.5 Definitions of types
4.5 タイプの定義
Following are some more precise definitions of types, in terms of the present model. These serve the purpose of establishing more firmly the semantics of our structure of objects, descriptions and values; however, they should not be thought of as providing a definition for the completed language specification.
以下に、タイプのそれ以上の厳密な定義が現在のモデルであります。 これらは、よりしっかり私たちのオブジェクト、記述、および値の構造の意味論を確立する目的に役立ちます。 しかしながら、完成した言語仕様のための定義を提供するとそれらを考えるべきではありません。
An object of type STRING has a value which is a sequence of characters (figure 4-1).
タイプSTRINGのオブジェクトには、キャラクタ(図4-1)の系列である値があります。
An object of type BOOL has a value which is a truth value (TRUE or FALSE -- figure 4-1).
タイプブールのオブジェクトには、真理値(TRUEかFALSE--4-1に、計算する)である値があります。
An object of type DIR has subordinate objects, each having its own description and value. Subordinate objects can be added and deleted at will (figure 4-2).
タイプDIRのオブジェクトには、それぞれそれ自身の記述と値を持っていて、下位オブジェクトがあります。 下位オブジェクトを自由自在(図4-2)に加えて、削除できます。
An object of type STRUCT has subordinate objects, each of which has a description which is subordinate to the STRUCT's description, and a value contained in the STRUCT's value. The number, order and description of components is fixed when the STRUCT is created (figure 4-3).
タイプSTRUCTのオブジェクトには下位オブジェクトがあります。それはそれぞれSTRUCTの記述に下位であることの記述、およびSTRUCTの値に含まれた値を持っています。 STRUCTが作成されるとき(図4-3)、コンポーネントの数、注文、および記述は固定されています。
An object of type LIST may be thought of as having imaginary subordinate objects, whose existence is simulated by the use of appropriate techniques in processing the LIST. Each of these has the same description, which is subordinate to the description of the LIST. Each has a distinct value, contained in the value of the LIST. In fact, only the LIST object, the LIST and component descriptions, and the values exist (figure 4-4).
タイプLISTのオブジェクトは想像する下位オブジェクトを持っていると考えられるかもしれません。(下位オブジェクトの存在はLISTを処理することにおける適切なテクニックの使用でシミュレートされます)。それぞれのこれらには、LISTの記述に下位であることののと同じ記述があります。それぞれには、LISTの値に含まれた異なった値があります。LISTオブジェクト、LIST、コンポーネント記述、および値だけが存在しています(図4-4)。
An object of type DESC has a description as its value. This value is the same sort of entity which serves as the description of other objects.
タイプDESCのオブジェクトには、値として記述があります。 この値は他のオブジェクトの記述として機能する同じ種類の実体です。
An object of type FUNC has a function call as its value. We will be able to say more about this after functions have been discussed.
タイプFUNCのオブジェクトには、値としてファンクションコールがあります。 機能について議論した後に私たちはこれに関してもう少し言うことができるでしょう。
An object of type OPD has an operation descriptor as its value. (see 4.7 for details).
タイプOPDのオブジェクトには、値として操作記述子があります。 (詳細に関して4.7を見ます。)
Winter, Hill & Greiff [Page 49] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[49ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
4.6 Object environment
4.6 オブジェクト環境
There are three categories of objects in the model datacomputer. These are p/objects, t/objects, and i/objects.
モデルdatacomputerにはオブジェクトの3つのカテゴリがあります。 これらは、p/オブジェクトと、t/オブジェクトと、i/オブジェクトです。
P/objects are permanent objects created explicitly with language functions. They correspond to the idea of stored data in the real datacomputer. There are three special objects. These are special only in that they are created as part of initializing the environment, rather than as the result of executing a language function. These are named STAR, BLOCK and TOP/LEVEL. All three are of type DIR.
P/オブジェクトは明らかに言語機能で作成された永続オブジェクトです。 彼らは本当のdatacomputerの記憶されたデータの考えに対応します。 3個の特別なオブジェクトがあります。 単にそれらが環境を初期化する一部として作成されるので、これらは特別です、言語機能を実行するというむしろ結果より。 これらはSTAR、BLOCK、およびTOP/LEVELと命名されます。 タイプDIRにはすべての3があります。
An object is a p/object if it is subordinate to STAR; it is a t/object if it is subordinate to BLOCK. TOP/LEVEL is subordinate to BLOCK. (see figures 4-5 and 4-6).
それがSTARに下位であるなら、オブジェクトはp/オブジェクトです。 BLOCKに下位であるなら、それはt/オブジェクトです。 TOP/LEVELはBLOCKに下位です。 (数字4-5と4-6を参照します。)
_________________
| |
| _____________ |
| | STAR | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | DIR | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | | | DESCRIPTION
| |_________|___| |
| CHILD | |
|___________|_____|
OBJECT |
|
|
|
V
_________________ | | | _____________ | | | 星| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | ディル| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | | | 記述| |_________|___| | | 子供| | |___________|_____| オブジェクト| | | | V
ALL P/OBJECTS
すべてのP/オブジェクト
Figure 4-5
STAR and p/objects
図4-5 STARとp/オブジェクト
T/objects are temporary objects, also created explicitly with language functions. However, these correspond to user-defined temporaries, both local to requests and "top-level" (i.e. not local to any request, but existing until deletion or logout.)
T/オブジェクトはまた、明らかに言語機能で作成された一時的なオブジェクトです。 しかしながら、これらはともに要求と「トップレベル」への地方のユーザによって定義されたtemporariesに対応しています。(要求しますが、すなわち、いずれへのどんなローカルも削除まで存在しないか、またはログアウトしてください。)
Winter, Hill & Greiff [Page 50] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[50ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________
| |
| _____________ |
| | BLOCK | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | DIR | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | | | DESCRIPTION
| |_________|___| |
| VALUE | |
|___________|_____|
OBJECT |
|
|
___________V_____
| |
| _____________ |
| | TOP/LEVEL | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | DIR | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | ____|_|___ DESCRIPTION
| |_____________| | |
| SIBLING | |
| _____________ | |___\ ALL BLOCKS AND
| | | | / LOCAL T/OBJECTS
| |_________|___| |
| CHILD | |
|___________|_____|
|
|
V
_________________ | | | _____________ | | | ブロック| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | ディル| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | | | 記述| |_________|___| | | 値| | |___________|_____| オブジェクト| | | ___________V_____ | | | _____________ | | | 先端/レベル| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | ディル| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | ____|_|___ 記述| |_____________| | | | 兄弟| | | _____________ | |___\はANDをすべて妨げます。| | | | /地方のT/オブジェクト| |_________|___| | | 子供| | |___________|_____| | | V
ALL GLOBAL
T/OBJECTS
すべてのグローバルなT/オブジェクト
Figure 4-6
BLOCK, TOP/LEVEL and t/objects
図4-6 BLOCK、TOP/LEVEL、およびt/オブジェクト
Winter, Hill & Greiff [Page 51] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[51ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
I/objects are internal, system-defined objects whose creation and deletion is implicit in the execution of some language function.
私は/が、反対する作成と削除が何らかの言語機能の実行で暗黙である内部の、そして、システムで定義されたオブジェクトです。
I/objects are hung directly off of function calls (objects of type FUNC), and are always local to the execution of such function calls. They correspond to the notions of (1) literal, and (2) compiler- or interpreter-generated temporary.
私は、/が、反対する直接ファンクションコール(タイプFUNCのオブジェクト)から掛けられて、いつもそのようなファンクションコールの実行に地元です。 彼らは(1)リテラル、および(2)コンパイラかインタプリタが発生することの概念に一時的に対応します。
4.7 Primitive Language Functions
4.7 原始の言語機能
Here we discuss the primitive language functions presently implemented in the model and likely to be of most interest. In this section, the emphasis is on relating functions to one another. Section 4.8 contains more detail and examples.
ここで、私たちは現在ほとんどの関心のであるモデルにおそらく実装されている原始の言語機能について議論します。 このセクションに、強調がお互いに機能を関係があるところにあります。 セクション4.8はその他の詳細と例を含みます。
_Assign_ operates on a pair of objects, called the target and the source. The value of the source is copied into the value of the target. Figure 4-7 shows a pair of objects, X and Y, before and after execution of an assignment having X as target and Y as source. Presently, assignment is defined only for objects of type BOOL and objects of type STRING. The objects involved must have identical descriptions.
_1組のオブジェクトを作動させて、目標とソースと呼ばれて、_を割り当ててください。 ソースの値は目標の値にコピーされます。 XとY、図4-7は1組のオブジェクトを示しています、ソースとして目標としてのXとYを持っている課題の実行の前後に。 現在、課題はタイプブールのオブジェクトとタイプSTRINGのオブジェクトのためだけに定義されます。 かかわったオブジェクトには、同じ記述がなければなりません。
Winter, Hill & Greiff [Page 52] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[52ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| | | |
| _____________ | | _____________ |
| | | | | | | |
| | X | | | | Y | |
| |_____________| | | |_____________| |
| NAME | | NAME |
| _____________ | | _____________ |
| | | | | | | |
| |_______|_____| | | |_______|_____| |
| VALUE | | | VALUE | |
|_________|_______| |_________|_______|
OBJECT | OBJECT |
| |
_________V_______ _________V_______
| | | |
| "ABC" | | "DEF" |
|_________________| |_________________|
VALUE VALUE
_________________ _________________ | | | | | _____________ | | _____________ | | | | | | | | | | | X| | | | Y| | | |_____________| | | |_____________| | | 名前| | 名前| | _____________ | | _____________ | | | | | | | | | | |_______|_____| | | |_______|_____| | | 値| | | 値| | |_________|_______| |_________|_______| オブジェクト| オブジェクト| | | _________V_______ _________V_______ | | | | | "ABC"| | 「クールです」。| |_________________| |_________________| 値の値
BEFORE ASSIGNMENT
課題の前に
_________________ _________________
| | | |
| _____________ | | _____________ |
| | | | | | | |
| | X | | | | Y | |
| |_____________| | | |_____________| |
| NAME | | NAME |
| _____________ | | _____________ |
| | | | | | | |
| |_______|_____| | | |_______|_____| |
| VALUE | | | VALUE | |
|_________|_______| |_________|_______|
OBJECT | OBJECT |
| |
_________V_______ _________V_____
| | | |
| "DEF" | | "DEF" |
|_________________| |_________________|
VALUE VALUE
_________________ _________________ | | | | | _____________ | | _____________ | | | | | | | | | | | X| | | | Y| | | |_____________| | | |_____________| | | 名前| | 名前| | _____________ | | _____________ | | | | | | | | | | |_______|_____| | | |_______|_____| | | 値| | | 値| | |_________|_______| |_________|_______| オブジェクト| オブジェクト| | | _________V_______ _________V_____ | | | | | 「クールです」。| | 「クールです」。| |_________________| |_________________| 値の値
AFTER ASSIGNMENT
課題の後に
Figure 4-7
Effect of assignment
図4-7 課題のEffect
Winter, Hill & Greiff [Page 53] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[53ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
A class of primitive functions for manipulating LISTs is defined. These are called _listops_. All listops input a special object called an _operation_descriptor_ or OPD.
LISTsを操作するための原始関数のクラスは定義されます。 これらは_listops_と呼ばれます。すべてのlistopsが_の操作_記述子_かOPDと呼ばれる特別なオブジェクトを入力しました。
To accomplish a complete operation on a LIST, a sequence of listops must be executed. There are semantic restrictions on the composition of such sequences, and it is best to think of the entire sequence as one large operation. The state of such an operation is maintained in the OPD.
LISTで完全な操作を実行するために、listopsの系列を実行しなければなりません。 そのような系列の構成には意味制限があります、そして、1つの大きい操作として全体の系列を考えるのは最も良いです。 そのような操作の状態はOPDで維持されます。
Refer back to figure 4-4. There is one box labeled "object" in this picture; this box represents the list as a whole. To operate on any given member we need an object box to represent that member. Figure 4-8 shows the structure with an additional object box; the new box represents one member at any given moment. Its value is one of the components of the LIST value; its description is subordinate to the LIST description. In 4-8, the name of this object is M.
図4-4を差し戻してください。 この画像で「オブジェクト」とラベルされた1個の箱があります。 この箱は全体でリストを表します。 私たちがオブジェクト箱を必要とするどんな与えられたメンバーも手術するには、そのメンバーの代理をしてください。 図4-8は追加オブジェクト箱で構造を示しています。 新しい箱はいつなんどきでも1人のメンバーの代理をします。 値はLIST価値のコンポーネントの1つです。 記述はLIST記述に下位です。 4-8では、このオブジェクトの名前はMです。
In 4-8 we have enough structure to provide a description and value for M, and this is sufficient to permit the execution of operations on M as an item. However, there is no direct link between object M and object L. The structure is completed by the addition of an OPD, shown in figure 4-9.
4-8では、私たちは記述と値をMに提供できるくらいの構造を持っています、そして、これは、項目としてMにおける操作の実行を可能にするために十分です。 しかしながら、オブジェクトMとオブジェクトL.の間には、直リンクが全くありません。構造は図4-9に示されたOPDの追加で完成します。
Winter, Hill & Greiff [Page 54] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[54ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| | | _____________ |
| _____________ | | | | |
| | L | | | |_____________| |
| |_____________| | | TYPE |
| NAME | | _____________ |
| _____________ | | | | |
| | ____|_|______\| |__________|__| |
| |_____________| | /| CHILD | |
| DESCRIPTION | |____________|____|
| _____________ | DESCRIPTION |
| | | | |
| |_________|___| | ____________V____
| VALUE | | | _____________ |
|___________|_____| | | STRING | |/___
OBJECT | | |_____________| |\ |
| | TYPE | |
___________V_____ |_________________| |
| | DESCRIPTION |
| _____________ | |
| | "ABC" | | _________________ |
| |_____________| | | | |
| _____________ | | _____________ | |
| | "XY" | | | | M | | |
| |_____________| | | |_____________| | |
| _____________ | | NAME | |
| | "ZLM" |/|___ | _____________ | |
| |_____________|\| | | | ____|_|____|
| : | | | |_____________| |
| : | | | DESCRIPTION |
| _____________ | | | _____________ |
| | "BBBF" | | |___|_|____ | |
| |_____________| | | |_____________| |
|_________________| | VALUE |
VALUE |_________________|
OBJECT
_________________ _________________ | | | _____________ | | _____________ | | | | | | | L| | | |_____________| | | |_____________| | | タイプ| | 名前| | _____________ | | _____________ | | | | | | | ____|_|______\| |__________|__| | | |_____________| | /| 子供| | | 記述| |____________|____| | _____________ | 記述| | | | | | | |_________|___| | ____________V____ | 値| | | _____________ | |___________|_____| | | ストリング| |/___ オブジェクト| | |_____________| |\ | | | タイプ| | ___________V_____ |_________________| | | | 記述| | _____________ | | | | "ABC"| | _________________ | | |_____________| | | | | | _____________ | | _____________ | | | | "XY"| | | | M| | | | |_____________| | | |_____________| | | | _____________ | | 名前| | | | "ZLM"|/|___ | _____________ | | | |_____________|\| | | | ____|_|____| | : | | | |_____________| | | : | | | 記述| | _____________ | | | _____________ | | | "BBBF"| | |___|_|____ | | | |_____________| | | |_____________| | |_________________| | 値| 値|_________________| オブジェクト
Figure 4-8
LIST and member objects
図4-8 LISTとメンバーオブジェクト
Winter, Hill & Greiff [Page 55] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[55ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | L | | | | | |
| |_____________| | | |_____________| |
| NAME | | TYPE |
| _____________ | | _____________ |
| | ____|_|______\| | | |
| |_____________| | /| |__________|__| |
| DESCRIPTION | | CHILD | |
| _____________ | |____________|____|
| | | |/__ DESCRIPTION |
| |_________|___| |\ | ____________V____
| VALUE | | | | _____________ |
|___________|_____| | | | STRING | |/___
OBJECT | | | |_____________| |\ |
| | | TYPE | |
___________V_____ | |_________________| |
| _____________ | | DESCRIPTION |
| | "ABC" | | | _________________ |
| |_____________| | | | | |
| _____________ | | | _____________ | |
| | "XY" | | |___|_|____ | | |
| |_____________| | | |_____________| | |
| _____________ | | LIST | |
| | "ZLM" | | | _____________ | |
| |_____________| | | | | | |
| : | | |_________|___| | |
| : | | MEMBER | | |
| _____________ | | : | | |
| | "BBBF" |/|___ | : | | |
| |_____________|\| | |___________|_____| |
|_________________| | OPD | |
VALUE | ___________V_____ |
| | _____________ | |
| | | M | | |
| | |_____________| | |
| | NAME | |
| | _____________ | |
| | | ____|_|____|
| | |_____________| |
| | DESCRIPTION |
| | _____________ |
|___|_|____ | |
| |_____________| |
Figure 4-9 | VALUE |
OPD, LIST and member |_________________|
OBJECT
_________________ _________________ | _____________ | | _____________ | | | L| | | | | | | |_____________| | | |_____________| | | 名前| | タイプ| | _____________ | | _____________ | | | ____|_|______\| | | | | |_____________| | /| |__________|__| | | 記述| | 子供| | | _____________ | |____________|____| | | | |/__記述| | |_________|___| |\ | ____________V____ | 値| | | | _____________ | |___________|_____| | | | ストリング| |/___ 物| | | |_____________| |\ | | | | タイプ| | ___________V_____ | |_________________| | | _____________ | | 記述| | | "ABC"| | | _________________ | | |_____________| | | | | | | _____________ | | | _____________ | | | | "XY"| | |___|_|____ | | | | |_____________| | | |_____________| | | | _____________ | | リスト| | | | "ZLM"| | | _____________ | | | |_____________| | | | | | | | : | | |_________|___| | | | : | | メンバー| | | | _____________ | | : | | | | | "BBBF"|/|___ | : | | | | |_____________|\| | |___________|_____| | |_________________| | OPD| | 値| ___________V_____ | | | _____________ | | | | | M| | | | | |_____________| | | | | 名前| | | | _____________ | | | | | ____|_|____| | | |_____________| | | | 記述| | | _____________ | |___|_|____ | | | |_____________| | 図4-9| 値| OPD、LIST、およびメンバー|_________________| 物
Winter, Hill & Greiff [Page 56] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[56ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
The OPD establishes the object relationship, and contains information about the sequence of primitive listops in progress. When sufficient information is maintained in the OPD, we have in 4-9 a structure which is adequate for the maintenance of the integrity of the LIST and of the global list operation. In addition to LIST and member pointers, the OPD contains information indicating: (1) which suboperations are enabled for the sequence, (2) the current suboperation, (3) the instance number of the current LIST member, (4) an end-of-list indicator. The suboperations are add/member, delete/member, change/member and get/member. All apply to the current member. Only suboperations which have been enabled at the beginning of a sequence may be executed during that sequence; eventually, the advance knowledge of intentions that is implied by this will provide important information for concurrency control and optimization.
OPDは進行中の原始のlistopsの系列に関して物の関係を確立して、情報を含んでいます。 十分な情報がOPDで維持されるとき、私たちは4-9にLISTの保全とグローバルなリスト操作のメンテナンスのために適切な構造を持っています。 LISTとメンバーポインタに加えて、OPDは情報表示を含んでいます: (1) どの副操作が(4) 系列、(2) 現在の副操作、(3) 現在のLISTメンバーの例の番号、リストのエンドインディケータのために有効にされますか? 副操作はそうです。/メンバーを加えてください、そして、/メンバー、変化/メンバーを削除してください、そして、/メンバーを手に入れてください。 すべてが現在のメンバーに適用されます。 その系列の間、系列の始めに有効にされた副操作だけを実行してもよいです。 結局、これによって含意される意志に関する予備知識は合意コントロールと最適化のための重要情報を提供するでしょう。
Presently, an OPD relates a single member object to a single LIST object. This imposes an important restriction on the class of operation sequences which can be expressed. Any LIST transformation requiring simultaneous access to more than one member must be represented as more than one sequence. (And we do not yet solve the problems implied in concurrent execution of such sequences, even when both are controlled by one process.)
現在、OPDは単一のLIST物に単一のメンバー物に関連します。 これは表すことができる操作系列のクラスに重要な制限を課します。 1つ以上の系列として1人以上のメンバーへの同時アクセスを必要とするどんなLIST変化も表さなければなりません。 (そして、私たちはまだそのような系列の同時発生の実行で暗示している問題を解決していません、両方が1つの工程で制御さえされるとき。)
Any transformation of a LIST can still be achieved by storing intermediate results in temporary objects; however, it is certainly more desirable to incorporate the idea of multiple current members into the semantics of the language, than it is to use such temporaries. An important future extension of the listops will deal with this problem.
一時的な物に中間結果を格納することによって、まだLISTのどんな変化も達成できます。 しかしながら、確かに、複数の現在のメンバーの考えを言語の意味論に組み入れるのはそのようなtemporariesを使用することになっているより望ましいです、。 listopsの重要な今後の拡大はこの問題に対処するでしょう。
There are six listops: listop/begin, listop/end, which/member, end/of/list, open/member and close/member.
6listopsがあります: /が始めるlistop、listop/終わり、どの/メンバー、/リストの終わり/、戸外/メンバー、および閉鎖/メンバー。
Listop/begin and listop/end perform the obvious functions of beginning and terminating a sequence of listops. Listop/begin inputs LIST and member objects, an OPD, and a specification of suboperations to enable. It initializes the OPD, including establishment of the links to LIST and MEMBER objects. After the OPD-LIST-member relationship has been established, it is only necessary to supply the OPD and auxiliary parameters as input to a listop in the sequence. From the OPD everything else can be derived.
Listop/は始まります、そして、listop/終わりはlistopsの系列を始めて、終える明白な機能を実行します。 Listop/は有効にする副操作の入力LISTとメンバー物、OPD、および仕様を始めます。 それはLISTへのリンクとメンバー物の確立を含むOPDを初期化します。 OPD-LIST-メンバー関係が確立された後に、単に系列でlistopに入力されるOPDと補助のパラメタを提供するのが必要です。 OPDから、他の何もかもを引き出すことができます。
Listop/end clears the OPD and frees any resources acquired by listop/begin.
Listop/終わりは、OPDをきれいにして、/が始めるlistopによって取得されたどんなリソースも解放します。
Which/member establishes the current member for any suboperations. This is either the first LIST member, the last LIST member, or the next LIST member. This listop merely identifies which member is to be operated on; it does not make the contents of the member accessible.
どの/メンバーが何か副操作のために現在のメンバーを設立しますか? これは、第1代LISTメンバー、最後のLISTメンバーかLISTメンバーのどちらかです次期。 このlistopは、メンバーがどれに関して手術されることになっているかを単に特定します。 それで、メンバーのコンテンツはアクセスしやすくなりません。
Winter, Hill & Greiff [Page 57] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[57ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
Open/member and close/member bracket a suboperation. The suboperation is indicated as an argument to open/member. Open/member always establishes a pointer from the member object to the member value; close/member always clears this pointer. In addition, each of these listops may take some action, depending on the suboperation.
オープンな/メンバーと閉鎖/メンバーは副操作に腕木を付けます。 副操作は議論として戸外/メンバーに示されます。 オープンな/メンバーはメンバー物からメンバー値までポインタをいつも設立します。 閉鎖/メンバーはいつもこのポインタをきれいにします。 さらに、副操作によって、それぞれのこれらのlistopsは何らかの行動を取るかもしれません。
The details of the action would be dependent on the representation of the LIST in storage, the size of a LIST member, and choices made in implementation.
動作の詳細は格納における、LISTの表現、LISTメンバー、および実現でされた選択のサイズに依存しているでしょう。
Between execution of the open/member and the close/member, the data is accessible. It can always be read; in the case of the add/member and change/member suboperations, it can also be written into.
戸外/メンバーの実行と閉鎖/メンバーの間では、データはアクセス可能です。 いつもそれを読むことができます。 ケース、/メンバーと変化/メンバー副操作を加えてください、そして、また、それに書くことができます。
End/of/list tests a flag in the OPD and returns an object of type BOOL. The value of the object is the same as the value of the flag; it is TRUE if a get/member, change/member or delete/member would be unsuccessful due to a which/member having moved "beyond the end". T his listop is provided so that it is possible to write procedures which terminate conditionally when all members have been processed.
/リストの終わり/は、OPDの旗を検査して、タイプブールの物を返します。 物の値は旗の値と同じです。 TRUEがaであるなら/メンバー、変化/メンバーを得るか、または/メンバー有が動かしたaへの失敗の支払われるべきものが「終わり」であったなら/メンバーを削除するということです。 彼のlistopがすべてのメンバーが処理されたとき条件付きに終わる手順を書くのが可能であるように提供されるT。
Get/struct/member provides the ability to handle STRUCTs. Given a STRUCT object which points to the STRUCT value, it will establish a pointer from a given member object to the member value. (The pointer it establishes is represented by a dashed line in figure 4-10).
struct/メンバーがSTRUCTsを扱う能力を提供する/を手に入れてください。 STRUCT値を示すSTRUCT物を考えて、それは与えられたメンバー物からメンバー値までポインタを設立するでしょう。 (それが設立するポインタは図4-10の投げつけられた線によって表されます。)
Winter, Hill & Greiff [Page 58] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[58ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | F | | | | STRUCT | |
| |_____________| | | |_____________| |
| NAME | | TYPE |
| _____________ | | _____________ |
| | ____|_|______\| | | |
| |_____________| | /| |__________|__| |
| DESCRIPTION | | CHILD | |
| _____________ | |____________|____|
| | | | DESCRIPTION |
| |___________|_| | ____________V____ _________________
| VALUE | | | _____________ | | _____________ |
| ___________|_ | | | STRING | | | | STRING | |
| | | | | | |_____________| | | |_____________| |
| |_________|_|_| | | TYPE | | TYPE |
| CHILD | | | | _____________ | | _____________ |
|___________|_|___| ____\| | | | | | | |
OBJECT | | | /| |_____________| | | |_____________| |
| | | | SIBLING | | SIBLING |
| | | |_________________| |_________________|
| | | DESCRIPTION DESCRIPTION A
| | | ______________________________________ |
| | | | ____________ ____________ | |
| | | | | "ABC" | | FALSE | | |
| |_____|_____| |____________| |____________| | |
| | |________A_____________________________| |
| | ............: VALUE |
___________V_____ | : _________________ |
| _____________ | | : | _____________ | |
| | A | | | : | | B | | |
| |_____________| | | : | |_____________| | |
| NAME | | : | NAME | |
| _____________ | | : | _____________ | |
| | ____|_|_| : | | ____|_|_______________________|
| |_____________| | : | |_____________| |
| DESCRIPTION | : | DESCRIPTION |
| _____________ | : | _____________ |
| | ....|.|....: | | | |
| |_____________| | | |_____________| |
| VALUE | | VALUE |
| _____________ | | _____________ |
| | ____|_|______\| | | |
| |_____________| | /| |_____________| |
| SIBLING | | SIBLING |
|_________________| |_________________| Figure 4-10
OBJECT OBJECT Effect of GET/STRUCT/MEMBER
_________________ _________________ | _____________ | | _____________ | | | F| | | | STRUCT| | | |_____________| | | |_____________| | | 名前| | タイプ| | _____________ | | _____________ | | | ____|_|______\| | | | | |_____________| | /| |__________|__| | | 記述| | 子供| | | _____________ | |____________|____| | | | | 記述| | |___________|_| | ____________V____ _________________ | 値| | | _____________ | | _____________ | | ___________|_ | | | ストリング| | | | ストリング| | | | | | | | |_____________| | | |_____________| | | |_________|_|_| | | タイプ| | タイプ| | 子供| | | | _____________ | | _____________ | |___________|_|___| ____\| | | | | | | | 物| | | /| |_____________| | | |_____________| | | | | | 兄弟| | 兄弟| | | | |_________________| |_________________| | | | 記述記述A| | | ______________________________________ | | | | | ____________ ____________ | | | | | | | "ABC"| | 誤る| | | | |_____|_____| |____________| |____________| | | | | |________A_____________________________| | | | ............: 値| ___________V_____ | : _________________ | | _____________ | | : | _____________ | | | | A| | | : | | B| | | | |_____________| | | : | |_____________| | | | 名前| | : | 名前| | | _____________ | | : | _____________ | | | | ____|_|_| : | | ____|_|_______________________| | |_____________| | : | |_____________| | | 記述| : | 記述| | _____________ | : | _____________ | | | ....|.|....: | | | | | |_____________| | | |_____________| | | 値| | 値| | _____________ | | _____________ | | | ____|_|______\| | | | | |_____________| | /| |_____________| | | 兄弟| | 兄弟| |_________________| |_________________| 4-10 物の物の効果について計算する、/STRUCT/メンバーを手に入れてください。
Winter, Hill & Greiff [Page 59] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[59ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
The primitives discussed so far (assign, listops, and get/struct/member) provide a basic facility for operating on structures of LISTs, STRUCTs and elementary items. Using only them, it is possible to transfer the contents of one hierarchical structure to another, to append structures, to delete portions of structures, and so on. To perform more interesting operations facilities for control and selection are needed.
今までのところ(/struct/メンバーを割り当てて、listopsして、得る)議論している基関数はLISTs、STRUCTs、および基本項目の構造を作動させるのに基本的な施設を提供します。それらだけを使用して、ある階層構造のコンテンツを別のものに移して、構造を追加して、構造などの部分を削除するのは可能です。 働くために、コントロールと選択のための、よりおもしろい操作施設が必要です。
A rudimentary control facility is provided through the primitives if/then, if/then/else, till and while. All of these evaluate one primitive function call, which must return a BOOL. Based on the value of this BOOL some action is taken.
そして、/であるなら当時の、または、ほかの/、そして、現金箱であるなら基関数を通して初歩的な制御機能を提供する、ゆったり過ごします。 これらはすべて、1つの原始のファンクションコールを評価します。(それは、ブールを返さなければなりません)。 このブールの値に基づいて、何らかの行動を取ります。
Let A and B be function calls. If/then(A,B) will execute B if A returns TRUE. If/then/else(A,B,C) will execute B if A returns TRUE; it will execute C if A returns FALSE. The while and till operators iterate, executing first A then B. While terminates the loop when A returns FALSE; till terminates the loop when A returns TRUE. If this happens the first time, B is never executed.
AとBがファンクションコールであることをさせてください。 /であるなら、AがTRUEを返すと、(A、B)はBを実行するでしょう。 AがTRUEを返すと当時の、または、ほかの/(A、B、C)がBを実行するなら。 AがFALSEを返すと、それはCを実行するでしょう。 そして、AがFALSEを返すとき、最初Aの当時のB.Whileを実行して、オペレータが繰り返す現金箱は輪を終えます。 AがTRUEを返すとき、現金箱は輪を終えます。 これが1回目に起こるなら、Bは決して実行されません。
So far, we have mentioned one function which returns a BOOL: the listop, end/of/list. Two other classes of functions which have this property are the booleans and the comparisons. There are 3 primitive booleans (and, or, not) and six primitive comparisons (equal, less/than, greater/than, not/equal, less/than/or/equal, greater/than/or/equal -- only equal is implemented at time of publication).
今までのところ、私たちはブールを返す1つの機能について言及しました: listop、/リストの終わりの/。 この特性を持っている他の2つのクラスの関数は、論理演算子と比較です。 そして、3つの原始の論理演算子がある、()、6つの原始の比較、(等しくて、より少ない/、同輩だけよりすばらしい/が公表の時に実行される、)
The booleans input and output BOOLs; the comparisons input pairs of elementary objects having the same description and output BOOLs. Expressions composed of booleans and comparisons on item contents are one of the principal tools used in selectively referencing data in data management systems.
論理演算子はBOOLsを入出力します。 比較は同じ記述と出力BOOLsを持っている組の基本の物を入力しました。 項目コンテンツで論理演算子と比較で構成された表現はデータ管理システムで選択的にデータに参照をつける際に使用される主要なツールの1つです。
With the booleans, the comparisons, and the primitives identified earlier, we can perform selective "retrievals". That is, we can transfer to LIST B all items in LIST A having a value of 'ABC'. In fact, we now have a (semantically) general ability to perform content- based retrievals and updates on arbitrary hierarchical structures. We can even program something as complex as the processing of a list of transactions against a master list, which is one of the typical applications in business data processing.
論理演算子、比較、および、より早く特定された基関数で、私たちは選択している"retrievals"を実行できます。 すなわち、私たちは、'ABC'の値を持ちながら、LIST Aですべての商品をLIST Bに移すことができます。 事実上、私たちには、現在、任意の階層構造に関する(意味的に)一般的な履行能力の満足しているベースのretrievalsと最新情報があります。 私たちは事務データ処理における主用途の1つであるマスターリストに対して取引のリストの処理と何か同じくらい複雑なものをプログラムさえできます。
Of course, we would not expect users of datalanguage to express requests at the level of listops. Further, the listops defined here are not a very efficient way of performing some of the tasks we have mentioned. To get good solutions, we need both higher-level operators and other primitives which use other techniques in processing.
もちろん、私たちはdatalanguageのユーザがlistopsのレベルで要求を言い表すと予想しないでしょう。 さらに、ここで定義されたlistopsは私たちが言及したタスクのいくつかを実行する非常に効率的な方法ではありません。 良い解決策を得るために、私たちは処理に他のテクニックを使用するよりハイレベルのオペレータと他の基関数の両方を必要とします。
In addition to those already discussed, the model contains functions
既に議論したものに加えて、モデルは機能を含んでいます。
Winter, Hill & Greiff [Page 60] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[60ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
for: (1) referencing an object by qualified name, (2) generating a constant, (3) generating data descriptions, (4) writing compound functions and blocks with local variables, (5) creating objects.
: (1) 適切な名前の物に、(2) (3) (4) (5) 物を作成して、局所変数で合成機能とブロックを書いて、データ記述を発生させて、定数を発生させて、参照をつけます。
The facilities for generating constants and data descriptions (which are a special case of constants) are marginal, and have no features of special interest. Obviously, data description will be an important concern in the modeling effort later on.
定数とデータ記述(定数の特別なケースである)を発生させるための施設は、マージンであり、特別に関心の特徴を全く持っていません。 後で、明らかに、データ記述はモデルの努力で重要な関心になるでしょう。
Object referencing functions permit reference to t/objects and p/objects (these terms are defined in 4.6). A p/object is referenced by giving the pathname from STAR to it. A t/object is referenced by giving the pathname from the block directory in which it is defined to it.
物の参照箇所機能はt/物とp/物の参照を可能にします(これらの用語は4.6で定義されます)。 STARからそれまでパス名を与えることによって、p/物は参照をつけられます。 それがそれと定義されるブロックディレクトリからパス名を与えることによって、t/物は参照をつけられます。
Compound/function permits a sequence of function calls to be treated syntactically as a single call. Thus, for example, in if/then(A,B), B is frequently a call to compound/function, which in turn calls a sequence of other functions.
化合物/機能は、ファンクションコールの系列がシンタクス上ただ一つの呼び出しとして扱われることを許可します。 (A、B)、/であるなら、頻繁にBはその結果、例えば、そして、中では、aです。化合物/機能(順番に他の機能の系列を呼ぶもの)に呼びかけてください。
Create takes two inputs: a superior object and a description. The superior must be a directory. The new object is created as the leftmost child of the directory; its name is determined by the description.
2が入力する撮影を作成してください: 優れた物と記述。 上司はディレクトリであるに違いありません。 新しい物はディレクトリの一番左子供として作成されます。 名前は記述で決定します。
4.8 Details of primitive language functions
原始の言語の4.8の詳細が機能します。
This section provides specifications for the primitives discussed in the previous section. We are still omitting details when we judge them to be of no general interest; the objective is to provide enough information for the reader to examine examples.
このセクションは前項で議論した基関数のための仕様を提供します。 それらが一般的興味の全くものでないと判断するとき、私たちはまだ詳細を省略しています。 目的は読者が例を調べることができるくらいの情報を提供することです。
Most of the primitives occur at two levels in the model. The internal primitives are called i/functions and the external, or language primitives are called l/functions. The relationship between the two types are explained in 4.9. In this section we discuss i/functions.
基関数の大部分はモデルの2つのレベルで現れます。 内部の基関数はi/機能と呼ばれます、そして、外部か言語基関数はl/機能と呼ばれます。 4.9では、説明されます2つの間の関係が、タイプする。 このセクションで、私たちはi/機能について議論します。
L/functions input and output _forms_, which are tree structures whose terminal nodes are atoms. The atoms are such things as function names, object names, literal string constants, truth va1ues and delimiters. Calls to i/functions are also expressed as forms.
L/機能は_フォーム_を入出力します。(_は端末のノードが原子である木構造です)。原子は機能名、オブジェクト名、文字通りのストリング定数、真実va1ues、およびデリミタのようにものです。 また、i/機能への呼び出しはフォームとして言い表されます。
Any form can be evaluated, yielding some object. A form which is an i/function call yields the value returned by the i/function: another form. In general, the form returned by an i/function call will, when evaluated, yield a datalanguage object (that is, the sort of object we have been represented by an "object box" in the drawings).
ある物をもたらして、どんなフォームも評価できます。 i/ファンクションコールであるフォームはi/機能によって返された値をもたらします: 別のフォーム。 一般に、評価されると、i/ファンクションコールで返されたフォームはdatalanguage物をもたらすでしょう。(それがそう、種類、物では、私たちが図面で「物の箱」によって代理をされた、)
Winter, Hill & Greiff [Page 61] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[61ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
4.8.1 Name recognition functions
4.8.1 知名度機能
These return a form which evaluates to an object.
aはどれを形成するか。これらが戻る、物に評価します。
L/TOBJ
L/TOBJ
Input must name a temporary object subordinate either to TOP/LEVEL or a block directory.
入力は一時的な物の部下をTOP/LEVELかブロックディレクトリに任命しなければなりません。
L/POBJ
L/POBJ
Input must name a permanent object (i.e., an object subordinate to STAR).
入力は永続オブジェクト(すなわち、STARの物の部下)を命名しなければなりません。
Typical calls are L/POBJ(X.Y.Z) and L/TOBJ(A).
典型的な呼び出しは、L/POBJ(X.Y.Z)とL/TOBJ(A)です。
4.8.2 Constant generators
4.8.2 一定のジェネレータ
Each of these inputs an atomic symbol yielding a value for a constant to be created. Each returns a form which will evaluate to an object having the specified value and an appropriate description.
それぞれのこれらは定数が作成されるために値をもたらす元素記号を入力します。 それぞれが規定値を持って、適切な記述を物に評価するフォームを返します。
LC/STRING - a typical call is LC/STRING('ABC')
LC/STRING--典型的な呼び出しはLC/STRINGです。('ABC')
LC/BOOL - a typical call is LC/BOOL(TRUE)
LC/ブール--典型的な呼び出しはLC/ブールです。(本当に)
4.8.3 Elementary item functions
4.8.3 基本項目機能
These input and output forms evaluating to elementary objects (objects which can have no subordinate object -- in effect, objects whose value is regarded as atomic). Eventually all the comparison operators will be implemented.
これらは物(下位オブジェクトを全く持つことができない物--事実上、値が原子と見なされる物)を基本に評価するフォームを入出力します。 結局、すべての比較オペレータが実行されるでしょう。
L/ASSIGN
/が割り当てるL
Inputs must evaluate either to STRINGs or BOOLs. Outputs a form which
transfers the value of the second to the first. Typical call:
L/ASSIGN(L/TOBJ(A),LC/STRING('XYZ'))
The output form, when evaluated, will copy 'XYZ' into A's value.
入力はSTRINGsかBOOLsにどちらかを評価しなければなりません。 1日への2番目の値を移すフォームを出力します。 典型的な呼び出し: 評価されると、出力が形成するL/ASSIGN(L/TOBJ(A)、LC/STRING('XYZ'))は'XYZ'をAの値にコピーするでしょう。
L/EQUAL
L/同輩
Inputs a pair of forms evaluating to objects, which must have identical descriptions and be BOOLs or STRINGs. Returns a form evaluating to an object of type BOOL. Value of this object is TRUE if inputs have identical descriptions and values; otherwise it is false. Typical call:
フォームの目的に関する評価かSTRINGsの1組を入力します。目的は、同じ記述を持って、BOOLsであるに違いありません。 タイプの物にブールを評価するフォームを返します。 入力に同じ記述と値があるなら、この物の値はTRUEです。 さもなければ、それは誤っています。 典型的な呼び出し:
Winter, Hill & Greiff [Page 62] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[62ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
L/EQUAL(L/TOBJ(X),LC/STRING('DEF'))
L/同輩(L/TOBJ(X)、LC/ストリング('クールな'))
L/AND, L/OR, L/NOT
L/AND、L/OR、L/NOT
The standard boolean operators. Inputs are forms evaluating to BOOLs;
output is a form evaluating to a BOOL. L/AND and L/OR take two inputs;
L/NOT one. Typical call:
L/AND( L/EQUAL(L/TOBJ(X),LC/STRING('DEF')),
L/EQUAL(T/TOBJ(Y),LC/STRING('GHI')) )
The form returned will, when evaluated, return TRUE if both X has value
'DEF' and Y has value 'GHI'.
標準の論理演算子オペレータ。 入力はBOOLsに評価するフォームです。 出力はブールに評価するフォームです。 L/ANDとL/ORは2つの入力を取ります。 1ではなく、L/。 典型的な呼び出し: フォームが返した(L/EQUAL(L/TOBJ(X)、LC/STRING('DEF'))、L/EQUAL(T/TOBJ(Y)、LC/STRING('GHI')))がそうするL/AND、評価のリターンTRUEであるときに、Xには、値の'DEF'が両方であるならあります、そして、Yには、値の'GHI'があります。
4.8.4 Data description functions
4.8.4 データ記述機能
These all return a form evaluating to a description (i.e. that which is represented in our drawings by a box labeled "description").
これらはすべて、(すなわち、私たちの図面に「記述」とラベルされた箱によって表されるそれ)を記述に評価するフォームを返します。
LD/STRING
LD/ストリング
Inputs 3 parameters specifying the name, size option and size for the
string. Typical call:
LD/STRING(X,FIXED,3)
This call returns a form evaluating to a description for a fixed-length
3-character string named X.
名前、サイズオプション、およびサイズをストリングに指定する入力3パラメタ。 典型的な呼び出し: この呼び出しが固定長の3文字列のための記述に評価するフォームを返すLD/STRING(X、FIXED、3)はXを命名しました。
LD/LIST
LD/リスト
Inputs two forms. The first is the name of the LIST and the second
evaluates to a description of the LIST member. Typical call:
LD/LIST(L,LD/STRING(M,FIXED,3))
Creates the structure shown in figure 4-11, and returns a form
evaluating to the description represented by the upper box.
入力twoは形成されます。1番目はLISTという名前です、そして、2番目はLISTメンバーの記述をaに評価します。 典型的な呼び出し: LD/LIST(L、LD/STRING(M、FIXED、3))は図4-11に示された構造を作成して、記述に関する評価が上側の箱で表した書式を返します。
Winter, Hill & Greiff [Page 63] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[63ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________
| _____________ |
| | L | |
| |_____________| |
| NAME |
| _____________ |
| | LIST | |
| |_____________| |
| TYPE |
| _____________ |
| | | |
| |________|____| |
| CHILD | |
|__________|______|
DESCRIPTION |
|
__________V______
| _____________ |
| | M | |
| |_____________| |
| NAME |
| _____________ |
| | STRING | |
| |_____________| |
| TYPE |
| _____________ |
| | _________ | |
| | | FIXED | | |
| | |_________| | |
| | _________ | |
| | | 3 | | |
| | |_________| | |
| |_____________| |
| PARAMETERS |
|_________________|
DESCRIPTION
_________________ | _____________ | | | L| | | |_____________| | | 名前| | _____________ | | | リスト| | | |_____________| | | タイプ| | _____________ | | | | | | |________|____| | | 子供| | |__________|______| 記述| | __________V______ | _____________ | | | M| | | |_____________| | | 名前| | _____________ | | | ストリング| | | |_____________| | | タイプ| | _____________ | | | _________ | | | | | 修理されています。| | | | | |_________| | | | | _________ | | | | | 3 | | | | | |_________| | | | |_____________| | | パラメタ| |_________________| 記述
Figure 4-11
LIST and member descriptions
図4-11 LISTとメンバー記述
LD/STRUCT
LD/STRUCT
Inputs a form to use as the name for the STRUCT and one or more forms evaluating to descriptions; these are taken as the descriptions of the members. Typical call:
STRUCTと1つかその他のための名前が記述に関する評価を形成するとき、使用する書式を入力します。 これらはメンバーの記述としてみなされます。 典型的な呼び出し:
Winter, Hill & Greiff [Page 64] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[64ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
LD/STRUCT(R,
LD/STRING(A,FIXED,3)
LD/BOOL(B) )
produces the structure shown in 4-12; returns a form evaluating to the
top box.
LD/STRUCT、(R、LD/STRING(A、FIXED、3)LD/ブール(B) )は4-12で見せられた構造を発生させます。 最高箱に評価するフォームを返します。
_________________
| _____________ |
| | R | |
| |_____________| |
| NAME |
| _____________ |
| | STRUCT | |
| |_____________| |
| TYPE |
| _____________ |
| | | |
| |_________|___| |
| CHILD | |
|___________|_____|
DESCRIPTION |
|
___________V_____
| _____________ |
| | A | |
| |_____________| |
| NAME |
| _____________ |
| | STRING | |
| |_____________| |
| TYPE | _________________
| _____________ | | _____________ |
| | | | | | B | |
| |_____________| | | |_____________| |
| PARAMETER | | NAME |
| _____________ | | _____________ |
| | ____|_|______\| | BOOL | |
| |_____________| | /| |_____________| |
| SIBLING | | TYPE |
|_________________| |_________________|
DESCRIPTION DESCRIPTION
_________________ | _____________ | | | R| | | |_____________| | | 名前| | _____________ | | | STRUCT| | | |_____________| | | タイプ| | _____________ | | | | | | |_________|___| | | 子供| | |___________|_____| 記述| | ___________V_____ | _____________ | | | A| | | |_____________| | | 名前| | _____________ | | | ストリング| | | |_____________| | | タイプ| _________________ | _____________ | | _____________ | | | | | | | B| | | |_____________| | | |_____________| | | パラメタ| | 名前| | _____________ | | _____________ | | | ____|_|______\| | ブール| | | |_____________| | /| |_____________| | | 兄弟| | タイプ| |_________________| |_________________| 記述記述
Figure 4-12
STRUCT and member descriptions
図4-12 STRUCTとメンバー記述
Winter, Hill & Greiff [Page 65] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[65ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
LD/BOOL, LB/DIR, LD/OPD, LD/FUNC, LD/DESC
LD/ブール、lb/ディルLD/OPD、LD/FUNC、LD/DESC
Each inputs a name and produces a single description; each returns a
form evaluating to the description produced. Typical call:
LD/BOOL(X)
それぞれが、名前を入力して、ただ一つの記述を起こします。 それぞれが記述に関する評価が製作したフォームを返します。 典型的な呼び出し: LD/ブール(X)
4.8.5 Data creation
4.8.5 データ作成
L/CREATE
L/は作成します。
Inputs two forms and evaluates them. First must yield an object of type
DIR; second must yield a description for the object to be created.
Creates the object and returns a form, which, when evaluated, will
generate a value for the new object. A simple example:
L/CREATE(L/TOBJ(X),LD/B0OL(Y))
2つの書式を入力して、それらを評価します。 1番目はタイプDIRの物をもたらさなければなりません。 2番目は、物が作成されるために記述をもたらさなければなりません。 物を作成して、フォームを返します。(評価されると、それは、新しい物のために値を発生させるでしょう)。 簡単な例: L/は作成します。(L/TOBJ(X)、LD/B0OL(Y))
Figure 4-13 shows the directory X before execution of the above call. It contains only an OPD. After execution, the directory appears as in 4- 14. Creation of a value for Y occurs when the form returned by L/CREATE is evaluated (covered in section 4.9).
図4-13は上の呼び出しの実行の前にディレクトリXを示しています。 それはOPDだけを含んでいます。 実行の後に、ディレクトリは4- 14のように見えます。 L/CREATEによって返されたフォームが評価されるとき(セクション4.9では、覆われます)、Yのための価値の創造は起こります。
Winter, Hill & Greiff [Page 66] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[66ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________
| |
| _____________ |
| | X | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | DIR | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | | | DESCRIPTION
| |_________|___| |
| CHILD | |
|___________|_____|
OBJECT |
|
|
___________V_____
| |
| _____________ |
| | Z | |
| |_____________| |
| NAME | ____________
| _____________ | | ________ |
| | ____|_|______\| | OPD | |
| |_____________| | /| |________| |
| DESCRIPTION | | TYPE |
| _____________ | |____________|
| | | | DESCRIPTION
| |_________|___| |
| VALUE | | ____________
|___________|_____| | |
OBJECT |____________\| |
/|____________|
OPD
_________________ | | | _____________ | | | X| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | ディル| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | | | 記述| |_________|___| | | 子供| | |___________|_____| 物| | | ___________V_____ | | | _____________ | | | Z| | | |_____________| | | 名前| ____________ | _____________ | | ________ | | | ____|_|______\| | OPD| | | |_____________| | /| |________| | | 記述| | タイプ| | _____________ | |____________| | | | | 記述| |_________|___| | | 値| | ____________ |___________|_____| | | 物|____________\| | /|____________| OPD
Figure 4-13
X and Z before creation of Y
図4-13 Yの創造の前のXとZ
Winter, Hill & Greiff [Page 67] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[67ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________
| _____________ |
| | X | |
| |_____________| | _________________
| NAME | | _____________ |
| _____________ | | | DIR | |
| | ____|_|______\| |_____________| |
| |_____________| | /| TYPE |
| DESCRIPTION | |_________________|
| _____________ | DESCRIPTION
| | | |
| |_________|___| |
| VALUE | |
|___________|_____|
OBJECT |
___________V_____
| _____________ |
| | Y | |
| |_____________| | _________________
| NAME | | _____________ |
| _____________ | | | BOOL | |
| | ____|_|______\| |_____________| |
| |_____________| | /| TYPE |
| DESCRIPTION | |_________________|
| _____________ | DESCRIPTION
| | | |
| |_____________| |
| VALUE |
| _____________ |
| | ____|_|______________
| |_____________| | |
| SIBLING | |
|_________________| ______V__________ _________________
OBJECT | _____________ | | _____________ |
| | Z | | | | OPD | |
| |_____________| | __\| |_____________| |
| NAME | | /| TYPE |
| _____________ | | |_________________|
| | ____|_|___| DESCRIPTION
| |_____________| |
| DESCRIPTION |
| _____________ | _________________
| | ____|_|______\| |
Figure 4-14 | |_____________| | /|_________________|
X, Y, and Z after | VALUE | OPD
L/CREATE |_________________|
OBJECT
_________________ | _____________ | | | X| | | |_____________| | _________________ | 名前| | _____________ | | _____________ | | | ディル| | | | ____|_|______\| |_____________| | | |_____________| | /| タイプ| | 記述| |_________________| | _____________ | 記述| | | | | |_________|___| | | 値| | |___________|_____| 物| ___________V_____ | _____________ | | | Y| | | |_____________| | _________________ | 名前| | _____________ | | _____________ | | | ブール| | | | ____|_|______\| |_____________| | | |_____________| | /| タイプ| | 記述| |_________________| | _____________ | 記述| | | | | |_____________| | | 値| | _____________ | | | ____|_|______________ | |_____________| | | | 兄弟| | |_________________| ______V__________ _________________ 物| _____________ | | _____________ | | | Z| | | | OPD| | | |_____________| | __\| |_____________| | | 名前| | /| タイプ| | _____________ | | |_________________| | | ____|_|___| 記述| |_____________| | | 記述| | _____________ | _________________ | | ____|_|______\| | 図4-14| |_____________| | /|_________________| X、Y、および後のZ| 値| OPD L/は作成します。|_________________| 物
Winter, Hill & Greiff [Page 68] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[68ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
4.8.6 Control
4.8.6 コントロール
L/IF/THEN, L/IF/THEN/ELSE
L/、当時の/L/である、当時の、または、ほかの/です。
Used to request conditional evaluation of a form. Typical call:
L/IF/THEN(L/EQUAL(L/TOBJ(A),LC/STRING('ABC'),
L/ASSIGN(L/TOBJ(B),LC/STRING('DE')))
The form returned will do the following, when evaluated: if A has value
'ABC', then store 'DE' in the value of B.
形式の条件付きの評価を要求するのにおいて、使用されています。 典型的な呼び出し: L/、/THENである、(フォームが返したL/EQUAL(L/TOBJ(A)、LC/STRING('ABC')L/ASSIGN(TOBJ(B)、LC/STRING L/('DE')))は以下をするでしょう、評価されると: Aに値の'ABC'があるなら、Bの値に'DE'を格納してください。
L/WHILE, L/TILL
L/がゆったり過ごす、L/現金箱
These iterate conditionally, as explained in the previous section. Examples appear later.
これらは前項で説明されるように条件付きに繰り返します。 例は後で現れます。
L/CF
L/Cf
Compound function: it inputs one or more forms and returns a form which,
when evaluated, will evaluate each input in sequence. Typical call:
L/CF(L/ASSIGN(L/TOBJ(R.A),LC/STRING('XX')),
L/ASSIGN(L/TOBJ(R.B),LC/STRING('YY')))
When the output of L/CF is evaluated, it will assign new values to R.A
and R.B.
機能を合成してください: それは、1つ以上の書式を入力して、評価されると連続して各入力を評価するフォームを返します。 典型的な呼び出し: L/CFの出力であるときに、L/CF(L/ASSIGN(L/TOBJ(R.A)、LC/STRING('XX'))、L/ASSIGN(L/TOBJ(R.B)、LC/STRING('YY')))は評価されて、それはR.AとR.Bに新しい値を割り当てるでしょう。
4.8.7 Listops
4.8.7 Listops
These primitives are executed in sequences in order to perform operations on LISTs. With the exception of L/END/OF/LIST these functions output forms which are evaluated for effect only; that is, the output forms do not themselves return values.
これらの基関数は、LISTsに操作を実行するために系列で実行されます。 L/END/OF/LISTを除いて、これらの機能は効果だけのために評価されるフォームを出力しました。 すなわち、出力フォームはリターン値を自分たちにするというわけではありません。
L/LISTOP/BEGIN
L/LISTOP/は始まります。
Inputs forms evaluating to: (1) a LIST, (2) an object to represent the
current LIST member, (3) an OPD. Also, inputs a list of atomic forms
whose values are taken as suboperations to enable. Typical call:
L/LISTOP/BEGIN(L/POBJ(F),L/TOBJ(R),
L/TOBJ(OPF),ADD,DELETE)
This returns a form that will initialize a sequence of listops to be
performed on F. Caller has previously created R and OPF. He intends to
ADD and DELETE list members.
入力は以下のことのために評価を形成します。 (1) (2) LIST、(3) 現在のLISTメンバー、OPDを表す物。 aが可能にするために値が副操作としてみなされる原子フォームについてリストアップする入力も。 典型的な呼び出し: これがF.Callerに実行されるためにlistopsの系列を初期化するフォームを返すL/LISTOP/BEGIN(L/POBJ(F)、L/TOBJ(R)、L/TOBJ(OPF)、ADD、DELETE)は以前に、RとOPFを作成しました。 彼はADDとDELETEリストにメンバーを意図します。
All subsequent calls in this sequence of listops need specify only the OPD and auxiliary parameters.
listopsのこの系列におけるその後の呼び出しが必要とするすべてがOPDと補助のパラメタだけを指定します。
Winter, Hill & Greiff [Page 69] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[69ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
L/LISTOP/END
L/LISTOP/終わり
Inputs a form evaluating to an OPD. Outputs a form which, when evaluated, clears OPD and breaks relationships between OPD, LIST and member objects.
OPDに評価する書式を入力します。 評価されるとOPDをきれいにして、OPDと、LISTとメンバー物との関係を壊すフォームを出力します。
L/WHICH/MEMBER
L/はどの/メンバーであるか。
Inputs two forms. First evaluates to an OPD; second is one of FIRST,
LAST, NEXT. The form output, when evaluated, will establish a new
current member for the next suboperation. Note: this does not make the
value of the member accessible, it simply identifies it by setting the
instance number in the OPD. A typical call:
L/WHICH/MEMBER(L/TOBJ(OPF),NEXT)
When a which/member causes advance beyond the end of the list, a flag is
set in the OPD.
入力twoフォーム最初に、OPDに評価します。 2番目に、FIRSTの1つ、LAST、ネクストはあります。 評価されると、フォーム出力は次の副操作のために新しい現在のメンバーを設立するでしょう。 以下に注意してください。 これで、メンバーの値はアクセスしやすくならないで、それは、例の番号をOPDにはめ込むことによって、単にそれを特定します。 典型的な呼び出し: どの/メンバー原因であるかときに、L/WHICH/メンバー(L/TOBJ(OPF)、ネクスト)はリストの終わりを超えたところまで進んで、旗はOPDに設定されます。
L/END/OF/LIST
/リストのL/終わりの/
Inputs a form evaluating to an OPD. Outputs a form which, when evaluated, returns a BOOL. This has value TRUE if the end of list flag in the OPD is on.
OPDに評価する書式を入力します。 評価されるとブールを返すフォームを出力します。 これには、OPDのリスト旗の端がオンであるなら、値のTRUEがあります。
L/OPEN/MEMBER
L/戸外/メンバー
Inputs a form evaluating to an OPD and a form which must be one of ADD,
DELETE, GET, CHANGE. Outputs a form which, when evaluated, will
initiate the requested suboperation on the current LIST member. The
suboperation always establishes the pointer from the member object to
the current member value instance. In addition, in the case of ADD this
value must be created. Typical call:
L/OPEN/MEMBER (L/TOBJ (OPF) ,ADD)
どれがADDの1つ、DELETE、GET、CHANGEであるに違いないかをOPDと用紙に評価する書式を入力します。 評価されると現在のLISTメンバーの上で要求された副操作を開始するフォームを出力します。 副操作はメンバー物から現在のメンバー値の例までポインタをいつも設立します。 さらに、ADDの場合では、この値を作成しなければなりません。 典型的な呼び出し: L/戸外/メンバー(L/TOBJ(OPF)、加えてください)
L/CLOSE/MEMBER
L/閉鎖/メンバー
Inputs a form evaluating to an OPD. Outputs a form which, when
evaluated, will complete the suboperation in progress. A typical call:
L/CLOSE/MEMBER(L/TOBJ(OPF))
Always clears the pointer from member object to member value. In
addition, in the case of DELETE, removes the member value from the LIST.
In the case of ADD enters the member value in the LIST. Makes the
member added the current member, so that a sequence of ADDs executed
without intervening which/members will add the new members in sequence.
OPDに評価する書式を入力します。 評価されると進行中の副操作を完成するフォームを出力します。 典型的な呼び出し: L/CLOSE/メンバー(L/TOBJ(OPF))はメンバー物からメンバー値までポインタをいつもきれいにします。 中に、DELETEの場合では、添加はメンバー値をLISTから移します。中では、ADDに関するケースは. 現在のメンバー、ADDsの系列がどの/メンバーに介入しないで実行したメンバーの加えられたそうがそうする造が、新しいメンバーが中で配列すると言い足すLISTにメンバー値を入れます。
An elaborate example, involving listops and several other primitives, appears in section 4.10.
listopsと他のいくつかの基関数にかかわって、入念な例はセクション4.10に現れます。
Winter, Hill & Greiff [Page 70] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[70ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
4.9 Execution cycle
4.9 実行サイクル
The model datacomputer has a two-part execution cycle: it first compiles requests, then interprets them. A "request" is an l/function call; "compilation" is the aggregate result of executing all the l/function calls involved in the request (typically this is many calls, as there are usually several levels of nested calls, with the results of the inner calls being delivered as arguments to the next level of calls). Usually, the process of executing an l/function involves a simple macro expansion, preceded by some binding, checking and (eventually) optimization.
モデルdatacomputerには、2部分の実行サイクルがあります: それは、最初に、要求をコンパイルして、次に、それらを解釈します。 「要求」はl/機能呼び出しです。 「編集」は要求にかかわるすべてのl/ファンクションコールを実行するという集合結果(これは通常、多くの呼び出しです、いくつかのレベルの入れ子にされた呼び出しが通常あるとき、議論として内側の呼び出しの結果を呼び出しの次のレベルに送って)です。 通常、l/機能を実行する過程は何らかの結合、照合、および(結局)の最適化で先行された簡単なマクロ展開を伴います。
The compiled form consists wholly of atomic symbols and i/function calls. The i/functions are internal primitives which input and output datalanguage objects (the entities represented by the boxes labeled "object" in the drawings).
コンパイルされたフォームは元素記号とi/ファンクションコールから完全に成ります。 i/機能はdatalanguage物(図面を「物」とラベルされた箱によって表された実体)を入出力する内部の基関数です。
Each of the l/functions discussed compiles into a single i/function; thus the macro expansion aspect of compilation is presently trivial. However, this will not be true in general; it is only that these are _primitive_ l/functions that makes it true now.
それぞれ議論したl/機能はただ一つのi/機能にコンパイルされます。 したがって、編集のマクロ展開局面は現在、些細です。 しかしながら、一般に、これは本当にならないでしょう。 単に、これらが今それを本当にする_の原始の_l/機能であるということです。
The decision to use a compile-and-interpret cycle calls for some explanation. The way to understand this, is to think in terms of the functions that would be performed in a strictly interpretive system. There would still be a requirement to perform global checks on the validity of the request in advance of the execution of any part of it. This is because partial execution of an incorrect request can leave a database in an inconsistent state; if this is a large or complex database, the cost of recovery will be considerable. Thus it pays to do as much checking as is possible; when the system is fully developed, this will include a certain element of simple prediction of execution flow; in any case, much more than syntactic checking is implied.
コンパイルしている、解釈しているサイクルを費やすという決定は何らかの説明を求めます。 これを理解する方法は機能に関して思うために、それが厳密に解釈的なシステムで実行されるだろうということです。 まだ、それのどんな部分の実行の前にも要求の正当性にグローバルなチェックを実行するという要件があるでしょう。 これは不正確な要求の部分的な実行が矛盾した状態にデータベースを残すことができるからです。 これが大きいか複雑なデータベースであるなら、回復の費用は無視できなくなるでしょう。 したがって、できるだけ多くの照合をするのは得になります。 システムが完全に開発されるとき、これは実行流動の単純予測のある要素を含むでしょう。 どのような場合でも、構文の照合よりはるかに多くが含意されます。
Since any such global checks will be performed in advance of actual execution, they are effectively not part of the execution itself, for any given form. By performing them as part of a separate compilation process, we only formalize a modularity which already effectively exists.
そのようなどんなグローバルなチェックも実際の実行の前に実行されるので、事実上、それらは実行自体の一部ではありません、どんな与えられたフォームのためにも。 個別コンパイルの過程の一部としてそれらを実行することによって、私たちは既に事実上存在するモジュール方式を正式にするだけです。
There will still be cases, however, in which checking, binding and optimization functions must be executed during interpretation, if at all. This will occur when the information needed is not available until some of the data has been accessed. When practical, we will provide for such occurrences by designing most functions so that they can be executed as part of either "half" of the cycle.
解釈の間、それでも、ケースがあって、どの照合では、しかしながら、結合と最適化機能をせいぜい実行しなければならないか。 いくつかのデータがアクセスされるまで必要である情報が利用可能でないときに、これは起こるでしょう。 実用的であるときに、私たちはサイクルの「半分」の一部のようなそれらを実行できるようにほとんどの機能を設計するのによる発生に備えるつもりです。
As the model develops, we expect to get a better feel for this problem;
モデルが展開するとき、私たちは、この問題の、より良い感じを得ると予想します。
Winter, Hill & Greiff [Page 71] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[71ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
it is certainly reasonable to end up with a structure in which there are many cycles of compilation and interpretation, perhaps forming a structure in which nesting of cycles within cycles occurs.
確かに、何サイクルも編集と解釈がある構造で終わるのは妥当です、恐らく、サイクル以内のサイクルの巣篭もりが起こる構造を形成して。
4.10 Examples of operations on LISTs
4.10 LISTsにおける操作に関する例
Here we develop an example of an operation on a LIST using primitive l/functions. We first show the function calls required to create a LIST named F and give it a few member values. We then selectively copy certain members to a second LIST G.
ここで、私たちは、LISTで原始のl/機能を使用することで操作に関する例を開発します。 私たちは、最初に、ファンクションコールがFというLISTを作成して、いくつかのメンバー値をそれに与えるのが必要であることを示します。 そして、私たちは選択的に第2のLIST Gの確信しているメンバーをコピーします。
To create F:
Fを作成するために:
L/CREATE("STAR",LD/LIST(F,
LD/STRUCT(R,
LD/STRING(A,FIXED,2),
LD/STRING(B,FIXED,2))))
L/は作成します。(「星」、LD/リスト、(F、LD/STRUCT、(LD/ストリング、R、LD/が(2修理されて、)を結ぶ、(Bの、そして、固定された2)
This creates F as a member of the permanent directory STAR (see section 4.6 for details about STAR). The symbol STAR has a special status in the "language", in that it is one of the few atomic symbols to evaluate directly to an object. (Recall that most permanent objects are referenced through a call to L/POBJ; reserving the symbol STAR is equivalent to reserving STAR as a name and writing L/POBJ(STAR). The solution we choose here is easier to write.) Execution of this call builds the structure shown in 4-15 (except for STAR, which existed in advance of the call). The value initially created for F is an empty LIST--a LIST of zero members.
これは永久的なディレクトリSTARのメンバーとしてFを作成します(STARに関する詳細に関してセクション4.6を見てください)。 シンボルSTARには、「言語」による特別な状態がいます、それが直接物に評価するわずかな元素記号の1つであるので。 L/POBJへの呼び出しでほとんどの永続オブジェクトが参照をつけられたと思い出してください; シンボルSTARを予約するのは名前としてSTARを予約して、L/POBJ(STAR)に書くのに同等です。(私たちがここで選ぶ解決策はより書きやすいです。) この呼び出しの実行は4-15(呼び出しの前に存在したSTARを除いた)で見せられた構造を建設します。 初めはFのために作成された値は空のLISTです--メンバーがないLIST。
Winter, Hill & Greiff [Page 72] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[72ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | STAR | | | | F | |
| |_____________| | | |_____________| |
| NAME | | NAME |
| _____________ | | _____________ |
| | | | | | LIST | |
| |_________|___| | | |_____________| |
| CHILD | | | TYPE |
|___________|_____| | _____________ |
OBJECT | | | | |
| | |___________|_| |
___________V_____ __\| CHILD | |
| _____________ | | /|_____________|___|
| | F | | | DESCRIPTION |
| |_____________| | | |
| NAME | | _____________V___
| _____________ | | | _____________ |
| | ____|_| | | | R | |
| |_____________| |___| | |_____________| |
| DESCRIPTION | | NAME |
| _____________ | | _____________ |
| | | | | | STRUCT | |
| |_________|___| | | |_____________| |
| VALUE | | | TYPE |
|___________|_____| | _____________ |
OBJECT | | | | |
| | |___________|_| |
___________V_____ | CHILD | |
| | |_____________|___|
| | DESCRIPTION |
|_________________| _____________V___
VALUE | _____________ |
| | A | |
| |_____________| |
| NAME | _________________
| _____________ | | _____________ |
| | STRING | | | | B | |
| |_____________| | | |_____________| |
| TYPE | | NAME |
| _____________ | | _____________ |
| | ____|_|_____\| | STRING | |
Figure 4-15 | |_____________| | /| |_____________| |
F immediately after | SIBLING | | TYPE |
creation |_________________| |_________________|
DESCRIPTION DESCRIPTION
_________________ _________________ | _____________ | | _____________ | | | 星| | | | F| | | |_____________| | | |_____________| | | 名前| | 名前| | _____________ | | _____________ | | | | | | | リスト| | | |_________|___| | | |_____________| | | 子供| | | タイプ| |___________|_____| | _____________ | 物| | | | | | | |___________|_| | ___________V_____ __\| 子供| | | _____________ | | /|_____________|___| | | F| | | 記述| | |_____________| | | | | 名前| | _____________V___ | _____________ | | | _____________ | | | ____|_| | | | R| | | |_____________| |___| | |_____________| | | 記述| | 名前| | _____________ | | _____________ | | | | | | | STRUCT| | | |_________|___| | | |_____________| | | 値| | | タイプ| |___________|_____| | _____________ | 物| | | | | | | |___________|_| | ___________V_____ | 子供| | | | |_____________|___| | | 記述| |_________________| _____________V___ 値| _____________ | | | A| | | |_____________| | | 名前| _________________ | _____________ | | _____________ | | | ストリング| | | | B| | | |_____________| | | |_____________| | | タイプ| | 名前| | _____________ | | _____________ | | | ____|_|_____\| | ストリング| | 図4-15| |_____________| | /| |_____________| | 直後のF| 兄弟| | タイプ| 創造|_________________| |_________________| 記述記述
Winter, Hill & Greiff [Page 73] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[73ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
To add members to F, we need to use listops, and for this we must create
two more objects: an object to represent the current member and an
operation descriptor (OPD). These are temporaries rather than permanent
objects; they are also "top level" (i.e., not local to a request).
Temporary, top level objects are created as members of the directory
TOP/LEVEL. The calls to create them are:
L/CREATE(L/TOBJ(TOP/LEVEL),
LD/STRUCT(M,
LD/STRING(A,FIXED,2),
LD/STRING(B,FIXED,2)))
L/CREATE(L/TOBJ(TOP/LEVEL),LD/OPD(OPF))
We create M to represent the current member; its description is the same
as the one input for a member of F (see the call which created F). The
proper way to accomplish this is with a mechanism which shares the
actual LIST member description with M; however, this mechanism does not
yet exist in our model.
Fのメンバーであり、私たちが、listopsを使用する必要であると言い足して、これのために私たちはもう2個の物を作成しなければなりません: 現在のメンバーの代理をする物と操作記述子(OPD)。 これらは永続オブジェクトよりむしろtemporariesです。 また、それらは「トップレベル」(すなわち、要求への地方でない)です。 一時的で、最高な平らな物はディレクトリTOP/LEVELのメンバーとして作成されます。 それらを作成するという要求は以下の通りです。 L/CREATE(L/TOBJ(TOP/LEVEL)、LD/STRUCT(M、LD/STRING(A、FIXED、2)、LD/STRING(B、FIXED、2)))L/CREATE(L/TOBJ(TOP/LEVEL)、LD/OPD(OPF))、私たちは現在のメンバーの代理をするためにMを作成します。 記述はFのメンバーへの1つの入力と同じです(Fを作成した呼び出しを見てください)。 これを達成する適切な方法が実際のLISTメンバー記述をMと共有するメカニズムであります。 しかしながら、このメカニズムは私たちのモデルにまだ存在していません。
We now wish to add some data to F; each member will be a STRUCT containing two two-character STRINGs.
現在、いくつかのデータをFに加えたいと思います。 各メンバーは2 2キャラクタのSTRINGsを含むSTRUCTになるでしょう。
To begin the listop sequence:
L/LISTOP/BEGIN(L/POBJ(F),L/TOBJ(M),
L/TOBJ(OPF),ADD)
This call establishes the structure shown in figure 4-16. It initializes
the OPD, making it point to F and M and recording that only the ADD
suboperation is enabled.
listop系列を始めるために: これが呼ぶL/LISTOP/BEGIN(L/POBJ(F)、L/TOBJ(M)、L/TOBJ(OPF)、ADD)は図4-16に示された構造を確立します。 ADD suboperationだけが有効にされるのをポイントからF、M、および録音にして、それはOPDを初期化します。
Winter, Hill & Greiff [Page 74] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[74ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | STAR | | | | OPF | |
| |_____________| | | |_____________| |
| NAME | | NAME |
| _____________ | | _____________ |
| | | | | | | |
| |_________|___| | | |_______|_____| |
| CHILD | | | VALUE | |
|___________|_____| |_________|_______|
OBJECT | OBJECT |
___________V_____ _________V______
| _____________ | | _____________ |
| | F | |/______|_|____ | |
| |_____________| |\ | |_____________| |
| NAME | | LIST |
| _____________ | | _____________ |
| | | | | | | |
| |_________|___| | | |________|____| |
| VALUE | | | MEMBER | |
|___________|_____| |__________|______|
OBJECT | VALUE | OPD
| __________V______
___________V_____ | _____________ |
| | | | M | |
| LIS | | |_____________| |
|_________________| | NAME |
VALUE | _____________ |
| | | |
| |________|____| |
| CHILD | |
|__________|______|
OBJECT |
__________V______ _________________
| _____________ | | _____________ |
| | A | | | | B | |
| |_____________| | | |_____________| |
| NAME | | NAME |
| _____________ | | _____________ |
| | ____|_|_____\| | | |
| |_____________| | /| |_____________| |
| SIBLING | | |
|_________________| |_________________|
OBJECT OBJECT
_________________ _________________ | _____________ | | _____________ | | | 星| | | | OPF| | | |_____________| | | |_____________| | | 名前| | 名前| | _____________ | | _____________ | | | | | | | | | | |_________|___| | | |_______|_____| | | 子供| | | 値| | |___________|_____| |_________|_______| 物| 物| ___________V_____ _________V______ | _____________ | | _____________ | | | F| |/______|_|____ | | | |_____________| |\ | |_____________| | | 名前| | リスト| | _____________ | | _____________ | | | | | | | | | | |_________|___| | | |________|____| | | 値| | | メンバー| | |___________|_____| |__________|______| 物| 値| OPD| __________V______ ___________V_____ | _____________ | | | | | M| | | 李| | |_____________| | |_________________| | 名前| 値| _____________ | | | | | | |________|____| | | 子供| | |__________|______| 物| __________V______ _________________ | _____________ | | _____________ | | | A| | | | B| | | |_____________| | | |_____________| | | 名前| | 名前| | _____________ | | _____________ | | | ____|_|_____\| | | | | |_____________| | /| |_____________| | | 兄弟| | | |_________________| |_________________| 物の物
Figure 4-16
F, OPF and M after L/BEGIN/LISTOP
/LISTOPを4-16F、OPF、およびLのM後に計算するか、または始めてください。
Winter, Hill & Greiff [Page 75] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[75ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
Next we must establish a current member. We want to add members to the
end (in this case, adding them anywhere would get the same effect, since
the LIST is empty), which is done by making LAST the current member.
L/WHICH/MEMBER(L/TOBJ(OP1),LAST)
次に、私たちは現在のメンバーを設立しなければなりません。 終わり(どこでも彼らを加えると、この場合同じ効果を得るでしょう、LISTが空であるので)にメンバーを加えたいと思います。(それが、現在のメンバーにLASTを作ることによって、行われます)。 L/はどの/メンバーであるか。(L/TOBJ(OP1)、最終)
Now, to add a new member to F, we can execute the following:
L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('AB'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('CD'))
L/CLOSE/MEMBER(L/TOBJ(OPF))
今、新しいメンバーをFに加えるために、私たちは以下を実行できます: L/戸外/メンバー(L/TOBJ(OPF)、加える)L/案配、(L/TOBJ(M.a)、LC/ストリング('AB'))L/案配(L/TOBJ(M.B)、ストリングLC/('CD'))L/閉鎖/メンバー(L/TOBJ(OPF))
L/OPEN/MEMBER creates a STRUCT value for M. It does not affect the value of F. Each member of the STRUCT value is initialized when the STRUCT is created. The result is shown in 4-17; notice that the STRUCT member values are as yet unrelated to the objects M.A and M.B.
L/オープン/メンバーはM.のためにSTRUCT値を作成します。ItはSTRUCTのメンバーがSTRUCTが作成されるとき、初期化されるのを評価するF.Eachの値に影響しません。 結果は4-17に示されます。 STRUCTメンバー値がまだ物M.AとM.Bに関係ないのに注意してください。
Figure 4-18 shows the changes accomplished by the first L/ASSIGN; the pointer from the object M.A to the value was set up by a GET/STRUCT/MEMBER compiled by L/TOBJ(M.A). The value was filled in by the assign operator. The second assign has similar effect, filling in the second value. The call to L/CLOSE/MEMBER takes the value shown for M in 4-18 (with the second member value filled in) and adds it to the value of F. The result is shown in 4-19; compare with 4-16.
図4-18は最初のL/ASSIGNによって達成された変化を示しています。 物のM.Aから値までのポインタはL/TOBJ(M.A)によってコンパイルされたGET/STRUCT/メンバーによってセットアップされました。 値は案配オペレータによって記入されました。 2番目は、同様の効果を持って、2番目の値に記入しながら、割り当てます。 L/CLOSE/メンバーへの呼び出しは、4-18(2番目のメンバー値が記入されている状態で)にMのために示された値を見て取って、結果が4-19に示されるF.の値にそれを加えます。 4-16と比較してください。
Winter, Hill & Greiff [Page 76] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[76ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | M | | | | STRUC | |
| |_____________| | | |_____________| |
| NAME | | TYPE |
| _____________ | | _____________ |
| | ____|_|______\| | | |
| |_____________| | /| |__________|__| |
| DESCRIPTION | | CHILD | |
| _____________ | |____________|____|
_____|_|____ | | DESCRIPTION |
| | |_____________| | |
| | VALUE | ____________V____
| | _____________ | | _____________ |
| | | | | | | STRING | |
| | |_________|___| | | |_____________| |
| | CHILD | | ___\| TYPE | _____________
| |___________|_____| | /| _____________ | | _________ |
| OBJECT | | | | ____|_|______\| | STRING | |
| | | | |_____________| | /| |_________| |
| ___________V_____ | | SIBLING | | TYPE |
| | _____________ | | |_________________| |_____________|
| | | A | | | DESCRIPTION DESCRIPTION A
| | |_____________| | | |
| | NAME | | _________________ |
| | _____________ | | | _____________ | |
| | | ____|_|__| | | B | | |
| | |_____________| | | |_____________| | |
| | DESCRIPTION | | NAME | |
| | _____________ | | _____________ | |
| | | | | | | ____|_|___________________|
| | |_____________| | | |_____________| |
| | VALUE | | DESCRIPTION |
| | _____________ | | _____________ |
| | | ____|_|______\| | | |
| | |_____________| | /| |_____________| |
| | SIBLING | | VALUE |
| |_________________| |_________________|
| OBJECT OBJECT
|___________________________
|
_____________________V____________________
| _____________ _____________ |
| | | | | |
| |_____________| |_____________| |
|__________________________________________| Figure 4-17
VALUE After L/OPEN/MEMBER
_________________ _________________ | _____________ | | _____________ | | | M| | | | STRUC| | | |_____________| | | |_____________| | | 名前| | タイプ| | _____________ | | _____________ | | | ____|_|______\| | | | | |_____________| | /| |__________|__| | | 記述| | 子供| | | _____________ | |____________|____| _____|_|____ | | 記述| | | |_____________| | | | | 値| ____________V____ | | _____________ | | _____________ | | | | | | | | ストリング| | | | |_________|___| | | |_____________| | | | 子供| | ___\| タイプ| _____________ | |___________|_____| | /| _____________ | | _________ | | オブジェクト| | | | ____|_|______\| | ストリング| | | | | | |_____________| | /| |_________| | | ___________V_____ | | 兄弟| | タイプ| | | _____________ | | |_________________| |_____________| | | | A| | | 記述記述A| | |_____________| | | | | | 名前| | _________________ | | | _____________ | | | _____________ | | | | | ____|_|__| | | B| | | | | |_____________| | | |_____________| | | | | 記述| | 名前| | | | _____________ | | _____________ | | | | | | | | | ____|_|___________________| | | |_____________| | | |_____________| | | | 値| | 記述| | | _____________ | | _____________ | | | | ____|_|______\| | | | | | |_____________| | /| |_____________| | | | 兄弟| | 値| | |_________________| |_________________| | オブジェクトオブジェクト|___________________________ | _____________________V____________________ | _____________ _____________ | | | | | | | | |_____________| |_____________| | |__________________________________________| 図4-17 L/戸外/メンバーの後の値
Winter, Hill & Greiff [Page 77] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[77ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | M | | | | STRUC | |
| |_____________| | | |_____________| |
| NAME | | TYPE |
| _____________ | | _____________ |
| | ____|_|______\| | | |
| |_____________| | /| |__________|__| |
| DESCRIPTION | | CHILD | |
| _____________ | |____________|____|
_____|_|____ | | DESCRIPTION |
| | |_____________| | |
| | VALUE | ____________V____
| | _____________ | | _____________ |
| | | | | | | STRING | |
| | |_________|___| | | |_____________| |
| | CHILD | | ___\| TYPE | _____________
| |___________|_____| | /| _____________ | | _________ |
| OBJECT | | | | ____|_|______\| | STRING | |
| | | | |_____________| | /| |_________| |
| ___________V_____ | | SIBLING | | TYPE |
| | _____________ | | |_________________| |_____________|
| | | A | | | DESCRIPTION DESCRIPTION A
| | |_____________| | | |
| | NAME | | _________________ |
| | _____________ | | | _____________ | |
| | | ____|_|__| | | B | | |
| | |_____________| | | |_____________| | |
| | DESCRIPTION | | NAME | |
| | _____________ | | _____________ | |
| __|_|____ | | | | ____|_|___________________|
| | | |_____________| | | |_____________| |
| | | VALUE | | DESCRIPTION |
| | | _____________ | | _____________ |
| | | | ____|_|______\| | | |
| | | |_____________| | /| |_____________| |
| | | SIBLING | | VALUE |
| | |_________________| |_________________|
| | OBJECT OBJECT
| |___________
| |
| ________|_________________________________
| | ______V______ _____________ |
|____\| | "AB" | | | |
/| |_____________| |_____________| |
|__________________________________________| Figure 4-18
VALUE After first L/ASSIGN
_________________ _________________ | _____________ | | _____________ | | | M| | | | STRUC| | | |_____________| | | |_____________| | | 名前| | タイプ| | _____________ | | _____________ | | | ____|_|______\| | | | | |_____________| | /| |__________|__| | | 記述| | 子供| | | _____________ | |____________|____| _____|_|____ | | 記述| | | |_____________| | | | | 値| ____________V____ | | _____________ | | _____________ | | | | | | | | ストリング| | | | |_________|___| | | |_____________| | | | 子供| | ___\| タイプ| _____________ | |___________|_____| | /| _____________ | | _________ | | オブジェクト| | | | ____|_|______\| | ストリング| | | | | | |_____________| | /| |_________| | | ___________V_____ | | 兄弟| | タイプ| | | _____________ | | |_________________| |_____________| | | | A| | | 記述記述A| | |_____________| | | | | | 名前| | _________________ | | | _____________ | | | _____________ | | | | | ____|_|__| | | B| | | | | |_____________| | | |_____________| | | | | 記述| | 名前| | | | _____________ | | _____________ | | | __|_|____ | | | | ____|_|___________________| | | | |_____________| | | |_____________| | | | | 値| | 記述| | | | _____________ | | _____________ | | | | | ____|_|______\| | | | | | | |_____________| | /| |_____________| | | | | 兄弟| | 値| | | |_________________| |_________________| | | オブジェクトオブジェクト| |___________ | | | ________|_________________________________ | | ______V______ _____________ | |____\| | 「AB」| | | | /| |_____________| |_____________| | |__________________________________________| 図4-18 VALUE After最初のL/ASSIGN
Winter, Hill & Greiff [Page 78] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[78ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________ _________________
| _____________ | | _____________ |
| | STAR | | | | OPF | |
| |_____________| | | |_____________| |
| NAME | | NAME |
| _____________ | | _____________ |
| | | | | | | |
| |_________|___| | | |___________|_| |
| CHILD | | | VALUE | |
|___________|_____| |_____________|___|
OBJECT | OBJECT |
___________V_____ _____________V___
| _____________ | | _____________ |
| | F | |/______|_|____ | |
| |_____________| |\ | |_____________| |
| NAME | | LIST |
| _____________ | | _____________ |
| | | | | | | |
| |_________|___| | | |___________|_| |
| VALUE | | | MEMBER | |
|___________|_____| |_____________|___|
OBJECT | VALUE | OPD
| _____________V___
______________V_________ | _____________ |
| ______________________ | | | M | |
|| _________ _________ || | |_____________| |
||| "AB" || "CD" ||| | NAME |
|||_________||_________||| | _____________ |
||______________________|| | | | |
| / | | |___________|_| |
| / | |_____________|___|
|_______________/________| OBJECT |
VALUE / / _____________V___ _________________
/ / | _____________ | | _____________ |
/ / | | | | | | B | |
/ LIST | |_____________| | | |_____________| |
/ | NAME | | NAME |
/ | _____________ | | _____________ |
NEW MEMBER VALUE | | ____|_|_____\| | | |
| |_____________| | /| |_____________| |
|_________________| |_________________|
OBJECT OBJECT
_________________ _________________ | _____________ | | _____________ | | | 星| | | | OPF| | | |_____________| | | |_____________| | | 名前| | 名前| | _____________ | | _____________ | | | | | | | | | | |_________|___| | | |___________|_| | | 子供| | | 値| | |___________|_____| |_____________|___| オブジェクト| オブジェクト| ___________V_____ _____________V___ | _____________ | | _____________ | | | F| |/______|_|____ | | | |_____________| |\ | |_____________| | | 名前| | リスト| | _____________ | | _____________ | | | | | | | | | | |_________|___| | | |___________|_| | | 値| | | メンバー| | |___________|_____| |_____________|___| オブジェクト| 値| OPD| _____________V___ ______________V_________ | _____________ | | ______________________ | | | M| | || _________ _________ || | |_____________| | ||| 「AB」|| 「CD」||| | 名前| |||_________||_________||| | _____________ | ||______________________|| | | | | | / | | |___________|_| | | / | |_____________|___| |_______________/________| オブジェクト| 値//_____________V___ _________________ / / | _____________ | | _____________ | / / | | | | | | B| | /リスト| |_____________| | | |_____________| | / | 名前| | 名前| / | _____________ | | _____________ | 新しいメンバー値| | ____|_|_____\| | | | | |_____________| | /| |_____________| | |_________________| |_________________| オブジェクトオブジェクト
Figure 4-19
After L/CLOSE/MEMBER
図4-19 L/閉鎖/メンバーの後に
Winter, Hill & Greiff [Page 79] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[79ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
By executing similar groups of four primitives, varying only values of constants, we can build up the LIST F shown in 4-20. The calls required are shown below:
定数の値だけを変えて、4つの基関数の同様のグループを作成することによって、私たちは4-20で見せられたLIST Fを確立できます。 必要である呼び出しは以下に示されます:
L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('FF'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('GH'))
L/CLOSE/MEMBER(L/TOBJ(OPF))
L/戸外/メンバー(L/TOBJ(OPF)、加える)L/案配、(L/TOBJ(M.a)、ストリングLC/('ff'))L/案配(L/TOBJ(M.B)、ストリングLC/('ギガヘルツ'))L/閉鎖/メンバー(L/TOBJ(OPF))
L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('AB'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('IJ'))
L/CLOSE/MEMBER(L/TOBJ(OPF))
L/戸外/メンバー(L/TOBJ(OPF)、加える)L/案配、(L/TOBJ(M.a)、LC/ストリング('AB'))L/案配(L/TOBJ(M.B)、ストリングLC/('IJ'))L/閉鎖/メンバー(L/TOBJ(OPF))
L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('CD'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('LM'))
L/CLOSE/MEMBER(L/TOBJ(OPF))
L/戸外/メンバー(L/TOBJ(OPF)、加える)L/案配、(L/TOBJ(M.a)、ストリングLC/('CD'))L/案配(L/TOBJ(M.B)、ストリングLC/('LM'))L/閉鎖/メンバー(L/TOBJ(OPF))
The add suboperation has the effect of making the member just added, the current member; thus no L/WHICH/MEMBER calls are needed in this sequence.
副操作にはメンバーをただ加えさせるという効果、現在のメンバーがいると言い足してください。 したがって、L/WHICH/メンバー呼び出しは全くこの系列で必要ではありません。
To terminate the sequence of listops:
L/END/LISTOP(L/TOBJ(OPF))
listopsの系列を終えるために: L/終わり/LISTOP(L/TOBJ(OPF))
Winter, Hill & Greiff [Page 80] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[80ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
_________________
| _____________ |
| | F | |
| |_____________| |
| NAME |
| _____________ |
| | ____|_|_________\
| |_____________| | /
| DESCRIPTION |
| _____________ |
| | | |
| |_________|___| |
| VALUE | |
|___________|_____|
OBJECT |
|
_______________V______________
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "AB" | | "CD" | | |
| | |_________| |_________| | |
| |__________________________| |
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "EF" | | "GH" | | |
| | |_________| |_________| | |
| |__________________________| |
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "AB" | | "IJ" | | |
| | |_________| |_________| | |
| |__________________________| |
| __________________________ |
| | _________ _________ | |
| | | | | | | |
| | | "CD" | | "LM" | | |
| | |_________| |_________| | |
| |__________________________| |
|______________________________|
VALUE
_________________ | _____________ | | | F| | | |_____________| | | 名前| | _____________ | | | ____|_|_________\ | |_____________| | / | 記述| | _____________ | | | | | | |_________|___| | | 値| | |___________|_____| オブジェクト| | _______________V______________ | __________________________ | | | _________ _________ | | | | | | | | | | | | | 「AB」| | 「CD」| | | | | |_________| |_________| | | | |__________________________| | | __________________________ | | | _________ _________ | | | | | | | | | | | | | "EF"| | 「ギガヘルツ」| | | | | |_________| |_________| | | | |__________________________| | | __________________________ | | | _________ _________ | | | | | | | | | | | | | 「AB」| | "IJ"| | | | | |_________| |_________| | | | |__________________________| | | __________________________ | | | _________ _________ | | | | | | | | | | | | | 「CD」| | "LM"| | | | | |_________| |_________| | | | |__________________________| | |______________________________| 値
Figure 4-20
After L/END/LISTOP
図4-20 L/終わり/LISTOPの後に
Winter, Hill & Greiff [Page 81] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[81ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
A slightly more interesting exercise is to construct calls which create a LIST named G, having the same description as F, and then to copy into G all members of F having A equal to 'AB'.
わずかにおもしろい運動はGというLISTを作成する呼び出しを構成することです、Fと同じ記述を持っていてGへのコピーへのその時は皆、'AB'のA同輩がいるFのメンバーです。
We must first create G, an OPD and an object to represent the current
member.
L/CREATE("STAR",LD/LIST(G,
LD/STRUCT(R,
LD/STRING(A,STRING,2),
LD/STRING(B,STRING,2)))
L/CREATE(L/TOBJ(TOP/LEVEL),LD/OPD(OPG))
L/CREATE(L/TOBJ(TOP/LEVEL) ,LD/STRUCT(GM,
LD/STRING(A,STRING,2),
LD/STRING(B,STRING,2)))
私たちは、最初に、現在のメンバーの代理をするためにG、OPD、およびオブジェクトを作成しなければなりません。 L/が作成する、(「星」、LD/リスト(G、LD/STRUCT(R、LD/ストリング(A、ストリング、2)、LD/ストリング(B、ストリング、2)))L/がL/を作成する、(L/TOBJ(先端/レベル)、LD/OPD(OPG))作成(L/TOBJ(先端/レベル)、LD/STRUCT(GM、LD/ストリング(A、ストリング、2)、LD/ストリング(B、ストリング、2)))
We now need to initiate two sequences of listops, one on G and one on F.
L/BEGIN/LISTOP(L/POBJ(F),L/TOBJ(M),
L/TOBJ(OPF),GET)
L/BEGIN/LISTOP(L/POBJ(G),L/TOBJ(GM),
L/TOBJ(OPG),ADD)
L/WHICH/MEMBER(L/TOBJ(OPF),FIRST)
L/WHICH/MEMBER(L/TOBJ(OPG),LAST)
私たちは、現在、listopsの2つの系列、Gの1、およびF.L/BEGIN/LISTOP(L/POBJ(F)、L/TOBJ(M)、L/TOBJ(OPF)、GET)L/BEGIN/LISTOP(L/POBJ(G)、L/TOBJ(GM)、L/TOBJ(OPG)、ADD)L/WHICH/メンバー(L/TOBJ(OPF)、FIRST)L/WHICH/メンバーの1を開始する必要があります。(L/TOBJ(OPG)、最終)
We will now sequence through the members of F; whenever the current member has A equal to 'AB', we will add a member to G. We then copy the values of the current member of F into the newly added member of G. When the current member does not meet this criterion, we do nothing with it.
私たちは現在のFのメンバーを通した系列がそうするつもりです。 現在のメンバーには'AB'のA同輩がいて、私たちがG.のWeの当時のコピーにメンバーを加えるつもりであるときはいつも、現在のメンバーがするG.Whenの新たに加えられたメンバーへのFの現在のメンバーの値はこの評価基準を満たさないで、また私たちはそれで何もしません。
First, to write a loop that will execute until we get to the end of F:
L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),x)
Whatever we put in this call to replace "x" will execute repeatedly
until the end/of/list flag has been set in OPF.
まず最初に、私たちがFの終わりを始めるまで、輪にそれを書くのは実行されるでしょう: L/TILL(L/END/OF/LIST(L/TOBJ(OPF))、x)は私たちが何であっても/リスト旗の端/がOPFに設定されるまで「x」を取り替えるのに繰り返して実行されるというこの要求を入れます。
We must replace "x" with a single function call to in order to give
L/TILL what it is looking for. However, we will be executing "x" once
for each member of F, and will need to execute several listops each
time. The solution is to use L/CF, the compound-function function:
L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),L/CF(y))
We can now replace "y" with a sequence of function calls.
私たちは「x」を機能がそれが探しているものをL/TILLに与えるために呼びかけるシングルに取り替えなければなりません。 しかしながら、私たちは、Fの各メンバーのために一度「x」を実行して、その都度数個のlistopsを実行する必要があるつもりです。 ソリューションはL/CF、合成機能機能を使用することです: L/TILL、(L/END/OF/LIST(L/TOBJ(OPF))、L/CF(y))、私たちは現在、「y」をファンクションコールの系列に取り替えることができます。
Each time we iterate, we need to process a new member of F; initially we
are set up to get the first member. The following sequence, then, is
needed:
L/CF( L/OPEN/MEMBER(L/TOBJ(OPF),GET),
z
L/CLOSE/MEMBER(L/TOBJ(OPF)),
L/WHICH/MEMBER(L/TOBJ(OPF),NEXT) )
繰り返す各回であり、私たちは、Fの新しいメンバーを処理する必要があります。 初めは、私たちは、第1代メンバーを得るためにセットアップされます。 次に、以下の系列が必要です: L/Cf(L/オープン/メンバー(L/TOBJ(OPF)、GET)、z L/CLOSE/メンバー(L/TOBJ(OPF))、L/WHICH/メンバー(L/TOBJ(OPF)、ネクスト))
Winter, Hill & Greiff [Page 82] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[82ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
The above is a compound function which will open the current member of F, do something to it (represented above by "z"), close it, and ask for the next member.
上記はFの現在のメンバーを開いて、それ(上では、「z」で、表される)を興奮して、それを閉じて、次期メンバーを求める合成機能です。
We want to replace "z" by a function call which tests the contents of A
in the current member of F, and either does nothing or adds a member to
G, copying the values of the current member of F. If "w" represents the
action of adding a member to G and copying the values, then we can
express this:
L/IF(L/EQUAL(L/TOBJ(M.A),LC/STRING('AB')),w)
「z」をGにFの現在のメンバーでAのコンテンツをテストして、何もしないか、またはメンバーを加えるファンクションコールに取り替えたいと思います、F.If「w」の現在のメンバーの値をコピーすると、Gにメンバーを加えて、値をコピーする動作は表されます、次に、私たちはこれを言い表すことができます: L/(L/同輩(L/TOBJ(M.a)、LC/ストリング('AB'))、w)
A suitable way to express "add a member and copy values" is:
L/CF(L/OPEN/MEMBER(L/TOBJ(OPG),ADD),
L/ASSIGN(L/TOBJ(GM.A),L/TOBJ(M.A)),
L/ASSIGN(L/TOBJ(GM.B),L/TOBJ(M.B)),
L/CLOSE/MEMBER(L/TOBJ(OPG))
This is similar enough to the previous example so that no explanation
should be necessary.
「メンバーとコピー値を加えてください」を言い表す適当な方法は以下の通りです。 L/CF、(L/オープン/メンバー(L/TOBJ(OPG)、ADD)、L/ASSIGN(L/TOBJ(GM.A)、L/TOBJ(M.A))、L/ASSIGN(L/TOBJ(GM.B)、L/TOBJ(M.B))、(L/TOBJ(OPG))これが十分同様であるL/CLOSE/メンバー、前の例、必要です。
Putting this all together, we get:
L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),
L/CF( L/OPEN/MEMBER(L/TOBJ(OPF),GET),
L/IF(L/EQUAL(L/TOBJ(A),LC/STRING('AB')),
L/CF( L/OPEN/MEMBER(L/TOBJ(OPG),ADD),
L/ASSIGN(L/TOBJ(GM.A),L/TOBJ(M.A)),
L/ASSIGN(L/TOBJ(GM.B),L/TOBJ(M.B)),
L/CLOSE/MEMBER/L/TOBJ(OPG)) ) )
L/CLOSE/MEMBER(L/TOBJ(OPF)),
L/WHICH/MEMBER(L/TOBJ(OPF),NEXT) ) )
一斉にこれを置いて、私たちは以下を得ます。 L/TILL(L/END/OF/LIST(L/TOBJ(OPF)), L/CF( L/OPEN/MEMBER(L/TOBJ(OPF),GET), L/IF(L/EQUAL(L/TOBJ(A),LC/STRING('AB')), L/CF( L/OPEN/MEMBER(L/TOBJ(OPG),ADD), L/ASSIGN(L/TOBJ(GM.A),L/TOBJ(M.A)), L/ASSIGN(L/TOBJ(GM.B),L/TOBJ(M.B)), L/CLOSE/MEMBER/L/TOBJ(OPG)) ) ) L/CLOSE/MEMBER(L/TOBJ(OPF)), L/WHICH/MEMBER(L/TOBJ(OPF),NEXT) ) )
To conclude the operation, we execute:
L/LISTOP/END(L/TOBJ(OPG))
L/LISTOP/END(L/TOBJ(OPF))
操作を結論づけるために、私たちは以下を実行します。 L/LISTOP/終わり(L/TOBJ(OPG))のL/LISTOP/エンド(L/TOBJ(OPF))
The result is a LIST G whose first member has value ('AB','CD'), and
whose second member has value ('AB','IJ'). With a few variations on the
above example, quite a few LIST operations can be performed.
結果は最初のメンバーが値('AB'、'CD')を持っていて、2番目のメンバーが値('AB'、'IJ')を持っているLIST Gです。 上記の例のいくつかの変化で、かなり多くのLIST操作を実行できます。
4.11 Higher level functions
4.11 より高い平らな機能
While these primitive i/functions are useful, we would not ordinarily expect users to operate in datalanguage at this low level. We want to make these primitives available to users so that they can handle the exceptional case, and so that they can construct their own high-level functions for atypical applications. Ordinarily, they ought to operate at least at the level of the following construction (which is legal in the real datalanguage currently implemented):
これらの基関数である間、i/機能が役に立つ、通常、私たちはユーザがdatalanguageでこの低レベルで働いていると予想しないでしょう。 彼らが例外的なケースを扱うことができて、非定型的なアプリケーションのためにそれら自身のハイレベルの機能を構成できるようにこれらの基関数をユーザにとって利用可能にしたいと思います。 通常、彼らは少なくとも以下の工事(現在実行されている本当のdatalanguageで法的である)のレベルで作動するべきです:
Winter, Hill & Greiff [Page 83] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[83ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
FOR G.R,F.R WITH A EQ 'AB'
G.R=F.R
END
This relatively concise expression accomplishes the same result as the
elaborate construction of i/functions given at the close of the
preceding section. We could define i/functions very similar to the
semantic functions used in the running software, and write the above
request as:
L/FOR(L/POBJ(G),R
L/POBJ(F),R,L/WITH(L/EQUAL(L/TOBJ(A),
LC/STRING('AB')))
The differences between the i/function call and the datalanguage request
above it are principally syntactic.
FOR G.R、比較的簡潔な表現が同じように達成するF.R F.R WITH A EQ'AB'G.R=END Thisは先行するセクションの閉鎖で与えられたi/機能の入念な工事として結果になります。 私たちは、実行中のソフトウェアで使用される意味関数と非常に同様のi/機能を定義して、以下として上記の要求を書くことができました。 L/FOR、(L/POBJ(G)、R L/POBJ(F)、R、i/機能の違いが呼ぶL/WITH(L/EQUAL(L/TOBJ(A)、LC/STRING('AB')))、およびそれの上のdatalanguage要求は主に構文です。
In designing functions such as L/FOR and L/WITH, the central problems have to do with choosing the right restrictions. One cannot have all the generality available at the primitive level. Some important choices for these particular functions are: (1) handling multiple inputs and outputs, (2) when FORs are nested, how outer FORs restrict the options available to inner FORs, (3) generality of selection functions (may then in turn generate FORs?), (4) options with regard to where processing should start (are we updating, replacing or appending to the output list(s)?).
正しい制限を選ぶL/FORとL/WITH、主要な問題は関係がある機能を設計する際に。 1つは原始のレベルで利用可能なすべての一般性を持つことができるというわけではありません。 これらの特定の機能のためのいくつかの重要な選択は以下の通りです。 (1) 取り扱い倍数は入出力されます、(2) FORsが入れ子にされるとき、外側のFORsがどう内側のFORsに利用可能なオプションを制限するか、選択機能(次に、順番に、FORsを発生させるかもしれませんか?)の(3)の一般性、処理が始まるべきである(出力並びに取り替えるか、または追加して、私たちはアップデートしていますか?)ところに関する(4)オプション。
Finally, this problem is related to the more general problem of dealing with _sets_, which are a generalization of the idea of a collection of members in a LIST having common properties. FOR is only one of many operators that can input sets.
最終的に、この問題は関連されて、_に対処するというより一般的な問題が_を設定するという(LISTでのメンバーの収集には通有性があるという考えの一般化です)ことです。 FORはセットを入力できる多くのオペレータのひとりであるだけです。
4.12 Conclusion
4.12 結論
The present model, though embryonic, already contains enough primitives and data types to permit definition and generalized manipulation of hierarchical data structures. Common data management operations, such as retrieval by content and selective update can be expressed.
現在のモデルは、胎児ですが、既に十分な基関数とデータ型を許可証定義に含んで、階層データ構造の操作を一般化しました。 満足していて選択しているアップデートによる検索などの一般的なデータ管理操作を言い表すことができます。
The use of this model in developing these primitives has resulted in precise, well-defined and internally consistent specifications for language elements and processing functions. Operating in the laboratory environment provided by the model seems to be a substantial benefit.
これらの基関数を開発することにおけるこのモデルの使用は言語要素と処理機能のための正確で、明確で内部的に一貫した仕様をもたらしました。 モデルによって提供された実験室環境で作動するのはかなりの利益であるように思えます。
Winter, Hill & Greiff [Page 84] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[84ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
5. Further Work
5. さらに働いてください。
In this section, we review what has been accomplished so far in the design and describe what work remains to be done before this design iteration of datalanguage is complete.
このセクションで、私たちは、今までのところデザインで達成されたことを見直して、どんな仕事がdatalanguageのこのデザイン繰り返しが完全になる前にするために残っているかを説明します。
5.1 A Review
5.1 レビュー
Most important, among our accomplishments, we feel that we have delineated the problems and presented the broad outlines of a solution to development of a language for the datacomputer system. Key elements of our approach are the primacy of data description in capturing all the aspects of the data, the separation of logical and physical characteristics of data description, the ability of users to define different views of the same data, the ability to associate functions with different uses of data items, an attempt to capture common aspects of data at every possible level, and the ability of users to communicate with the datacomputer in as high a level as their application permits.
私たちの達成の中で最も重要です、私たちは問題を図で表わして、datacomputerシステムのために言語の開発の解決策の広いアウトラインを提示したと感じます。 私たちのアプローチの主要な要素はデータのすべての局面を得ることにおいて、データ記述の第一です、データ記述の論理的で物理的な特性の分離、ユーザが同じデータ、データ項目の異なった用途に機能を関連づける能力、あらゆる可能なレベルでデータの一般相を得る試み、およびユーザが彼らのアプリケーションが可能にするのと同じくらい高いレベルでdatacomputerとコミュニケートする能力の異なった視点を定義する能力。
5.2 Topics for Further Research
5.2 さらなる調査のための話題
Although more work needs to be done in general to turn out a finished design for datalanguage, we can single out certain issues which in particular need further investigation.
より多くの仕事が、一般に、datalanguageのために終わっているデザインを消すためにする必要がありますが、私たちはさらなる調査を特に必要とするある問題を選び抜くことができます。
So far, only hierarchal data structures (i.e. those that can be modeled by physical containment) have been developed to any extent. We also intend to investigate and provide other types of data structures. We are confident that our language framework does not make assumptions that would prohibit such additions.
今までのところ、聖職者階級制のデータ構造(すなわち、物理的な封じ込めでモデル化できるもの)だけをどんな程度まで開発してあります。 私たちは、他のタイプのデータ構造を調査して、また、提供するつもりです。 私たちは私たちの言語枠組みがそのような追加を禁止する仮定をしないと確信しています。
Our current work on access regulation centers on the use of multiple descriptions for data. We need to do more work on both the technical and administrative aspects of access regulation. Problems of encrypting data for both transmission and storage will also be investigated.
アクセス規則への私たちの執筆中の作品は複数の記述のデータの使用に集中します。 私たちは、アクセス規則の両方の技術的で管理の局面に対する、より多くの仕事をする必要があります。 また、トランスミッションと格納の両方のためのデータをコード化するという問題は調査されるでしょう。
Another issue requiring further research is the protocol requirement for process interaction with the datacomputer.
さらなる研究を必要とする別の問題はdatacomputerとの過程相互作用のためのプロトコル要件です。
Separation of the description into independent modules needs further research. In particular, we need to look into work which has already been done on separate specifications of logical descriptions, physical descriptions, and mappings between the two.
独立しているモジュールへの記述の分離はさらなる研究を必要とします。 特に、私たちは、論理的な記述、物理的性質、および2つの間のマッピングの別々の仕様で既に行われた仕事を調べる必要があります。
Winter, Hill & Greiff [Page 85] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[85ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
5.3 Datalanguage Syntax
5.3Datalanguage構文
We have not yet proposed a syntax for the datalanguage we are developing. Certainly the most difficult parts of the problem have been the semantic and pragmatic issues. We are confident that various syntactic forms can be chosen and implemented without excessive difficulty. It may be best to develop different syntactic forms for the language for different types of users or even for the various subparts of the language itself. As discussed in section 2, the user syntax for the datacomputer is supposed to be at a low level. It should be easy for _programs_ to generate datalanguage requests in this syntax.
私たちは開発しているdatalanguageのためにまだ構文を提案していません。 確かに問題の最も難しい部分は意味的で実践的な問題です。 私たちは過度の困難なしで様々な構文のフォームを選んでいて、実行できると確信しています。 異なったタイプのユーザか言語自体の様々な下位区分のためにさえ言語のための異なった構文のフォームを発生するのは最も良いかもしれません。 セクション2で議論するように、datacomputerのためのユーザ構文が低レベルにあるべきです。 _プログラム_がこの構文によるdatalanguage要求を発生させるのは、簡単であるはずです。
5.4 Further Work on the Datalanguage Model
5.4 Datalanguageモデルへのさらなる作業
The model provides an excellent foundation on which to build up a language with the facilities described in section 3. Much work is yet to be done.
モデルは施設がセクション3で説明されている状態で言語を確立する素晴らしい基礎を提供します。 多くの仕事はまだしていないことです。
For a while, emphasis will be on sets, high-level operators, language extension and data description.
しばらく、セット、ハイレベルのオペレータの上に強調があって、言語は、拡大とデータ記述です。
We expect to model sets as a new datatype, whose value is ordinarily shared with other objects. Some further work on binding and sharing of values is needed to support this.
私たちは、新しいデータ型式としてセットをモデル化すると予想します。(通常、データ型式の値は他の物と共有されます)。 値を縛って、共有するとのさらなるいくらかの取り組みが、これを支持するのに必要です。
Sets can be regarded as a special case of generalized relations, which will come somewhat later.
特殊なものとして一般化された関係についてセットを見なすことができます。(関係は後でいくらか来るでしょう)。
High-level operators such as FOR will be constructed from the existing primitives, and will eventually be defined to have one effect but several possible expansions. The expansion will depend on the representation of the data and the presence of auxiliary structures.
FORなどのハイレベルのオペレータは、既存の基関数から構成されて、結局、1つの効果にもかかわらず、数回の可能な拡大を持つために定義されるでしょう。 拡大はデータの表現と補助の構造の存在によるでしょう。
Alternate expansions will be possible when the data description has been broken up into its various modules. This, also, requires some further research.
データ記述が様々なモジュールに終えられたとき、交互の拡大は可能になるでしょう。 また、これはさらなる何らかの研究を必要とします。
We feel that the language extension problem is much more easily attacked in the environment provided by the model datacomputer. In particular, we expect the laboratory environment to be helpful in evaluating the complex interactions and pervasive effects of operators in the language which extend the language.
私たちは、言語拡大問題がモデルdatacomputerによって提供された環境ではるかに容易に攻撃されると感じます。 特に、私たちは、実験室環境に言語を広げる複雑な相互作用を評価して、言語における、オペレータの波及効果に役立っていると予想します。
Data description work in the near term will focus on the isolation of attributes, the representation of variable structure in description, the description of descriptions and the development of a sufficient set of builtin data types.
データ記述仕事は近いうちに属性の孤立、記述における、可変構造の表現、記述の記述、および十分なセットの作り付けのデータ型の開発に焦点を合わせるでしょう。
Winter, Hill & Greiff [Page 86] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[86ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
Later, we expect to model the semantics of pointers as a datatype, when the representation of the pointer and the semantics of the address space into which it points are specified in the description of the pointer.
その後、私たちは、データ型式としてポインタの意味論をモデル化すると予想します、ポインタの表現とそれが指すアドレス空間の意味論がポインタの記述で指定されるとき。
A large number of lower-level issues will be attacked, including some of the problems discovered in the modeling to date. Some of these are pointed out in the discussions in section 4.
これまでのモデルで発見された問題のいくつかを含んでいて、多くの低レベル問題が攻撃されるでしょう。 これらの或るものは議論でセクション4で指摘されます。
5.5 Applications Support
5.5 アプリケーションサポート
The datalanguage we are designing is intended to provide services to sub-systems solving a broad class of problems related to data management. Examples of such sub-systems are: report generators, online query systems for non-programmers, document-handling systems, transaction processing systems, real-time data collection systems, and library and bibliographic systems. There are many more.
私たちが設計しているdatalanguageがデータ管理に関連する広いクラスの問題を解決するサブシステムに対するサービスを提供することを意図します。 そのようなサブシステムに関する例は以下の通りです。 報告書作成ルーチン、非プログラマのシステムについて質問して、システムをドキュメントでトランザクション処理システムの、そして、リアルタイムの扱うことのオンラインデータ収集システム、ライブラリ、および図書目録のシステムずっと多くがあります。
The idea is that such systems will run on other machines, reference or store data at the datacomputer, and make heavy use of datalanguage. Such a system would not be written entirely in datalanguage, but a large component of its function would be expressed in datalanguage requests; some controlling module would build the requests and perform the non- datalanguage functions.
考えはそのようなシステムがdatacomputerを他のマシン、参照または店データで動いて、datalanguageの重い使用をするということです。 そのようなシステムは完全にdatalanguageに書かれていないでしょうが、機能の大きいコンポーネントはdatalanguage要求で急送されるでしょう。 何らかの制御モジュールが、要求を組み込んで、非datalanguageの機能を実行するでしょう。
While we have experience with such applications in other environments, and we talk to potential users, it will require some work to determine that our language is actually adequate for them. That is, we are not attacking directly the problem of building a human-oriented online query system; we are trying to provide the tools which will make it easy to build one. There is a definite need to analyze whether the tools are likely to be good enough. Of course, the ultimate test will be in actual use, but we want to filter out as many problems as we can before implementation.
私たちには他の環境におけるそのようなアプリケーションの経験があって、潜在的ユーザと話している間、彼らには、私たちの言語が実際に適切であることを決定するのがいくらかの仕事を必要とするでしょう。 すなわち、私たちは直接、人間指向のオンライン質問システムを構築するという問題を攻撃していません。 私たちは1つを建てるのを簡単にするツールを提供しようとしています。 ツールが十分良い傾向があるか否かに関係なく、分析する明確な必要があります。 もちろん、究極のテストは実際使用中でしょうが、私たちが実現の前にそうすることができるのと同じくらい多くの問題を無視したいと思います。
An important component of supporting applications is that the using programs will frequently be written in high-level languages such as FORTRAN, COBOL or PL/1. We will want to investigate the ability of datalanguage to support such users, while the design is taking shape.
サポートアプリケーションの重要な成分は使用プログラムが頻繁にFORTRAN、COBOLまたはPL/1などの高位言語に書かれるということです。 デザインが具体化している間にdatalanguageがそのようなユーザを支持する能力を調査したいと思うでしょう。
5.6 Future Plans
5.6 将来のプラン
This paper has laid the foundations for a new design of datalanguage. Section 3 provides an outline for a datalanguage design, which will be filled in during the coming months. Following the issue of a detailed specification, we anticipate extensive review, revisions, and
この紙はdatalanguageの新案のために基礎を作りました。 セクション3はdatalanguageデザインのためのアウトラインを提供します。(デザインは来るべき月日の中で記入されるでしょう)。 そして仕様詳細の問題を調査して、私たちが大量のレビュー、改正を予期する。
Winter, Hill & Greiff [Page 87] RFC 610 Further Datalanguage Design Concepts December 1973
冬、ヒル、およびGreiff[87ページ]RFC610は設計思想1973年12月にDatalanguageを促進します。
incorporation into the implementation plans. Implementation will occur in stages, compatible with the established plans for development of datacomputer service and data management capabilities.
実現への編入は計画されています。 実現はdatacomputerサービスとデータ管理能力の開発のための確立したプランとのコンパチブル段階に起こるでしょう。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 1/2000 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社1/2000]
Winter, Hill & Greiff [Page 88]
冬、ヒル、およびGreiff[88ページ]
一覧
スポンサーリンク
