K.Maebashi's BBS

>ちゃんと知るには発案者のシェルリ自身が >書いたものに一度目を通しておくのが無難かと思います。 紹介ありがとうございます。片方はsumimさんのページから辿ってちょっと読みかけたのですが、 けっこう量が挫折してました。今度印刷してじっくり読んでみます。

そうですね。C++ のテンプレートテクニックにも同名のがありますね。ややこしやー。ｗ そんなかんじで Traits にはいろいろと別物がある上、ブラックたち（というかシェルリ） の Traits にインスパイヤされたと言明されたものでも、たとえば Scala の Traits の ように一部機能を限定した実装もあるので、ちゃんと知るには発案者のシェルリ自身が 書いたものに一度目を通しておくのが無難かと思います。 Flattening Traits http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.5836&rep=rep1&type=pdf Traits: Composable Units of Behavior http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf

アマゾン詣でをしていたら、、 こんなんありました！！ http://www.amazon.co.jp/dp/4774138959 2009/6/20 いやー楽しみです。

>すみません、ちょっと一筋縄ではいかないようです。 やっぱりそうでしたか、yaccエラーを無くすまでは出来たのですが。内部的な 問題が発生してしまって、当面は無視して先に進むことにします。^^;

>下記のようなプログラムで、ただのブロックを書いた場合、diksamで構文エラー >になります。4.01でも。これをエラーにしないように、diksam.yを修正したいの >ですが、お暇がありましたら何かアドバイスをお願いいたします。 そういえば、Diksamはぶら下がりifの類を許していないので、複合文も 作っていませんでした。 Cと同じように文の一種としてcompound_statementを導入すればよいのでは、 とちょっと試してみたのですが、yaccでconflictが出ました。 考えてみればDiksamでは配列リテラルがあるので、「{」の後に式が来たとき ブロックなのか配列リテラルの始まりなのかがわからないわけです。 こういう場合、構文規則を変形してreduceのタイミングを遅らせる手法が 使えることがありますが、現状のDiksamのブロックは、「{」の直後で 埋め込みアクションが動くようになっており、そのためにはreduceが必要です。 すみません、ちょっと一筋縄ではいかないようです。

返信が遅くなりましてすみません。 >それは SELF の trait ですね。ここでいう Traits は、メソッドのセットを用いた多重 >継承機構で、従来のクラスやそれに準ずるものを用いた多重継承から一歩踏み込んだもの >です。Squeak Smalltalk で実効性が示されて、その後、各種言語で応用されています。 >新しい言語では言語組み込みのものもあったりと、ちょっとした流行りの機能かと。 > >http://www.slideshare.net/hiratara/traitmooserole/7 URLを紹介いただきありがとうございます。 Java上がりの私には、Scalaをベースとしたこちらの説明がわかりやすかったです。 http://www.ibm.com/developerworks/jp/java/library/j-scala04298.html 検索してみるとC++のテンプレートのテクニックとしてEffective C++第3版で 紹介されているものがあるようですが、これはまた別物……ですよね。 # うちにあるEffective C++は第2版まででした。 このところ日々の仕事に追われるばかりで、各種情報が追いかけられていないです。 いかんなぁ。

下記のようなプログラムで、ただのブロックを書いた場合、diksamで構文エラー になります。4.01でも。これをエラーにしないように、diksam.yを修正したいの ですが、お暇がありましたら何かアドバイスをお願いいたします。 -------------------------- int func01() { { int a1; } } --------------------------

>traitsは、「プロトタイプベース言語でクラスを実現するもの」ぐらいの認識でしたが、 >これも元祖はSmalltalk? ……と思ったら別物? それは SELF の trait ですね。ここでいう Traits は、メソッドのセットを用いた多重 継承機構で、従来のクラスやそれに準ずるものを用いた多重継承から一歩踏み込んだもの です。Squeak Smalltalk で実効性が示されて、その後、各種言語で応用されています。 新しい言語では言語組み込みのものもあったりと、ちょっとした流行りの機能かと。 http://www.slideshare.net/hiratara/traitmooserole/7

>他方で古くはデザパタ、ユニットテストやアジャイル的な手法、比較的新しいところでも >Classbox や Traits などのような静的型でも応用の利く役立つ物を次々と編み出して >くるのも、また Smalltalk 愛好者たちなので、 今日検索して知ったのですが、ケント・ベックってSmalltalkの開発者だったんですね。 知りませんでした。 http://biography.sophia-it.com/content/%E3%82%B1%E3%83%B3%E3%83%88%E3%83%BB%E3%83%99%E3%83%83%E3%82%AF traitsは、「プロトタイプベース言語でクラスを実現するもの」ぐらいの認識でしたが、 これも元祖はSmalltalk? ……と思ったら別物? http://sumim.no-ip.com:8080/wiki/818

>山さんの言語でこのあたりを変えるとなると、fix_tree.cでのTypeSpecifierの >扱いが変わってくるはずです。 はい、実質中では同じような構造を持っていますが意味が多少違ってきました。 　いまようやくVM 入り口まで書けるようになりました。可変スタックはなかなか やっかいです。まずは動くことを目指してスピードUPはまた今度で書いています。

>ひとつのVMで複数のスレッドを動かすのではなく、VMごと分けてしまって、 >それぞれ別のスレッドで動かせばよいのではないでしょうか。 　大きな単位でのスレッドのことだと思いますが、当初はそう考えていましたが、 結局言語を作ることになったので、理想を少しあげてみました。 >Rubyのまつもとゆきひろさんが以前こんなことを書いています。 >　(中略) >>という(むしろforkを活用すべきという)意見を述べています。 　言語としての統一性と、インタープリター言語としてのスレッド化は、理想的な 形で両立するのは難しいと思います。なので、私はスレッド向けに参照操作を すっぱりなくしました。グローバルシステム変数にいたっては…、いやこれは目的 アプリケーションのためで…。 　でも、せっかくだから殆どの面でスレッドセーフにすることで、利用者は並列動作 のためのプログラミングルールを気にすることなく書けるようになるのではないか と思いチャレンジしています。 　それに、一般的な言語だったら、C/C++なりJavaなりその他のもっといい言語が あるので、作る気なんてしません。^^　どうせ作るなら一般言語では出来ないよう な事を、です。

>おお、ご本人が降臨されるとは。 降臨だなんて勘弁してください。^^; >主義者を殲滅というのは物騒でいかんですねえ。反省。 型安全性を重視する人にとっては、Smalltalk 愛好者やそのやり方・考え方は、正気の 沙汰とは思えないいい加減さがあるでしょうから、「自分の周りからできれば排除した い…」と思うのも、やむを得ない反応だと思います。 他方で古くはデザパタ、ユニットテストやアジャイル的な手法、比較的新しいところでも Classbox や Traits などのような静的型でも応用の利く役立つ物を次々と編み出して くるのも、また Smalltalk 愛好者たちなので、そういう成果物はどんどん活用したいと 思っている人には、生かさず殺さずのさじ加減が難しい存在でもあるでしょうね。ｗ

>この BBS では、だいぶ久しぶりですよね。 恐縮です。 >実は Actor よりも Alan Kay のアイディアの方が先だったとは... >勉強になりました。_o_ ストラウストラップによるＯＯの再定義（抽象データ型のＯＯの提唱）が後にくるので アクターが先、ＯＯはあと、というのが定説になってしまったようです。ふたつのＯＯを 無理矢理ひとくくりにしてしまうと、こんな歴史的な事実も歪曲されてしまうのですね。

>int func(p1[],p2[]) >{ > p1[2]=10; // これはOK > p2[4]=9;　　　　// これはOK > p1=p2;　　　　 // これがエラーです >} >ひょっとしてdiksamはOKでしたか？ DiksamではOKです。Diksamの配列の仕様はJavaとほぼ同じですので。 よって、[]は演算子です。 int[][]という型の式に対し、1回適用すればその式の型はint[]になりますし、 2回適用すればintになります。 山さんの言語でこのあたりを変えるとなると、fix_tree.cでのTypeSpecifierの 扱いが変わってくるはずです。

>私は「クラス単位」で「オブジェクト」で分割です。 前から思っていたのですが、「クラス」と「オブジェクト」の区別、ついてます? >しかしこれは構造化ですよ。オブジェクト指向ではありません。 すてぜりふ?

>　では、スレッド間で複数のデータを渡す場合の方法が無いのではないだろうかと思われ >るでしょう。これには、変数集合体のパック、アンパック機能を提供し、複数の情報を >パックして他スレッドに渡すことで、スレッドセーフを保障しています。 いまさらなのかも知れませんが、スレッド間のデータの受け渡しがこれぐらい疎結合で よいのなら、ひとつのVMで複数のスレッドを動かすのではなく、VMごと分けてしまって、 それぞれ別のスレッドで動かせばよいのではないでしょうか。 このスレッドでは、まさにそういうことを話していたつもりでした。 http://kmaebashi.com/bbs/thread.php?boardid=kmaebashibbs&from=1221&range=1 >この要求に対しポインターや参照を操作することは、スレッドセーフを著しく >阻害する要因です。 >なぜなら、2つのスレッドで同じ参照を持った場合、そのデータアクセスに対し >スレッドセーフを自動で行うことはとても大変であり重い処理となります。 少なくともDiksamの設計なら、ヒープもグローバル変数もDVMの配下にあります。 よって、DVMを複数生成すれば、ふたつのスレッドで同じオブジェクトへの参照を 持つことはありませんし、グローバル変数も別です。 その上で、VM共有変数とかを導入して、VM間のデータのやり取りを考えれば よいのではないかと。 スクリプト言語において、ひとつのVMで複数のネイティブスレッドを使うことに関しては、 Rubyのまつもとゆきひろさんが以前こんなことを書いています。 http://www.rubyist.net/~matz/20070530.html >global interpreter lockを使っているので、native threadを使ってもさほど >並列性はあがらず性能もあがりません。 >というのも、オブジェクトアクセスひとつひとつを排他制御しなければならないので、 >コンフリクトは無視して問題が起きそうなら自分で対処というようなC++のような >対応はスクリプト言語では難しいでしょう。 (中略) >また、PythonのGuido van Rossumはスクリプト言語の並列性について >http://mail.python.org/pipermail/python-3000/2007-May/007414.html >という(むしろforkを活用すべきという)意見を述べています。 まあ、JVMなんかでも、doubleの操作はアトミックであることを保証してはいないので、 割り切ってしまう、という考え方もあるかもしれませんけれど。 # ポインタが不正になってクラッシュするのはさすがにまずいのかなあ。 # でも、黙って間違った答を吐くアプリケーションはもっとひどいと思うけど。

で、以下の指摘については、何の反論も弁明もなしですか? >仮に実装継承による差分プログラミングを(いろいろの弊害は度外視して)認めると >しても、それが趣旨ならUpperStackをStack型の変数に代入してはいけないし、 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1269&range=1 >Stack st = new Stack(); にて、SEさんは、なぜUpperStackをStackに代入しているのですか? そうすることによるメリットは何ですか? >スタックから要素を取得するメソッドはget()をオーバーライドしてはいけません。 >getUpper()のような別のメソッドを作るべきです。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1260&range=1 にて、なぜget()をオーバーライドしたのですか? そうすることによるメリットは何ですか? >>FileWriterを例にした方がいいかもしれません。内容的には同じ意図です。 >「同じ意図です」って、どういう意図でしょうか? で、どういう意図でしょうか? #「抽象化」とか、まるっきり意味のない回答をしないでくださいよ。 >FileWriterがこういう継承関係になっている「意図」を理解しているのなら、 >オセロ盤に棋譜を吐かせるのに、Boardクラスによりによって「ファイル名」を >渡すなどという設計がでてくるはずがないのですけど。 >http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1303&range=1 私には、SEさんが、継承やポリモルフィズムを理解しているようにはとても見えないのですけど。 # ていうか「インスタンス」も理解してなさそうな。

>>http://kmaebashi.com/programmer/c_yota/module.html >まずモジュールの定義が私と違っていたようです。 >(ぱ)さんの所で言うモジュールは「ヘッダファイル単位」で、私の言っていたのは「ライブラリ単位」だったようです。 むちゃくちゃですね。 「ヘッダファイル単位」っていったいどういう意味ですか? 私がどこかにそんなことを 書きましたか? (書いてあるというのなら引用してください) ご自分が何を言っているか 自分で理解していますか? 「モジュール」が先に決まって、それに対応するヘッダファイルを作ることはあっても、 ヘッダファイルが先に決まることはありえないでしょう。常識的に考えて。 よってモジュールが「ヘッダファイル単位」などということがあるわけがありません。 これではモジュール切り分けの指針がどこにもないではないですか。 件のページで、私はこう書いています。 >さて、Cでは、ソースファイル単位で名前空間の隠蔽が出来ますが、プログラムの >規模がさらに大きく、ソースファイルの数自体が膨大になってくると、今度は、 >いくつかのソースファイルをまとめて、もう1段階大きな固まりを作る必要が >出てきます。以下、この文章中では、この固まりのことを「モジュール」と呼びます。 ># こういうのは「ライブラリ」と呼ばれることもありますが、「ライブラリ」と ># 言うとどうも「下請け」的なイメージがあって、私にはちょっとしっくり来ません。 SEさんは、Cでは、「せいぜいDBアクセスとか通信部分など」しかモジュール化しない そうですが、これはやはり私と同様、「ライブラリ」には下請け的なイメージを 持っていて、DBアクセスとか通信部分のような下請け部分しかモジュール(SEさん用語の ライブラリ)にはしない、と言っているわけでしょう。 では、「せいぜいDBアクセスとか通信部分など」以外の部分は、Cの時代には、 どのように作っていたのですか? いっさい分割なしのぐちゃぐちゃですか? >私は、実装隠蔽の単位としてクラスは適当だと思っていて、機能を単位とするのは間違いだと思います。 で、なぜそう思うわけですか? 具体的にどのような例で、クラスで分割するとうまくいって、機能を単位とすると うまくいかないわけですか? 具体例としてSEさんから出てきたのは、[1287]のこの例だけです。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1287&range=1 >ちなみに簡単に変更できた例は、 >メモリ上で頻繁に検索するデータが100件から6万件に変わった時の事でした。 >検索にキャッシュやヒストリー機能などあらゆる機能を組み込み高速化しましたが、 >修正したクラスは1つです。もしCの構造化で組んでいたら、修正箇所と影響範囲を >調べるだけで嫌になっていたと思います。 これを普通に読めば、なにかの検索機能という「機能を単位とした」モジュールが あって、それがうまいこと隠蔽されていたから修正箇所がそこだけで済んだ、という 話にしか読めません(誤読であればご指摘ください)。 そこで私は、「そんなものはオブジェクト指向以前の、モジュール化で達成している ことではないか(よって、オブジェクト指向の利点ではない)」と指摘しているわけです。 ここでそう書いてますよね? http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1292&range=1 >関連する操作やデータをまとめる、というのは普通にモジュール化であって、 >私が「疑りぶかい～」で書いたオセロの例の、Cでstaticで隠蔽を行った >board.cで達成していることでは? 機能単位のモジュール化では実現できず、オブジェクト指向なら実現できることの 具体例を示してもらわないと、SEさんにとってのオブジェクト指向の定義がさっぱり わからないです。

(ぱ)さんも感じているのではないかと思いますが、何か全てが少しづつ違うようです。 ただこの違和感は経験があります。構造化とオブジェクト指向の違いによる違和感です。 (ぱ)さんは、モジュールは「ヘッダ単位ファイル」で「機能」で分割ですね。 私は「クラス単位」で「オブジェクト」で分割です。 プログラムの組み方も変わります。イメージ的に言うと縦割りと横割りぐらい違います。 話が噛み合わないのは、この縦割りと横割りで見方が違うためでしょう。 実際、構造化プログラミングの観点で言えば、(ぱ)さんの意見は納得出来ます。 私もその観点で言えば、「クラスとカプセル化した関数は同じ」とか、 「利点をあげるとしたら見やすさ」などと言うと思います。 しかしこれは構造化ですよ。オブジェクト指向ではありません。

>おお、ご本人が降臨されるとは。 この BBS では、だいぶ久しぶりですよね。 実は Actor よりも Alan Kay のアイディアの方が先だったとは... 勉強になりました。_o_ >「殲滅」ではなくて「粉砕」でしたね。 >しかも対象は「Smalltalk原理主義者」ではなく「Smalltalk原理主義」。 > >主義者を殲滅というのは物騒でいかんですねえ。反省。 字面はたしかにそうでも、内容からすると「河野さんを殲滅せよ！」って感じなので、 実は合ってるかも。:-) 河野さんのボケっぷりが懐かしいですな。

>そういう経験もあって、2000年2月ころに書いたのがこちら。 >http://kmaebashi.com/programmer/c_yota/module.html まずモジュールの定義が私と違っていたようです。 (ぱ)さんの所で言うモジュールは「ヘッダファイル単位」で、私の言っていたのは「ライブラリ単位」だったようです。 ただ、ヘッダーファイル単位だとしてもクラス単位とは違うので、CでJavaと同じ単位ではないと思います。 >なお、なにせCなのでモジュール化の単位はクラスではないですけど、 >これはその方が都合がよいという考えでそうしています。 >Javaでも、メンバのアクセスレベルがデフォルトで「パッケージ」になっている >あたり、「実装隠蔽の単位としてクラスは適当ではない」というのが現状の >コンセンサスでいいんじゃないかと思っています。 私は、実装隠蔽の単位としてクラスは適当だと思っていて、機能を単位とするのは間違いだと思います。

　会話の上で言語仕様に食い違いがあった原因を今理解しました。私の考慮不足だったの ですが、当初より言語に求める基本機能に、スレッドセーフなシステムでした。この要求 に対しポインターや参照を操作することは、スレッドセーフを著しく阻害する要因です。 　なぜなら、2つのスレッドで同じ参照を持った場合、そのデータアクセスに対しスレッド セーフを自動で行うことはとても大変であり重い処理となります。同一スレッド内でも その機構の一部が動いてしまいます。これは避けたいことです。 　次の問題がもっと深刻です。参照先が複数データの場合、他の何らかのサポートなしに 参照された複数のデータをスレッドセーフにすることは原理的に不可能です。 　以上2つの理由により、一番最初から、ポインターや参照を直接操作する行為は無いとの、 大前提が私の思考基本にありました。そのため、無意識にそれが前提で思考や会話をして いたことを気がつきました。よくある事ですが考慮不足です。 　では、スレッド間で複数のデータを渡す場合の方法が無いのではないだろうかと思われ るでしょう。これには、変数集合体のパック、アンパック機能を提供し、複数の情報を パックして他スレッドに渡すことで、スレッドセーフを保障しています。これは始めて 説明しています。その他にもスレッドセーフを自動保障するシステムがあります。まだ 説明されていません。しばらくお待ちください。なにぶん自己検証を先にしたくて。 本当に申し訳ありません。

>>int[] func(p1,p2,p3); >>これの　int[]　配列の戻りが禁止になっています。 > >対策するのであれば、ユーザには、配列への参照自体を取得できないようにしておかな Cで言う所のポインターの存在がありません。だから、グローバル変数に参照を 入れることが出来ません。 int func(p1[],p2[]) { p1[2]=10; // これはOK p2[4]=9;　　　　// これはOK p1=p2;　　　　 // これがエラーです } ひょっとしてdiksamはOKでしたか？ （駄目だと思い込んでいました）仕様が変わっています。

>int[] func(p1,p2,p3); >これの　int[]　配列の戻りが禁止になっています。 具体的にどうされているのかがよくわかりませんが、少なくとも、関数の戻り値の型として 配列型を返せないようにするだけでは不完全ではないでしょうか。 ユーザが、配列への参照を取得できるのなら、それをグローバル変数に代入することも できるはずで、もしそれをされたら、関数を抜けてスタックが開放された時点で 不正なポインタになってしまいます。 対策するのであれば、ユーザには、配列への参照自体を取得できないようにしておかないと だめなのでは。

>ええと、ということは、そもそもユーザは配列への参照を取ることができない >(配列を引数として別関数に渡すときは内部的には参照が作られるが、ユーザがそれを >変数に代入したりすることはできない)ということでしょうか? >それなら問題ないように思います。CやJavaに慣れた身にはちょっと不便そうですが。 言葉足らずですみません。 int[] func(p1,p2,p3); これの　int[]　配列の戻りが禁止になっています。 int func(p1[][],p2[]) これは問題ありません。内部で操作しても問題なく処理されます。 配列は参照渡しなので、子関数で操作したものは、呼びだし関数の配列内が変わります

>>Cですごくありがちなバグである、 >　配列の参照戻しは今エラーにしています。もともと、配列は参照渡しなので、 >リターンで戻す必要を感じなかったので。 ええと、ということは、そもそもユーザは配列への参照を取ることができない (配列を引数として別関数に渡すときは内部的には参照が作られるが、ユーザがそれを 変数に代入したりすることはできない)ということでしょうか? それなら問題ないように思います。CやJavaに慣れた身にはちょっと不便そうですが。

　やはり寝ながら思いついたアイデアは細部まで検討されていませんでした。 出来なくは無いのですが、副作用が見つかったし。やはりトリッキーでnew事態の 一般的な意味の仕様も変えてしまうのは問題が有るので、上のアイデアは 無かったことにしてください。　orz 　今日は寝れそうに無くなってしまった…

>Cですごくありがちなバグである、 　配列の参照戻しは今エラーにしています。もともと、配列は参照渡しなので、 リターンで戻す必要を感じなかったので。 　いや～～寝ようとしたら、動的配列生成でトリッキーな方法を思いついてしまって 眠れなくなってしまいました、ここ2日間の作成をチャラにして元に戻そうかな～～ 　何を思いついたかと言うと、配列をnew宣言したときにスタック上の配列データの所を 開ける、その為にスタックを移動することです。スタックにリアルアドレスを持ってい るわけではないし、アドレス操作をするときは移動してないわけで。たぶん問題ないかと。 　ああ～～～だめだ、思いついたらやらないでおけなくなってしまう。寝ながら だめだ、だめだ、こんな変なこと考えてはと、何度繰り返したことか。でも、どうせ 好きに作れるんだからやってしまおう^^ どう思いますか？　

>>(1)Cのように、配列の領域をスタック上に取る。 >ご指摘ありがとうございます。前の書き込みからVMをいろいろ調べていましたが、 >まさに(1)の方法を取ろうと思っています。このレス読んだのがちょうど今日なん >ですよ。 この方法を取るとして、ローカルな配列への参照を、別関数に渡すことは できるのでしょうか? できるとしたら、配列への参照がプログラマの思いのままにできるということですから、 Cですごくありがちなバグである、 char *get_line() { char buf[256]; /* bufに値をつめる処理 */ return buf; } みたいなのも許すことになりませんか?

　上記の仕様変更により。yacc,lex部分からの修正をしています。 下に示すようなプログラムに。diksamの言語仕様と離れていってしまうのは 仕方の無いことかもしれません。それに、ほぼC言語に近くなってしまう。 ちなみに、配列変数宣言時に[]内に変数を入れるとエラーになります。 ---------------------------------------- int main(int p1,int p2) { 　　int aa; 　　string[1+2] msg = { "asd","qwe","zzz"}; 　　int[1+1+1] i1 = {1,2,65537}; 　　int[10][9] id; 　　id[5][4] = 321; 　　aa =id[9][8]; } ---------------------------------------- 　結局の所、GCを装備して配列の動的確保を可能にし、管理のための処理及び間接 アクセスのためのオーバーヘッドを許すか。領域を固定にもって直接スアクセス し、高速で単純な処理だが配列領域は宣言時に固定で確保しなければならないか。 のチョイスで有ったのではないかと思います。 　私は今回、連続的な処理（一般的なプログラム）より。マルチスレッドで複数の 小さな処理の集合体による制御を優先しているので下の方を選びました。単にGCを 入れたくなかっただけかもしれませんが^^;