回答編集履歴
2
最終稿
answer
CHANGED
|
@@ -30,6 +30,11 @@
|
|
|
30
30
|
|
|
31
31
|
wikipediaに記述するなら、評価戦略という観点から、歴史的順序、標準化の程度、依存関係、抽象化の度合いなどを、どう規定するかが著者に求められませんか？もちろん、逆引き用語集のように網羅的、索引的な記述をしてもよいが、作業量は増えます。その作業がかえって観点確立に役立つかもしれないけれど。
|
|
32
32
|
|
|
33
|
+
### Javaの引数渡しの思考実験 (2019-05-02)
|
|
34
|
+
Javaで、１９７９年の議論を実現するには次のようにする。荒唐無稽ですが。
|
|
35
|
+
- Call by Value オブジェクトをシリアライズして渡す。呼び元のオブジェクトには全く影響を及ぼさない（mutableのみ）ただし高オーバーヘッド。
|
|
36
|
+
- call by reference 仮引数をfinal宣言して破壊的代入を許さなくする。あるいは、（できるなら）メソッド呼び出しをネストしたブロックにインライン展開、内部ブロックから実引数を直接参照する。できない場合が多い。
|
|
37
|
+
|
|
33
38
|
### CLU (2019-05-02)
|
|
34
39
|
|
|
35
40
|
CLUにプリミティヴ型変数はなく参照型変数しかない。関数呼び出しは仮引数に実引数の参照をコピー代入することで行う。Javaにあわせて表を作ると以下のようになる。
|
|
@@ -61,27 +66,59 @@
|
|
|
61
66
|
スタック上の変数はオブジェクトの実体ではない。オブジェクトの実体はヒープに存在する。変数はオブジェトを参照するのみ。ここから、複数の変数が同じオブジェクトを参照（共有する）という事態が起こる。共有の本質は参照のコピー代入である。共有はどこで起こるのか。
|
|
62
67
|
|
|
63
68
|
- スタック上の複数の変数がヒープ上のオブジェクトを共有する。
|
|
64
|
-
- cluster の private 変数によって、ヒープ上の複数のオブジェクトが別のオブジェクトを共有する。再帰的な共有
|
|
69
|
+
- cluster の private 変数によって、ヒープ上の複数のオブジェクトが別のオブジェクトを共有する。再帰的な自己共有や、循環的な自己共有も可能。
|
|
65
70
|
- 関数呼び出しによって、呼び元の実引数と呼び先の仮引数が、ヒープ上のオブジェクトを共有する。
|
|
66
71
|
|
|
67
72
|
代入においてオブジェトの実体コピーとは何かという問いがたてられ、深いコピー/浅いコピーの違いや、真の実体を代入するために、by-reference パラメータを使う代入(Alfard)などが検討された。
|
|
68
73
|
|
|
69
|
-
**call
|
|
74
|
+
**call by sharing 共有の何が新しいと思ったのか １９７９**
|
|
70
75
|
|
|
76
|
+
代入とは
|
|
71
|
-
|
|
77
|
+
- オブジェクトの本体はコピーされない
|
|
78
|
+
- 代入はオブジェクトの状態に影響を与えない
|
|
79
|
+
- 代入後、オブジェクトは変数によって共有される
|
|
72
80
|
|
|
81
|
+
引数渡しとは
|
|
82
|
+
- 仮引数は呼び先のルーチンのローカル変数とみなす
|
|
83
|
+
- 実引数の式が評価され評価結果のオブジェクトが仮引数に代入される（ローカル変数の初期化）
|
|
84
|
+
- この手法は、伝統的な引数渡しのなかに該当するものがほとんど見当たらない（LISPの引渡しに似ている）
|
|
73
85
|
|
|
86
|
+
伝統的な引数渡しとの相違点
|
|
87
|
+
- call by value オブジェクトの本体を変更したら、呼び元にも変更が見える（mutableな場合）
|
|
88
|
+
- call by reference 呼び元の変数のエイリアスではない。オブジェクトの本体を指している
|
|
74
89
|
|
|
75
|
-
|
|
90
|
+
したがって、call by sharing と呼ぶことにする。
|
|
76
91
|
|
|
77
|
-
|
|
92
|
+
Barbara Liskov et al., 'CLU Reference Manual', MIT Laboratory for Computer Science, Cambridge, MA, 1979
|
|
78
93
|
|
|
79
|
-
|
|
94
|
+
設計にかかわる議論は７８項目にわたって記述されている。それらは未読。
|
|
80
|
-
|
|
95
|
+
Programming Methodology Group, CLU Design Notes, MIT Laboratory for Computer Science, Cambridge, MA, 1973-1979.
|
|
81
|
-
from evaluating the actual argument expression is assigned to the formal.
|
|
82
96
|
|
|
97
|
+
手元の記事には実装の詳細が一部だけ掲載されている。拾い読み程度。読まないかもしれない。
|
|
83
|
-
|
|
98
|
+
B. Liskov, A. Snyder, R. Atkinson et al., 'Abstraction Machanisms in CLU', CACM vol. 20 no. 8, 1977
|
|
99
|
+
オブジェトディスクリプタの解説では定数はスタックに置かれるようだ。その他はヒープに置く。
|
|
84
100
|
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
101
|
+
**by objectという用語 １９９２ **
|
|
102
|
+
１９９２年にリスコフは call-by-sharing という用語を使っていない。call-by-object は記述がなく、"by object"が登場するのは、変数共有を排除することで推論が容易になるというところだけ。
|
|
103
|
+
|
|
104
|
+
> In fact, CLU procedures do not share variables at all. In addition to there being no free variables, there is no call-by-reference. Instead arguments are passed "by object"; the (pointer to the) object resulting from evaluating the actual argument expression is assigned to the formal. (Thus passing a parameter is just doing an assignment to the formal.) Similarly, a pointer to a result object is returned to the caller. We have found that ruling out shared variables seems to make it easier to reason about programs.
|
|
105
|
+
|
|
106
|
+
Barbara Liskov, 'A History of CLU', MIT Laboratory for Computer Science, Cambridge, MA, 1992
|
|
107
|
+
|
|
108
|
+
free variables は LISP の用語で(束縛されない)自由変数と訳せる。ここではグローバル変数のこと。
|
|
109
|
+
"by object" は、call-by-reference を指すとも、オブジェクトの本体を渡すともとれる。
|
|
110
|
+
object resulting from evaluating the actual argument expression は、正格処理として実引数の式を評価して結果オブジェクトを得ること。
|
|
111
|
+
|
|
112
|
+
１９７９年から１９９２年までの間に、call-by-sharing を使わなくなった理由は不明。
|
|
113
|
+
|
|
114
|
+
CLUを調べることで、他の回答者の議論になんとか追いつくことができました。概要だけみるとCLUは、Javaや、pythonの祖先といってよいほど似ている。pythonはCLUの嫡子でしょう。抽象データ型には触れなかったが、ほんとうの研究の成果はここにあると思います。その他、仕事で出会った古いALOGOLコードにCLU由来の考えがあったのを思い出した。
|
|
115
|
+
|
|
116
|
+
### 命名
|
|
117
|
+
英文 wikipedia で call by sharing は共通合意ではないといっているが、１９７９年の議論は解説する必要があるでしょう。１９９２年にはオブジェクトのポインターを代入すると言っているので、値渡しの範囲に分類できる。call by object は資料の中に見つけられなかったので採用しません。
|
|
118
|
+
|
|
119
|
+
英語に便利な言い方があります、等値の ', or'（すなわち）を使います。
|
|
120
|
+
|
|
121
|
+
call by sharing, or call by reference value
|
|
122
|
+
共有呼び、すなわち参照の値呼び
|
|
123
|
+
|
|
124
|
+
すごく常識的になりました。内容に誤りがあればご指摘ください。
|
1
CLUを追記
answer
CHANGED
|
@@ -28,4 +28,60 @@
|
|
|
28
28
|
|
|
29
29
|
Java における call by sharing の位置付け。「オブジェクトの共有」は暗黙の了解事項であるが名前を付けて意識するほどのことではない。しかし他の言語については、上の関連表を書いて考察しない限り確かなことは言えない。CLUの場合はどんな表になるのかは興味がある。
|
|
30
30
|
|
|
31
|
-
wikipediaに記述するなら、評価戦略という観点から、歴史的順序、標準化の程度、依存関係、抽象化の度合いなどを、どう規定するかが著者に求められませんか？もちろん、逆引き用語集のように網羅的、索引的な記述をしてもよいが、作業量は増えます。その作業がかえって観点確立に役立つかもしれないけれど。
|
|
31
|
+
wikipediaに記述するなら、評価戦略という観点から、歴史的順序、標準化の程度、依存関係、抽象化の度合いなどを、どう規定するかが著者に求められませんか？もちろん、逆引き用語集のように網羅的、索引的な記述をしてもよいが、作業量は増えます。その作業がかえって観点確立に役立つかもしれないけれど。
|
|
32
|
+
|
|
33
|
+
### CLU (2019-05-02)
|
|
34
|
+
|
|
35
|
+
CLUにプリミティヴ型変数はなく参照型変数しかない。関数呼び出しは仮引数に実引数の参照をコピー代入することで行う。Javaにあわせて表を作ると以下のようになる。
|
|
36
|
+
|
|
37
|
+
|variable type|call by value|call by reference|call by sharing|call by name|
|
|
38
|
+
|:--|:--:|:--:|:--:|:--:|
|
|
39
|
+
|reference type|◯|-|◯|-|
|
|
40
|
+
|
|
41
|
+
以下は言語の設計過程で行われた検討。
|
|
42
|
+
|
|
43
|
+
**オブジェトをヒープ、スタックのどちらに置くか**
|
|
44
|
+
|
|
45
|
+
Simula 67 がCLUの目指す設計に最も近かったが、Simula 67 はオブジェクトをスタック、ヒープの両方に置く方式を採用。CLU はすべてのオブジェクトをヒープに置く。理由は、状態遷移する mutable オブジェクトを採用したため可変長オブジェクトの更新にはヒープが有利だったのと、オブジェクトの生存期間をプロセジャのスコープより長くしたかったから。当然 GC を採用した（懸垂参照（ポインタ）の議論がちょっとある）。
|
|
46
|
+
|
|
47
|
+
**ヒープ、スタック**
|
|
48
|
+
|
|
49
|
+
ヒープとシングルスタックを採用する。並行処理（マルチスタック）を考えたが途中で放棄した。スレッド共有という考えはない。
|
|
50
|
+
|
|
51
|
+
**オブジェト**
|
|
52
|
+
|
|
53
|
+
built-in type 、 user-defined type 、 procedure / iterator の三種類。
|
|
54
|
+
- built-in type Javaにおけるプリミティヴ型 (immutable)、配列などの集合型 (mutable/immutable)。
|
|
55
|
+
- user-defined type ユーザーが定義するクラス（属性と振舞を持つ。カプセル化を実現）。clusterと呼ぶ。(function cluster)
|
|
56
|
+
- procedure / iterator 関数（第一級のオブジェクト）
|
|
57
|
+
cluster (クラス) に継承という考えはない。パラメトリック・ポリモーフィズム（Javaのジェネリックスに相当。型変数を伴いコンパイル時にチェック）を採用。cluster は抽象データ型のアイデアを実装。抽象、つまり公開する振る舞い（Javaのインタフェースに相当）と実装、表現（representation）とを分離、定義する。
|
|
58
|
+
|
|
59
|
+
**オブジェクト共有**
|
|
60
|
+
|
|
61
|
+
スタック上の変数はオブジェクトの実体ではない。オブジェクトの実体はヒープに存在する。変数はオブジェトを参照するのみ。ここから、複数の変数が同じオブジェクトを参照（共有する）という事態が起こる。共有の本質は参照のコピー代入である。共有はどこで起こるのか。
|
|
62
|
+
|
|
63
|
+
- スタック上の複数の変数がヒープ上のオブジェクトを共有する。
|
|
64
|
+
- cluster の private 変数によって、ヒープ上の複数のオブジェクトが別のオブジェクトを共有する。再帰的な共有の連鎖も可能。
|
|
65
|
+
- 関数呼び出しによって、呼び元の実引数と呼び先の仮引数が、ヒープ上のオブジェクトを共有する。
|
|
66
|
+
|
|
67
|
+
代入においてオブジェトの実体コピーとは何かという問いがたてられ、深いコピー/浅いコピーの違いや、真の実体を代入するために、by-reference パラメータを使う代入(Alfard)などが検討された。
|
|
68
|
+
|
|
69
|
+
**call-by-sharing 共有の何が新しいと思ったのか**
|
|
70
|
+
|
|
71
|
+
<ここ、追記予定>
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
**call-by-object という用語の否定**
|
|
76
|
+
|
|
77
|
+
リスコフは、call-by-sharingと同じ意味で使っていない。以下は、プロセジャで（参照の共有があっても）変数の共有がないことを説明する箇所。
|
|
78
|
+
|
|
79
|
+
> In fact, CLU procedures do not share variables at all. In addition to there being no free variables, there
|
|
80
|
+
is no call-by-reference. Instead arguments are passed "by object"; the (pointer to the) object resulting
|
|
81
|
+
from evaluating the actual argument expression is assigned to the formal.
|
|
82
|
+
|
|
83
|
+
'A History of CLU' Barbara Liskov, 1992
|
|
84
|
+
|
|
85
|
+
free variables は LISP の用語で(束縛されない)自由変数と訳せるが、ここではグローバル変数のこと。
|
|
86
|
+
"by object" は、call-by-reference のこと。(暗にC++のような深いコピーを渡すことも指していると勝手に解釈）
|
|
87
|
+
object resulting from evaluating the actual argument expression は、正格処理として実引数の式を評価して結果オブジェクトを得ること。変数自体も式である。
|