top recent

プログラミング言語:文法談義

関連ページ

プログラミング言語 プログラミング

目次

  1. Integerに、Integerな名前のMessageを送信すると、Floatな値が返される。...
  2. すると、Schemeの敵(笑)は、なんなんだろう?...
  3. TinyBASICにはローカル変数がないので...
  4. 再帰 in TinyLisp(?)...
  5. 左辺値Objectって考え方に意味は有るでしょうか？...
  6. Perlの最近のバージョン(5.6)では左辺値を返す...
  7. rubyのhoge=のほうがすっきり…かな...
  8. 代入の記法...
  9. SVOO...
  10. Smalltalkなら...
  11. re:Smalltalkなら (#10)...
  12. re:re:Smalltalkなら(was re:re:[[id:1109]] (#11))...
  13. selfがyourselfにメッセージを送信する、というのがSmalltalkらしさだと。...
  14. Sender, Receiver, Dispatcher.......
  15. 自分なりの理解はこんな感じです...
  16. DispatcherとDispatchネタとは違う...
  17. 名前をどれに与えるかの問題...

Integerに、Integerな名前のMessageを送信すると、Floatな値が返される。


…という阿呆な仕様の言語＆クラスライブラリを考えた。

つまり「1.1」というソース上の記述を「1 Objectに1というMessageを送った」と解釈することで、
FloatのためにわざわざParserとかの機能を用意する必要がなくなる、ということ。

ああ馬鹿馬鹿しい(ぉ

----
別解：見なれたC++系構文とは別物になるが一応：
-1 Object に . というMessageを 1という引数つきで投げた(ぷ^2

うーん。いずれにせよ、1と01と001と…を区別するという概念が無いとならんなあ。
ソース上の所謂リテラルは、それが展開される結果の定数へのマッピング方法は
一意唯一だとは限らない、という言語でないとならんかな。
少なくとも整数のパースのしかたが御仕着せ唯一な言語ではアウトだな。
signature: 戯

----
後日談：
Forth系しか作ったことのない身で、何も考えずに言語を作ると、
どうも上記のようなものを作ってしまいそうな勢いです(^^; -戯

つまり、 . もまたmessage(名)である、という言語を…

-かなーり無益ですけどね。
-というか、"何への"messageなのか、が既に混乱しているぞ＞俺
-まともな道に復帰しる＞俺
-といっても、 . のような幾つか特定のSymbolを、特別扱いするだけ(で済むはず)だが…
--今のところ考えているのが、特別なSymbolとして . = ; の3つだけが有る言語(ぉ

[[id:625]] 2002-09-13 16:28:41

すると、Schemeの敵(笑)は、なんなんだろう?

Smalltalkは子供向けじゃなくて子供から大人までオススメです (プログラミング言語)

やっぱり、basic系からC系への一連のマジョリティの流れが、
それ以外のアーキテクチャの言語への邪魔となって作用してるんだろうか?

a=b
と
(= 'a b) ;;;仮に(^^;
とで何か違うのか?と問われてしまうと、実は何も違わなくて、慣れの問題でしかない。
小学校の算数(あるいは近年なら情報)の科目で、そういう記法を教えれば済むだけのこと。

そういう意味では、目に見えるかたちで商業主義的に行なわれるMS洗脳(笑)よりも、
見えにくいかたちのbasic/C洗脳のほうが、重症かも知れない。

#で、その逆をうまく突いたのが、ruby(笑)

というか、算数系の表記を安易に一見それっぽく(だけど本質を間違えて)真似てしまった、
basic/c系というかそもそもfortran系の「式」っていう概念は、
ちょっと痛いよね、ほんと言えば。

どうせ行番号basicにだってGCは有る(よね?)んだから、
あの時点でGatesが選択した言語がlispであっても、良かったはずだ…

よだん：
TinyBasicの某CPU向け実装は1kbyte無かったそうだから
lispでもそういうことがやれるんでわないかとか…
変数名とかをキツキツにケチるらしい。変数名1文字しか使えないならばparserとかは超単純になるわけで。

よだん2：
あと、参照の概念をホカすのは痛いぞ>>fortran
最適化したいのは判るが、だからってfortranを真似たstrictポインタの導入は違和感だなあ>>新C

[[id:757]] 2002-09-02 10:29:49

TinyBASICにはローカル変数がないので

Re: すると、Schemeの敵(笑)は、なんなんだろう? (#2)

変数名がアルファベット１文字ということは、数値を入れる箱を26個、文字列を入れる箱を26ずつ固定で持っておけばいいという実装ですよね。
想像してみてください‥‥‥
-名前がすべてグローバルなLisp
-再帰関数を作れないLisp
-非破壊的操作のできないLisp
- ：
- ：
-（ご自由に追記してください）

--------
->>名前がすべてグローバルなLisp
--たしかに使えませんね(^^;
->>再帰関数を作れないLisp
--作れるのでは？実Stack(?)を消費しないのならば大丈夫では？作れる関数(をbindできる名前)の数が少なすぎるだけで(^^;
->>非破壊的操作のできないLisp
--(たった26個の)変数を破壊しまくりながら動くのでは？

#Wikiでの「返事」の書きにくさは、Paragraphつきでもあまり改善されないですね…
#もっともメールや掲示板は単純にその問題から逃避しただけなので、問題が顕在化してるだけWikiのほうが良いのかも知れませんが。

[[id:762]] 2002-09-03 13:39:49

再帰 in TinyLisp(?)

re: TinyBASICにはローカル変数がないので (#3)
> * 作れるのでは？
再帰にはローカル変数が必須だったと思ったのですが、スタックを自前で作って管理すれば大丈夫という気もしてきました。
そういえばTinyBASICって配列ありましたっけ？

#そもそも CONS や GC は TinyBASIC の範疇を激しく超えるような気が。CONSがなくちゃLISPじゃないよう。

> Wikiでの「返事」の書きにくさは、‥‥‥

パラグラフ右下の [ins] というリンクで、追記ボックスを当該パラグラフのすぐ下に持ってくることができます。
“re: [||[id:762]||] ”
という行は手書きです。
当Wikiの道具立ては今のところこのくらいです。m(_@_)m

#SHIMADA

[[id:1111]] 2002-09-03 14:11:24

左辺値Objectって考え方に意味は有るでしょうか？

よくある(rubyのmatz氏が言うところの「C風の文法の」)言語での、

a.hoge=b.fuga

という代入の式を評価するとき、左辺ってどう処理しようかな？と思いまして。

真人間ならきちんとしたParserが左辺と右辺の区別を厳格につけつつ処理させるんだろけど、
等号(もとい代入)記号の存在に由来する処理を行全体に広げず、局所的(ってのか)に行う方法って、有るのかなーとか妄想モード。

Cだと変数hogeのアドレスが判ればいい(他にも判らないとだめな情報は幾つもあるがさておき)のだから、
Cじゃなくても同じことをやればいいかなーと妄想。

んで、「あるObjectのある属性(名)へのアクセスPath」を保持したObject…
いわば左辺値(左辺名のほうが適切命名か?)Objectとでもいうものが有ったら、どうかなーと。

処理系は左から評価していって=を見つけたところでこの左辺Objectを生成する。
aのhogeという口にモノを注ぎ込む準備をする。まぁ「漏斗」みたいなものかな。

で、b.fugaの評価結果を、「その」漏斗に流し込む。

あ。左辺を先に評価しちゃったら駄目だな。あくまでポンコツ路線でいくなら、

a./hoge=b.fuga

かなあ。(PostScript風。/をつけるとSymbolの評価結果じゃなくSymbolそのものを表す)

駄目ぇ？(かわいく甘えてみるテスト(ぉ

属性入力欄に入力またはDragDropされた時の動作 (グラフ計算ソフト(仮称))

----
それと逆の規則になっているのが sh ですね。
hoge と書くと左辺値、 $fuga と書くと右辺値。SHIMADA (HashedWiki友の会)

-shのアレって、
--構造体だのObjectだのの類が無いので、左辺を決定するために何かを「評価」する必要が無い(よね)。
--ほっとくと何でも(クオートなんかしなくても)文字列として評価されちゃう(^^;
-っていう辺りから来た文法なのかなあ？ -戯

- shのアレは、置換を基本にしたセマンティクスだからだと思います。右辺も左辺も気にしない。とにかくまず$とか``とかを置換して、それから = が含まれていればシェル変数のモディファイルーチンに制御を渡すと。 -Schemer
--マクロしか無い言語…とまでは言わないけど、それに少し近い感じ? --戯

[[id:669]] 2002-09-02 10:30:50

Perlの最近のバージョン(5.6)では左辺値を返す

サブルーチンが書けるらしいですよ。

$var = 0;

sub some_routine : lvalue {
$var;
}
some_routine() = 10;
print $var;
==> 10

[[id:917]] 2002-09-02 10:31:06

rubyのhoge=のほうがすっきり…かな

> Perlの最近のバージョン(5.6)では左辺値を返す (#6)

def hoge=(v)
@hoge=v
end

などと書けるわけですよね。代入記号のようなもの(^^;をメソッド名に取り込むことが出来る。

- いや見ための問題ではなくて、左辺値を値として返せるということが（有意義かどうかは別として）面白いわけで。

[[id:918]] 2002-09-02 10:31:22

代入の記法

Assignment operator が "=" というのがそもそもイタいんじゃないかと思います。

せめてゲイツはブロック構文のあるBASICにおいて
LET x = 10
HOGE
HUGA
ENDLET
とするべきだったのにと激しく思います。
これなら「xを10と置くと…である」という学校で習う方程式とも矛盾しないでしょ。

----
状態遷移モデル(っていうのかな:たいていの手続き型言語に含まれてる機能)なプログラミング環境では、
「じゃあ、endletの所で、処理系はどうやってxを10と置く"前"の状態に戻るんだ？」と考えないとならないっすよね。

「環境」を持つか、変数だか束縛だか1つづつの単位で値stackみたいなのを持つか、
なんかかんかしないとならないと思うけど、
あの時代にソレをやるmemoryは十分に無かったのではないかと…

あとlet…endletの空間つーか環境つーかの入れ子関係を管理する何かも、持ってないとならんし。
そしてそれに更にmemory食うし。

状態遷移モデルは、過去の状態を機械が忘れるのを許すモデル、とも言いますよねきっと。 -戯
一方で算数/数学のほうでは、デフォでは(問題が存在する限り)何一つ忘れないモデルであるわけで。

----
let…endletの寿命を最適化するための定型的なやり方って、何か有るんでしょうか？ 末尾呼び出しの最適化みたいに。
有るならばそれが使えるんでしょうけども。

----
…おっと。「ブロック構文のあるbasic」っすか。QuickBasic以降でしたっけ？
うーん。その時代だと、メモリはまぁ足りるのかな…うーんうーん…

[[id:764]] 2002-09-02 10:31:50

SVOO

英語の文法の説明で出てきた記号だったと思ったけど。

主語、動詞、目的語1、目的語2
つーか
なにが、なにに、なにを、どうする
って奴。

で。「なにに」と「なにを」が有るのが今日の味噌。

捉え方によっては、一般に説明されているような「selfは主語である」という説明は、変だ。
OOPでいうReceiverとかselfとかthisは「なにに」ではないか。Receiver(受取人)という語意を考えてみれば当然だ。
-言語の語順による「不気味さ」をいかに除くか (プログラミング言語)での解釈はどうなる？
--動詞と目的語との順序の問題だ、と考えればいい。(そして同じ結論になる(笑))

「なにを」は、引数であると捉えてもいいし、メソッド(名)そのものであると捉えてもいいだろう。
後者の解釈の場合、動詞「どうする」は「適用する」つまり「do」に固定されてしまうということになるが。
前者ならば「どうする」はメソッド(名)そのものが入るだろう。

そして「なには」だが、これを今日はSenderと呼んでみたい。
そしてsenderの定義を、そのメソッド名の「解釈が書かれたもの」だと、捉えてみたい。
つまりDispatcherだ。

prototype oopだと、それはproto.proto.proto.…のどっか(^^;だろう。
Class oopだと、class.superclass.superclass.…のどっか(^^;だろう。
OOPなら動的に決まりそうだ。
Lispとかだと静的っすか？＞識者

これは、素朴(?)なOOP言語を実装するにあたっての、「super」とか「inherited」とかの機能を
実現するために、都合が非常に良い解釈だろう。

Dispatcher(文意で動的に決まるかも)は、selfに、引数云々を、処理云々してあげる。
Dispatcher(文意で動的に決まるかも)は、selfに、処理云々を、適用してあげる。

もちろん、副作用(が有る言語なら)の適用先の基点(てのか?)は、selfである。

----
Dispatcherがメソッド名の解釈を求められて答える答えは、以下のどっちかかな。
-メソッドそのもの
-メソッドを含んだ環境

うーん。クロージャ.protoが何を参照すべきか(つまりproto親が何であるか)が問題かな。候補は以下2つ。それとも両方必要(二股proto)か？
-メソッドそのもの
-メソッドを呼び出した環境

[[id:1091]] 2002-09-02 10:33:19

Smalltalkなら

re: SVOO (#9)
メッセージ式は
reciever message: argument.
なので、主語、動詞、目的語 の順になってます。self も reciever になり得ます。reciever = 主語 = 「何は」 です。

そして sender という言葉はそのメッセージ式が含まれるメソッドを持つオブジェクト、すなわち文脈上の self を指します。

# 多くのオブジェクトが "yourself" というメッセージに対して self を return します。

そういう枠組みで「何は」を sender としてしまうと、すべての文が
I send a message foo to bar.
になってしまう気がします。
Sender = Dispatcher という展開はちょっとよく分かりませんが。
#SHIMADA

[[id:1109]] 2002-09-03 13:19:01

re:Smalltalkなら (#10)


>reciever = 主語 = 「何は」です。

なんでそう言えるのか？ってのが疑問です。

aBird sing.
を「鳥は歌う」と読むのか、「鳥に歌わせる」と読むのか、という悩み(?)ですね。

>sender という言葉はそのメッセージ式が含まれるメソッドを持つオブジェクト、すなわち文脈上の self を指します。

メソッドを「持つ」ものではなく、メソッドを「呼ぶ」もの、ですよね、文脈上のselfは。

メソッドを「持つ」のは、それこそ、receiver(またはreceiverの向こうにあるDispatcher)ではないかと。

># 多くのオブジェクトが "yourself" というメッセージに対して self を return します。

その定義だと、Objectの固有の状態としてyourselfを持つのはヤバイんで、
きっと派生属性になってるんでしょうね。

-グラフ計算ソフト(仮称)で話に出てきた謎言語では、メソッド呼び出しの引数の括弧の中で、その意味でのyourself(たぶん)を小細工することになるような気がする。

>「何は」を sender としてしまうと、すべての文が
>I send a message foo to bar.
>になってしまう気がします。

そうです。「常に」文頭はIになってしまいます。

だからこそIの存在を暗黙視した状態でも多くのプログラミング言語が活動できていた(それで一見問題が無かった)わけで。

で、その隙に(ぷ)、別のものを主語だと見なして(見なし方をすりかえて)しまうという考え方が、色々出てきたのだと思います。
その中のひとつが「主語はReceiverである」かなと。

Iを「神」と読み替えると丁度話の辻褄は合いますね。
全ては神の御心のまま。Receiverの「主体性」は実は神の随意の反映でしかない、という。
我々人間は、なまじ我々もまた一介のReceiverに過ぎない(そしてそれを認識できる)存在であるために、
Receiverを主語に「据えたがって」るのかな。
#神も多態を使うんだろうか？それとも「自分で」Dispatchするんだろうか？
#定性的にも定量的(つまりCostPerformance)にも全能の神ならば、Dispatcherを「自動」化する「必要」は、たしかに無いのだが…

>Sender = Dispatcher という展開

逆にいえば、Dispatcherに何か良い名前を与えたいんですが、無いですかね？
Smalltalk(とか普通の言語)ではDispatcherは平時にはプログラミングの対象ではないですよね。
だからこれといった名が無いのかなーと…

送る人、というよりも、送るものがドレなのかを決める人ですかね。

正直いって、「文脈上のself」という考え方は、大雑把過ぎるような気がしてきています。
Smalltalkとかならそれでもいいんでしょうけど、もう少しミニマル(^^;な言語ならば、
self(Smalltalkでの)とdispatcherとmethod実体ObjectとがそれぞれObjectであるので、
どれをselfと呼ぶべきか？で、ちょっと迷っています。心身多元論みたいな感じぃ？
従来の文化の延長で考えていいものかどうかと。

上記のように「自分」っぽいものが少なくとも3つも考えられてしまうので、
最近ではヤケになってそれぞれ this self meとでも呼び分けてやろうか？と思ったりします。
ええ。これでは混乱に拍車がかかるだけなんですけどね(ぉ)。ヤケですヤケ。

#生Methodから産まれたClosure(だよね)も数えると4つになってしまいますが、
#protoの考え方で産むならば区別する必要は無いかな、とも思っています。

----
Object指向はSubject指向ではない(ぉ)ので、実のところ、「主語」がどれかということを考えなくても
Object指向は出来ちゃうんですよね。

[[id:1114]] 2002-09-03 14:58:19

re:re:Smalltalkなら(was re:re:[[id:1109]] (#11))


>self(Smalltalkでの)とdispatcherとmethod実体Object

これらはそれぞれ Squeak 3.2 でいうところの

self
thisContext method who first
thisContext method

で合ってますでしょうか？　と誰へとはなしに言ってみるテスト（ぉ。--sumim

----
やってみますた。--SHIMADA
thisContext
==> UndefinedObject>>DoIt

thisContext method
==> a CompiledMethod (1579)

thisContext method who
==> #(UndefinedObject #DoIt)

thisContext method who first
==> UndefinedObject

Squeakから見ると僕は UndefinedObject なんだそうです。ひどい扱いだ。（参照：もちろん，センダはあなた自身です。
----
いや。それなら、センダはあくまで SHIMADA さん自身で(これは言及されていません)、レシーバ(ここでの self)が nil (UndefinedObject の唯一のインスタンス)、送ったメッセージが DoIt だった…ということを Squeak は言いたいのではないのでしょうか？

ちなむと、本当のセンダ(thisContext sender receiver)はコンパイラ(Compiler のインスタンス)で、メソッド DoIt (thisContext method decompileString) のディスパッチャが UndefinedObject かと…思ったのですが、ハズしています？ --sumim
----
で、さっきの熊と鳥の話だと、

Object subclass: #Bear
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Experimental-Context'!

!Bear methodsFor: 'communicating' stamp: 'sumim 9/3/2002 17:46'!
talkToBird
Bird new sing! !


Object subclass: #Bird
instanceVariableNames: 'song '
classVariableNames: ''
poolDictionaries: ''
category: 'Experimental-Context'!

!Bird methodsFor: 'accessing' stamp: 'sumim 9/3/2002 17:45'!
sing
thisContext copy inspect.
^ song! !

で、Bear new talkToBrid を do-it したときに、Bird>>#sing において、センダ（thisContext sender receiver）が Bear のインスタンスで、レシーバ（thisContext reciver）が Bird のインスタンス、#sing（thisContext method decompileString）のディスパッチャ（thisContext method who first）が Bird てな具合で SHIMADA さんの説明通り…と。--sumim
----
むぅ〜。“ディスパッチャ”を「メソッドを「持つ」のは、それこそ、receiver(またはreceiverの向こうにあるDispatcher)」で勘違いしているっぽいですね。「送るものがドレなのかを決める人」ですか…。だとするとこの場合は、誰なんでしょうねぇ…。悩む。--sumim

[[id:1115]] 2002-09-03 18:14:07

selfがyourselfにメッセージを送信する、というのがSmalltalkらしさだと。

re: re:[[id:1109]] (#11)
aBird sing. という式を考えたとき、Smalltalkでは「鳥さん歌って」と読むことが強く推奨されます。（ぉ

叙述ではなく発話です。Bear というクラスのメソッド中にこの式が現れたとすれば
クマさんが鳥さんに話し掛けるというお人形遊びです。--SHIMADA

-神によって、発言者として祭り上げられてしまったのが、その熊さんだ、と
--ムハンマドの発言は、アッラーフによって喋らされていた、と

- このコンテキストからいったらクマにしゃべらせているのは遊んでいる子供でしょ
--言われた側に拒否権が有るかどうかの違い、かな。
--人形で「遊んでる」人ってのは誰なんでしょうね。
---子供自ら人形を動かしてる一人遊びの場合。これなら人形に拒否権が無いので、子供は神と等価。
---オトナ(でなくてもいいが)が人形を動かして子供と遊んでいる場合(=この方向の延長には人形「劇」がある)。Dispatcherは人形師だということになる。拒否権を「発動する」のは人形師。
----子供向けの劇なんかでよく有ることだが、客の子供のリクエストを聞くことはある。ただし常に受領可能なリクエストとは限らない(判断するのは人形師)。

----
C++やJavaのような言語のほうでは、話し掛ける人という考え方は、一切サポートされていないですね。
直接引数で渡しでもしない限り、呼んだのが誰なのかは闇の中です。

-とりあえずDelphiのイベントプロシジャ(の標準的な作り方)では、Senderという引数をやり取りすることになっています。
--ComponentのMethod参照がFormの特定のMethodを覚えていて、Componentにイベントが発生すると、そのMethodを叩く。
--叩くとき、引数Senderに、self(Componentのほう)を入れて呼び出す。
--呼ばれたForm側のMethodは、Sender(イベントが起きたComponent)がどれかを捉えることが出来る。
-そういや、VB(少なくともver2)にはSenderが無かったです。
--1つのMethodに対して複数有るかも知れないSenderを区別するための手段として、Component配列、という概念が有りました。Componentを予め配列に所属させておき、Component参照の替わりに、配列の添え字(整数)を渡す。

[[id:1116]] 2002-09-03 17:22:10

Sender, Receiver, Dispatcher....


まあ dispatcher を考える場合たいがいは receiver を静的な部分と
動的な部分に分けて，動的な部分を dispatcher に全部押し込めてい
るんだ，って思うのは考え方が狭すぎるんだろうな....

- sender は receiver の post box にメッセージを送る．
- receiver の dispatcher は自分の post box にメッセージがきてたら receiver 中の定義にしたがって適当な処理をする．
-- dispatcher が自分で処理するか fork するのかは別にして，ね．
-- dispatcher は fork したスレッドを待っててもいいし，待たなくてもいい．Smalltalk は待ってるモデル．待たない奴ってあんまりないけど．

-rubyにおいては、特異メソッドは Dispatcher==Receiver ですね。そういう言語では「静的と動的」と分けるわけにはいかなそう。 -戯
-Dispatcher!=Receiver のときは、Dispatcherは「ReceiverのReadOnlyな影」って感じかな。
-TikiGuion:ばぶばぶ/dictとobjとclassの実装の統合の下のほうの「掃き出し」ってのが、「押し込め」の感覚に似てるかも。

----
ありがとうございます。ん〜、でも分かっていないみたいです(^_^;)。横から出てきておいて、へたれなヤツで、すみません。

センダからレシーバに送られたメッセージの定義を探して特定しているのはインタプリタだと思うのですが（ContextPart>>#send:to:with:super: あたりで lookupSelector: を使って）、ではインタプリタがディスパッチャかというと、そういうお話ではなさそうですし…。　あ痛たたっ。もうしません。ごめんなさいっ(T_T)（ぉ--sumim

----
- 言葉の選択を間違えたせいで完全に違うようにとらえられたようです．
- ここで言った「静的な部分」っていうのは activity でない部分っていうくらいの意味です．実行時に変化するかどうかというはなしではなく，データ構造やメソッド定義など．
- 一方「動的な部分」というのは activity そのものです．スレッドでもプロセスでもなんと呼んでもいいですが．
- ....つまりは naive なオブジェクトのモデルの話だったのです．で，上でいってる話の言葉づかいはこういうのとは違うなぁっていう感慨だったのです．
- ....ほんとうは naive な concurrent object のモデル，かも．オブジェクトがスレッド持ってるタイプのやつ．ABCL/1 とか Pool-T とか Eiffel// とか．

[[id:1119]] 2002-09-03 23:26:09

自分なりの理解はこんな感じです

-「なにが」「どうする」「なにに」「なにを」はよさげ
-「なにが」部は「どうする」部の“解釈が書かれたもの”とする
- これはナイーブな OOPL の実装に際して“「super」とか「inherited」とかの機能を実現するために、都合が非常に良い解釈”

- Smalltalk では「なにに」「どうする」「なにを」になっているが？
-「なにが」部は特に意識されない。もしくは「なにが」「どうする」「なにを」とも

-「なにに」は主語だから事実上「なにが」と同じ、という展開は納得しがたい
- aBird sing は「鳥が」「歌う」か、（誰かが）「鳥に」「歌わせる」のか（の解釈の違い）
- （「なにに」になりうる）self は、「どうする」部の解釈が書かれたものではなく、「どうする」を“呼ぶ”もの
-「どうする」部の解釈が書かれたものは、あくまで「なにが」
- (だから「なにが」と「なにに」を同一視して扱えるはずがない)

-「なにが」は常に「私が」になって（固定されて）しまうが…？
- それでよい。また、別に、「私が」以外のものを据えるという発想もありうる。そういう意味で「なにに」の“なに”を「なにが」の“なに”に据えるという解釈その一つかと
-「なにが」は「神が」でもよい

-「熊が」「鳥に」「歌え」というのもありだが
-“熊”は傀儡。やはり「神が」
- 「神が」「熊に」
-“熊”に拒否権があれば「熊が」も可だが、そうではない

-「なにが」に何かよい名前はないものか？
-“送るものがドレなのかを決める人”

-「なにに」における「自分自身に」で“自分自身”とは何かを迷う
--「どうする」を“呼ぶ”もの　“this”
--「なにが」、すなわち「どうする」部の解釈が書かれたもの　“self”
--「どうする」手続き自体　“me”、そこから“産まれた”クロージャも

-「なにに」の“動的部分”が「なにが」の実体
-「なにが」は「なにに」の郵便受けに「どうする」を置く
-「なにが」は「なにに」の郵便受けに「どうする」を見つけると「なにに」の中の定義にしたがって適当な処理をする
-この時、「なにが」が自ら手を下さずともよい
----
かいつまむと、
-従来、「神が」で固定されていた「なにが」に着目し、ここに“神”以外を明示することでナイーブな OOPL におけるオーバーライド回避が楽に表現できるのではないか
- ひとくちに“自分自身”といっても少なくとも３種類想定しうる。Smalltalk を含めて従来の用い方はおおざっぱすぎる。それぞれに別の呼称を与えてたい衝動にかられる

てな具合なのですが…。--sumim

[[id:1125]] 2002-09-04 02:41:19

DispatcherとDispatchネタとは違う

すまんっす。また間違い。Dispatcherという*er単語が Activityを持つかどうか、ってのは全然考えてなかった。-戯

俺が考えていたのは、Dispatchの案内書であって、それを読んで実際にDispatch作業をする人
(=狭義でのDispatcher)では、なかったなぁ。

ただ、神の問題の裏返しなんだけど、*erが常にActivityを持つものを指すと解釈すると、
Threadエンジン以外の全てのObjectが*erに成り得ない、という極端なことになってしまう(^^;

なんかそれも行き過ぎな解釈かも…
----
たびたびすみません。

> 実際にDispatch作業をする人(=狭義でのDispatcher)では、なかった

これでいくぶんすっきりしました。“案内書”としての SVOO は面白い着想だと思います。で、ちなむと、確かに Smalltalk の文法では（SVO との解釈も可能だけれども）おっしゃるとおり基本的に“O V: O”で、普段は S を意識させない。　ただ、S が（ディスパッチャではなく）センダでよいのなら、thisContext という（self ほどは知られていない(^_^;)）偽変数を通じてメソッドの動的側面をいつでも参照できるようになっている。　センダだけでなく、メソッドの“解釈”を持つもの自身、および、メソッド本体自身という“文脈いかんでの自分自身”二者についても“大雑把過ぎ”とのご指摘の self と混同されることなく、この thisContext を通じて（専用の偽変数こそ用意されていませんが）前述の方法で明示的に表現でき、その必要があれば、センダが誰かによって処理を切り換える（ディスパッチする）ことも可能だということを申し添えたかったのです。--sumim

http://www.sra.co.jp/people/h-asaoka/study/SmalltalkTextbook/12/Textbook12.html

実際の self はレシーバ自身であるのに、上の文脈での“自分自身”の列挙においては、“センダ自身”と表記して含めたくなる雰囲気を感じました。なので、振り返って、やはり Smalltalk での O V: O の心は V: O が送られるレシーバ(O)が主格でいいのだな…と再確認しました。そんなことを考えていたら、構造化パラダイムでは V(O, O) と、他のパラメータと同格に扱われていたレシーバ(O)を、Smalltalk のオブジェクト指向パラダイムアプローチでは O V: O として明示することで、旧来はコメントとして添えなければならなかった情報を記述に含ませることができている…というピンソン本（ISBN4810180115）の記述がふと思いおこされました。SVOO は、これをさらに進めて、センダ（あるいは V に対するディスパッチの指南）という情報も記述に含めてしまおうという新しい問題解決アプローチだと考えることもできますね。--sumim

[[id:1129]] 2002-09-04 21:44:46

名前をどれに与えるかの問題

文法だか語法だかを考える場合の話ですが、
複数のモノが互いに関連しあっていて、それらのうちのどれか1つを掴むことさえ出来れば残りもそこから手繰れるぞってとき、
じゃあどれを最初に掴むことが出来るようにしておこうか？ってのが、問題になるでしょうね。

selfというモノはメモリ上にあるとして、ではこれを呼び出すために
ソース(=なにかを呼び出すためには「名」が必要な世界)では
selfという特別な一語さえあれば即座に取れるのか、
それともうだうだうだうだ書かないと取れないのか、
というのを決めていくのが、

言語を作る過程や選ぶ過程において、色々重要になってくると思います。

で、今回。
contextに「最初の名」を与えるか、それともsenderに「最初の名」を与えるか、
あるいは両方欲しいのか、
とか、そういう問題だと思います。
どれを(一番)掴み易くしておくのが吉か(or好みか)、と。
---
御意。--sumim

[[id:1134]] 2002-09-05 18:32:35

top recent

HashedWiki version 3 beta
SHIMADA Keiki