Yukihiro Matsumoto <ma...@netlab.co.jp> wrote:
|が,ruby界のもう一人の論客,前田さんは久野さんがCLUの連載を
|書いた89年頃には中学生か下手すると小学生だったのではないかと….
一応中学生にはなっていたと思います(^^;
この記事って
「CLU とその仲間たち」 bit. Vol. 21, No. 6-8, 1989
ですよね?
読んでみたいのですが、手に入らないでしょうね...。
# 「その仲間たち」というのが気になっています。
--
前田 修吾
sh...@po.aianet.ne.jp (Shugo Maeda) writes:
|この記事って
|
|「CLU とその仲間たち」 bit. Vol. 21, No. 6-8, 1989
|
|ですよね?
その通りです.実はちょうど昨日荷物の整理をしてたら第1回の載っ
てるbit '89年5月号を発見しました.
|読んでみたいのですが、手に入らないでしょうね...。
松江まで遊びに来れば見せてあげます.^^;;;
6回連載の1回だけですけど.
大塚まで遊びに行くと久野さんが見せて下さるかも.
# でも阪大の図書館にもあるんじゃないかなあ.
|# 「その仲間たち」というのが気になっています。
確か,東工大で作られたCLUで書かれたOSの話とか,CLUのオブジェ
クト指向っぽい拡張の話とか($の代わりに!を使う,でも束縛は静
的だったはず)などの話がありました.
って,原稿書いた本人の前でなんですが….
まつもと ゆきひろ /:|)
前田さん:
> 読んでみたいのですが、手に入らないでしょうね...。
そりゃよろしければコピーくらい送らせて頂きますけど。
> # 「その仲間たち」というのが気になっています。
Argus、xclu、nclu、Misty :-) 久野
Yukihiro Matsumoto <ma...@netlab.co.jp> wrote:
||「CLU とその仲間たち」 bit. Vol. 21, No. 6-8, 1989
||
||ですよね?
|
|その通りです.実はちょうど昨日荷物の整理をしてたら第1回の載っ
|てるbit '89年5月号を発見しました.
|
||読んでみたいのですが、手に入らないでしょうね...。
|
|松江まで遊びに来れば見せてあげます.^^;;;
(^^;
|# でも阪大の図書館にもあるんじゃないかなあ.
図書館にはちょっとなさそうな気がします。
# 基礎工とかに行けばあるのかな...。
|確か,東工大で作られたCLUで書かれたOSの話とか,CLUのオブジェ
|クト指向っぽい拡張の話とか($の代わりに!を使う,でも束縛は静
|的だったはず)などの話がありました.
!は単なる構文糖みたいですね。
PRIMARY!NAME (EXPRESSION, ...)
は
T$NAME (PRIMARY, EXPRESSION, ...)
と全く同じ意味だそうです。
でも気分的にだいぶ違いますね。
--
前田 修吾
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
|> 読んでみたいのですが、手に入らないでしょうね...。
|
| そりゃよろしければコピーくらい送らせて頂きますけど。
送っていただけるととてもうれしいです:-)
メールで住所などをご連絡すればよろしいでしょうか。
|> # 「その仲間たち」というのが気になっています。
|
| Argus、xclu、nclu、Misty :-) 久野
Mistyのコンパイラってftpでgetできるのでしょうか?
--
前田 修吾
sh...@po.aianet.ne.jpさん:
> 送っていただけるととてもうれしいです:-)
> メールで住所などをご連絡すればよろしいでしょうか。
いいですよ。完全に私信だな…
> Mistyのコンパイラってftpでgetできるのでしょうか?
うーん。掘り起こして来ないと…Common Lispに落とす奴ならどこで
も動くかな…
ちょっと復活さすの大変そうです。すいません 久野
ですね。日常的に使ってましたけど、実際は {n,x}clu だったかも。
配列も、例えば a[i] が array[type-of(a)]$fetch(a, i) だったりする構文
糖だったような。type-of は擬似コードですけど。
Misty は CommonLisp で書かれてたので、二の足を踏んだまま今に至ります :-)
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
|> メールで住所などをご連絡すればよろしいでしょうか。
|
| いいですよ。完全に私信だな…
すみません>みなさま
|> Mistyのコンパイラってftpでgetできるのでしょうか?
|
| うーん。掘り起こして来ないと…Common Lispに落とす奴ならどこで
|も動くかな…
|
| ちょっと復活さすの大変そうです。すいません 久野
すみません、面倒でしたら結構ですので...。
久野さんの他の言語のコンパイラなどは手に入るでしょうか?
# 最近並列オブジェクト指向にも興味が出てきました:-)
--
前田 修吾
SHIBATA Seiki <se...@flab.fujitsu.co.jp> wrote:
|> !は単なる構文糖みたいですね。
|
|ですね。日常的に使ってましたけど、実際は {n,x}clu だったかも。
|
|配列も、例えば a[i] が array[type-of(a)]$fetch(a, i) だったりする構文
|糖だったような。type-of は擬似コードですけど。
あと.や+などの演算子も全部そうですよね。
C++の演算子オーバーロードよりもきれいな気がします。
# ところでstring$add(s1: string; s2: string)はなぜ無いんでしょう。
|Misty は CommonLisp で書かれてたので、二の足を踏んだまま今に至ります :-)
これはコンパイラが遅いという意味なのでしょうか。
# あるいはLispがお嫌いとか(^^;
--
前田 修吾
.xxx が、左辺か右辺かで set_xxx, get_xxx になるんでしたっけ。
> C++の演算子オーバーロードよりもきれいな気がします。
operator+ じゃなくて add と書くならいいですか? じゃないですよね?
> # ところでstring$add(s1: string; s2: string)はなぜ無いんでしょう。
add じゃなくて、concat だから? 記憶あやしいですが。
> |Misty は CommonLisp で書かれてたので、二の足を踏んだまま今に至ります :-)
>
> これはコンパイラが遅いという意味なのでしょうか。
> # あるいはLispがお嫌いとか(^^;
単に CommonLisp のインストールが面倒臭い(と思ってる)だけです。
# それは嫌いということか…
しばた // se...@flab.fujitsu.co.jp
SHIBATA Seiki <se...@flab.fujitsu.co.jp> wrote:
|> あと.や+などの演算子も全部そうですよね。
|
| .xxx が、左辺か右辺かで set_xxx, get_xxx になるんでしたっけ。
そうです。
|> C++の演算子オーバーロードよりもきれいな気がします。
|
| operator+ じゃなくて add と書くならいいですか? じゃないですよね?
たしかC++だと二項演算子はメソッドじゃなくて2引数の関数にするんですよね?
僕は左辺をレシーバとみなして、+というメッセージを送ると考える方が好きです。
# CLUの場合は第一引数をレシーバとして特別扱いしているわけではないですけど、
# addは各クラスタで定義されますよね。
|> # ところでstring$add(s1: string; s2: string)はなぜ無いんでしょう。
|
| add じゃなくて、concat だから? 記憶あやしいですが。
+が使えないのはconcatと定義されてるからなのですけど、何でaddは定義されて
ないのかなと。
# stringでaddというのはおかしいから?
|> |Misty は CommonLisp で書かれてたので、二の足を踏んだまま今に至ります :-)
|>
|> これはコンパイラが遅いという意味なのでしょうか。
|> # あるいはLispがお嫌いとか(^^;
|
| 単に CommonLisp のインストールが面倒臭い(と思ってる)だけです。
なるほど。
うちではclispとgclを入れているのですが、あまり使っていないので
Mistyで使えるといいかなとか思ったりします。
--
前田 修吾
Mistyじゃなくp6やp1ならさすがに動くと思いますが、いっときますけ
ど私のコンパイラは「かろうじて動く」ですからまつもとさんや平野さ
んみたいなのを想像しないでくださいね ^)^; そういう才能がないんで
す。
柴田さん:
> .xxx が、左辺か右辺かで set_xxx, get_xxx になるんでしたっけ。
そうそう。
> operator+ じゃなくて add と書くならいいですか? じゃないですよね?
いや、こういう気分は重要だと思いますけどね。
> add じゃなくて、concat だから? 記憶あやしいですが。
そうconcatです。演算子でいえば || ですね。CLUはキーワード使い
まくりですから { } じゃなくend、条件つきand/orは&&、||じゃなく
cand、corです。あーこんな説明しとらんでbitの記事送ればいいんです
よね。
しかし今は家なので 久野
柴田さん:
> # Java の String も concat だけど、演算子は + ですよね。
これは実はBasicみたいで最初ちょっと嫌でした。
> # 2番目以降が勝手に toString() されるのは便利だけど。
なるほど。toString()と決めうちせず、左と右の型に応じて任意のメ
ソッドが呼べる構文糖を自由に定義可能な言語としたらなかなか楽しめ
そうですね。
混乱しそうだともいう ^_^; 久野
あ、誤解招く書き方でしたね、すいません。
C++ だと、気分以前に、メソッドと関数と両方で書けて一意性が無いんです。
しばた
やはり誤解を生む書き方でしたね。
じつは C++ はメソッドも関数も書けます。で、曖昧だと怒られたりもでき
ます :-)
つまり、構文として「きれい」か、意味的に「きれい」か、ということを言
いたかったのでした。
> |> # ところでstring$add(s1: string; s2: string)はなぜ無いんでしょう。
> |
> | add じゃなくて、concat だから? 記憶あやしいですが。
>
> +が使えないのはconcatと定義されてるからなのですけど、何でaddは定義されて
> ないのかなと。
> # stringでaddというのはおかしいから?
|| 演算子があるということで、単に英語としておかしいからのようですね。
じゃ、sequence や array にも concat はあったかな?
# Java の String も concat だけど、演算子は + ですよね。
# 2番目以降が勝手に toString() されるのは便利だけど。
しばた
sh...@po.aianet.ne.jp (Shugo Maeda) writes:
|前田です。
|たしかC++だと二項演算子はメソッドじゃなくて2引数の関数にするんですよね?
|僕は左辺をレシーバとみなして、+というメッセージを送ると考える方が好きです。
ええと,C++の場合メンバ関数としても定義できたような気がします.
それはともかく,+演算子は本来左辺の型によって処理が決定する
のではなく,両辺の型の組合せによって処理が決定するので,左辺
のメソッドであるのはおかしい,という意見もある訳です.私もそ
れはもっともだと思います.
たとえば,演算子を実装する時,右辺の内容に対するアクセスがき
れいにいかない時とかとくにそう思います.
# rubyでそうなっているのは「ご都合」ですね.
こういう演算子に一番適切なのは恐らくCLOSのようなマルチメソッ
ドですが(全ての引数の型でディスパッチされる),これだけのため
にマルチメソッドを言語に導入する訳にもいきませんしねえ.
まつもと ゆきひろ /:|)
今すぐにでも C++ という言語でお楽しみ頂けます :-)
# 構文糖じゃないですけど
しばた
Yukihiro Matsumoto <ma...@netlab.co.jp> wrote:
||たしかC++だと二項演算子はメソッドじゃなくて2引数の関数にするんですよね?
||僕は左辺をレシーバとみなして、+というメッセージを送ると考える方が好きです。
|
|ええと,C++の場合メンバ関数としても定義できたような気がします.
そうなんですね、知りませんでした(^^;
|それはともかく,+演算子は本来左辺の型によって処理が決定する
|のではなく,両辺の型の組合せによって処理が決定するので,左辺
|のメソッドであるのはおかしい,という意見もある訳です.私もそ
|れはもっともだと思います.
Rubyだとレシーバの型のみでメソッドが決まりますけど、C++だと
オーバーロードがあるので、メンバ関数にした場合でも、両辺の
型の組み合わせでメソッドが決定されますよね?
後からクラスを追加したい場合には困りそうですけど...。
|こういう演算子に一番適切なのは恐らくCLOSのようなマルチメソッ
|ドですが(全ての引数の型でディスパッチされる),これだけのため
|にマルチメソッドを言語に導入する訳にもいきませんしねえ.
CLOSみたいに最初からoperation-centricなシステムとして設計されていれば、
それはそれできれいだと思うのですが、class-centricなシステムではオブジ
ェクトの振舞いはクラスで定義されていた方が一貫性があってきれいかなと
思ったのでした。
--
前田 修吾
柴田さん:
> 今すぐにでも C++ という言語でお楽しみ頂けます :-)
> # 構文糖じゃないですけど
甘くないからやだ :-) 久野
P.S. C++のオペレータオーバローディングはなんか好きじゃないんです
よねー。CLUとそんなに違わないはずなのに…
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
|cand、corです。あーこんな説明しとらんでbitの記事送ればいいんです
|よね。
今日届きました、ありがとうございました。
# CLUは「くるー」と読むんですね。
最後のMistyの回で、動的束縛を取り入れるのにany[T]を使うという
のは目から鱗が落ちました。
Mistyを知らない方のために説明しますと、CLUでは静的束縛のみなの
ですが、Mistyではanyを型パラメタ付きのクラスにすることで動的束縛
を取り入れています。
具体的には、変数を
x: any[t1]
と宣言することでxにt1とその子孫のインスタンスを代入できるように
なり、xに対するメソッド呼び出しは動的束縛になります。
# 当然xに対して呼び出せるメソッドはt1で定義されているものに限定
# されます。
any以外の型の変数の時はサブクラスのインスタンスを代入することは
できないので静的束縛になります。
Javaだと動的束縛にするか静的束縛にするかはクラスの設計者の手に
委ねられていますけど、Mistyだとユーザが選択できるのがいいですよね。
# SatherもMistyとは違う仕組みですけど同じ利点がありますね。
|Mistyじゃなくp6やp1ならさすがに動くと思いますが、いっときますけ
|ど私のコンパイラは「かろうじて動く」ですからまつもとさんや平野さ
|んみたいなのを想像しないでくださいね ^)^; そういう才能がないんで
|す。
p6/p1というのはどういう言語なのでしょう。
--
前田 修吾
前田さん:
> # CLUは「くるー」と読むんですね。
ううむ。そういえば「目蒲線」を「めかません」と読むのを知らなかっ
た方も昔いましたけど。
> 最後のMistyの回で、動的束縛を取り入れるのにany[T]を使うという
> のは目から鱗が落ちました。
あと何枚残ってます? :-)
> any以外の型の変数の時はサブクラスのインスタンスを代入することは
> できないので静的束縛になります。
「Mistyは厳密な型検査のオブジェクト指向言語」というのがキャッ
チフレーズでした。
> p6/p1というのはどういう言語なのでしょう。
p6というのは並列オブジェクト指向言語で、最初の実装を作っていた
ら6日で動くようになった言語です :-) で、p1はうちの学生さんが作っ
たProduce/1という言語の対称メッセージという機能だけを取り出して
p6に混ぜた言語です(6の次は0だけどそれは日曜でお休みだからその次
の1、というつもりもありました)。
ちなみにエディタは自作のe9というのをまだ使っている 久野
P.S. すいません、全然返事になってないですね。p6は情報処理学会論
文誌vol. 38, no. 3, pp. 563-573, 1997. p1は情処研報
96-PRO-12, pp. 67-72, 1996.
P.P.S. bit誌の5月号に単発記事を書いたのですが、これが「プログラ
ミング言語関係用語集」でして当然私の発明した変な用語も混ぜて
:-) あります。興味あればどうぞ(4月12日頃発売ですけど)。
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
|> 最後のMistyの回で、動的束縛を取り入れるのにany[T]を使うという
|> のは目から鱗が落ちました。
|
| あと何枚残ってます? :-)
まだまだたくさん残ってます:-)
|> any以外の型の変数の時はサブクラスのインスタンスを代入することは
|> できないので静的束縛になります。
|
| 「Mistyは厳密な型検査のオブジェクト指向言語」というのがキャッ
|チフレーズでした。
同じ静的型付けといっても、JavaやC++だと実行時に不正なキャストが
起こる可能性がありますけど、CLUやMistyなんかだと安全ですよね。
Javaもparameterrized typeを導入してキャストなんか無くしてしまえば
いいのに。
# あとArrayStoreExceptionもありましたね。
|P.S. すいません、全然返事になってないですね。p6は情報処理学会論
| 文誌vol. 38, no. 3, pp. 563-573, 1997. p1は情処研報
| 96-PRO-12, pp. 67-72, 1996.
探してみます。
|P.P.S. bit誌の5月号に単発記事を書いたのですが、これが「プログラ
| ミング言語関係用語集」でして当然私の発明した変な用語も混ぜて
| :-) あります。興味あればどうぞ(4月12日頃発売ですけど)。
こちらも楽しみです。
# serealizeも載ってるんでしょうか(^^;
--
前田 修吾
前田さん:
> 同じ静的型付けといっても、JavaやC++だと実行時に不正なキャストが
> 起こる可能性がありますけど、CLUやMistyなんかだと安全ですよね。
しかしMIT CLUにはこういう恐ろしい関数が付属してました。
_cvt = proc[t1:type, t2:type](t1) returns(t2)
> Javaもparameterrized typeを導入してキャストなんか無くしてしまえば
> いいのに。
> # あとArrayStoreExceptionもありましたね。
まあコンパイラ作るとparametrized typeは大変なんですけどね。
> 探してみます。
そうそう、個人的には前田さんに読んで欲しいのはこれかな。
久野、静的型検査を行なうオブジェクト指向言語Mistyにおける動的
な型の扱い、コンピュータソフトウェア, vol. 9, no. 2, pp. 88-101,
March 1992.
いかにもな題名でしょ :-)
> # serealizeも載ってるんでしょうか(^^;
それが載っていないんです。というのは私がアンチ分散オブジェクト
だから。言われてみれば確かに載ってもおかしくはないのですが、、、
幸い原稿もう出してしまいました :-) 久野
前田さん:
> 久野さんがアンチ分散オブジェクトというのはちょっと意外ですね。
bitの記事をお楽しみにと言っておきましょう。ここで全部ネタばら
ししたらつまんないですよね。読んだら続きを投稿してください :-)
と、売り上げに貢献する ^_^; 久野
P.S. 他の執筆陣 → 萩本さん、羽生田さん、平野さん、、、、
ku...@gssm.otsuka.tsukuba.ac.jp wrote:
|> 同じ静的型付けといっても、JavaやC++だと実行時に不正なキャストが
|> 起こる可能性がありますけど、CLUやMistyなんかだと安全ですよね。
|
| しかしMIT CLUにはこういう恐ろしい関数が付属してました。
|
| _cvt = proc[t1:type, t2:type](t1) returns(t2)
そんな(^^;
| そうそう、個人的には前田さんに読んで欲しいのはこれかな。
|
| 久野、静的型検査を行なうオブジェクト指向言語Mistyにおける動的
|な型の扱い、コンピュータソフトウェア, vol. 9, no. 2, pp. 88-101,
|March 1992.
|
|いかにもな題名でしょ :-)
ですね、楽しみです。
|> # serealizeも載ってるんでしょうか(^^;
|
| それが載っていないんです。というのは私がアンチ分散オブジェクト
|だから。言われてみれば確かに載ってもおかしくはないのですが、、、
久野さんがアンチ分散オブジェクトというのはちょっと意外ですね。
--
前田 修吾