K.Maebashi's BBS

　配列の実装は、結果的にまったく違うものになっています。配列領域を固定で スタックに持つことでGCを無くす。この目的のために結果的に多くの修正をしま した。下記のようなプログラムとディスアセンブルコードを見てください。 　この並列はずいぶん悩みましたが、結果的に一番良いであろう方法に落ち着き ました。 ---------------------------------- int main() { int[2][3] i5dim; int id = 33; boolean[2] bdim1 = { true , false }; int[2][3] idim21 = {{1,2,3},{4,300,65536}}; int[2][3][4] idim3 = {{{1,2,3,4},{5,6,7,300},{8,9,10,11}}, {{11,12,13,65536},{14,15,16,17},{18,19,20,21}}}; double[4] ddim1 = { 0.0, 1.0, 4.1, 5.1 }; string[5] sdim1 = {"aa","bb","cc","dd","ee"}; int a1; i5dim[1][2] = 1; a1 = i5dim[i5dim[1][2]][0]; } ---------------------------------- 　　↓ 　下記のように、配列の定数は配列定数バッファーに詰め込んで保持し、1命令で 配列変数に書き込みです。もちろん配列数と一致したデータ以外はエラーです。 また、変数の配列次元数が一致しない場合もエラーになる処理が入っています。 int[10]　P;　P = P;　の様なポインター的なコードが書けない仕様です。 　　↓ バイトコード 　　↓ 1:*** 一般関数情報ダンプ ****************** 1:int main() 1:*** ローカル変数の表示 no = 8 *** 1: 0:int [2][3] i5dim 1: 1:int id 1: 2:boolean [2] bdim1 1: 3:int [2][3] idim21 1: 4:int [2][3][4] idim3 1: 5:double [4] ddim1 1: 6:string [5] sdim1 1: 7:int a1 1:*** 配列定数 数 = 5 ********** 1: 0:int 配列 [2] size=20 1:int[0] = 1 1:int[1] = 0 1: 1:int 配列 [2][3] size=36 1:int[0][0] = 1 1:int[0][1] = 2 1:int[0][2] = 3 1:int[1][0] = 4 1:int[1][1] = 300 1:int[1][2] = 65536 1: 2:int 配列 [2][3][4] size=108 1:int[0][0][0] = 1 1:int[0][0][1] = 2 1:int[0][0][2] = 3 1:int[0][0][3] = 4 1:int[0][1][0] = 5 1:int[0][1][1] = 6 1:int[0][1][2] = 7 1:int[0][1][3] = 300 1:int[0][2][0] = 8 1:int[0][2][1] = 9 1:int[0][2][2] = 10 1:int[0][2][3] = 11 1:int[1][0][0] = 11 1:int[1][0][1] = 12 1:int[1][0][2] = 13 1:int[1][0][3] = 65536 1:int[1][1][0] = 14 1:int[1][1][1] = 15 1:int[1][1][2] = 16 1:int[1][1][3] = 17 1:int[1][2][0] = 18 1:int[1][2][1] = 19 1:int[1][2][2] = 20 1:int[1][2][3] = 21 1: 3:double 配列 [4] size=44 1:double[0] = 0.000000 1:double[1] = 1.000000 1:double[2] = 4.100000 1:double[3] = 5.100000 1: 4:string_no 配列 [5] size=32 1:string[0] = 9 1:string[1] = 10 1:string[2] = 11 1:string[3] = 12 1:string[4] = 13 1:*** 文字列 数 = 14 *** 1: 0: "main" 1: 1: "i5dim" 1: 2: "id" 1: 3: "bdim1" 1: 4: "idim21" 1: 5: "idim3" 1: 6: "ddim1" 1: 7: "sdim1" 1: 8: "a1" 1: 9: "aa" 1: 10: "bb" 1: 11: "cc" 1: 12: "dd" 1: 13: "ee" 1:*** 使用予定のスタックサイズ = 426 1:*** 関数コードのディスアセンブラ size = 63 1: 0 push_int_1byte 33 1: 2 pop_stack_int 1 1: 5 set_array_literal_int 0 2 1: 10 set_array_literal_int 1 3 1: 15 set_array_literal_int 2 4 1: 20 set_array_literal_double 3 5 1: 25 set_array_literal_string 4 6 1: 30 push_int_1byte 1 1: 32 push_stack_array 0 1: 35 push_int_1byte 1 1: 37 push_array_int 1: 38 push_int_1byte 2 1: 40 pop_array_int 1: 41 push_stack_array 0 1: 44 push_stack_array 0 1: 47 push_int_1byte 1 1: 49 push_array_int 1: 50 push_int_1byte 2 1: 52 push_array_int 1: 53 push_array_int 1: 54 push_int_1byte 0 1: 56 push_array_int 1: 57 pop_stack_int 7 1: 60 push_int_1byte 0 1: 62 return 1:*** 行情報 数 = 10 *** 1: 4: from 0 size 5 1: 5: from 5 size 5 1: 6: from 10 size 5 1: 8: from 15 size 5 1: 9: from 20 size 5 1: 10: from 25 size 5 1: 13: from 30 size 11 1: 14: from 41 size 19 1: 19: from 60 size 2 1: 15: from 62 size 1 1:*** end of main() --------------

>ここで埋め込まれる関数インデックスって、VM内で一意になるんですよね? >だとすれば、コンパイル単位の破棄の際に破棄対象の関数が使っていたインデックスの >ところをぎゅっと圧縮しようとさえ思わなければ、そもそも振りなおし自体不要なのでは >ないかと思うのですが…… 同じ所に、こう書いてあります。 >>　次にスピードの点ですが、現在はVMメイン管理で一元的にカウンターを持ってい >>ますが、これを関数単位でもてば、（ぱ）さんの指摘する問題は回避できます。 >>　ただ、初期は出来る限り単純なもので済ませたいとの思いがあり。簡単な機構で >>すめばそのままにしています。 上記のように、今のところ優先順位が低いので、後回しにしています。 もちろん、圧縮等はしていないので、比較的簡単に実装出来ると思います。 たぶん二人とも同じことを考えてると思います。

>　コンパイル時の負荷はまず棚においておいて、実際問題、再コンパイルが頻繁に >行わなければならない処理が多いと思われますか?、実際的に考えればそんな設計は >良い設計とは思えません。 うーん、再コンパイルの頻度は低くても、それが起きるたびに以後の関数呼び出しに ついてすべて一度ずつリンクが入るのはちょっと心配ですがそれはさておき、 ここで埋め込まれる関数インデックスって、VM内で一意になるんですよね? だとすれば、コンパイル単位の破棄の際に破棄対象の関数が使っていたインデックスの ところをぎゅっと圧縮しようとさえ思わなければ、そもそも振りなおし自体不要なのでは ないかと思うのですが……

>この方法だと、コンパイル単位が増えてきたとき、プログラムの端のほうでちょろっと >動的リンクが発生しただけで、それこそprint()みたいにあちこちで使われる関数の >呼び出し箇所すべて(通るところだけですが)に対し再リンクが必要になるような…… 　必ず突っ込まれるで有ろうと予測した部分が突っ込まれました^^。確かに再コンパ イルが頻繁に行われるようであれば、当然負荷が増えるでしょう。でもその場合、 コンパイル時に再リンクも大きな負荷に思えます。 　コンパイル時の負荷はまず棚においておいて、実際問題、再コンパイルが頻繁に 行わなければならない処理が多いと思われますか?、実際的に考えればそんな設計は 良い設計とは思えません。 　ではなぜ、動的コンパイルが必要だったか。それは、複数の違った処理を一元的 にメニュー管理する目的があったのです。利用目的ですね。このような利用目的が 無い場合、動的コンパイラは不要です。だからdiksamとは指向性が多少違います。 　次にスピードの点ですが、現在はVMメイン管理で一元的にカウンターを持ってい ますが、これを関数単位でもてば、（ぱ）さんの指摘する問題は回避できます。 　ただ、初期は出来る限り単純なもので済ませたいとの思いがあり。簡単な機構で すめばそのままにしています。 　うう～～上記文は多々説明不足な気がすごくしますが、説明を始めると長くなっ てしまいそうなので短文にしています。「もっと説明しろ！」との指摘がありまし たら、ぜひ言ってくださいませ。

>はい、一つ目は文字列バッファーにある関数名インデックスを示し、二つ目はコン >パイル単位カウンター、三つ目は関数ID＝インデックス、四つ目はパラメターの数 >です。P2，P3は実行時に埋め込まれます。コンパイルカウンターは、１～最大値ま >でのループカウンターで動的コンパイル実行時かコンパイル単位の消滅処理時に >＋１されます。コード上は最初は0そしてカウンターは1なので、値が違うためP1の >関数名から動的リンクをしてP2に１、P3に関数インデックスが埋めこめられ、この >関数インデックスで直接関数が起動されます。以後、P2のコンパイルカウンターが >一緒なら、P3で直接関数起動です。直接起動の前にIF文が一回入る程度です。 うーん、いまいちわかりませんが、 ・call_functionのふたつめのオペランドを「P2」として、 ・「コンパイルカウンター」は、「動的コンパイル実行時かコンパイル単位の 　消滅処理時に＋１」というくらいだから、VMにひとつだけ存在するカウンタですよね? つまり、動的コンパイルが動いたり、逆にバイトコードを破棄したりするたびに VMの状態が変わるわけですが、この「状態」に対して、1から始まる連番が振られて いるわけですね。 で、call_functionごとに、それがリンクされた時点の連番(コンパイルカウンター)が 埋め込んであり、呼び出しごとに現在のコンパイルカウンターと比較して違っていたら 再リンクする、と。 この方法だと、コンパイル単位が増えてきたとき、プログラムの端のほうでちょろっと 動的リンクが発生しただけで、それこそprint()みたいにあちこちで使われる関数の 呼び出し箇所すべて(通るところだけですが)に対し再リンクが必要になるような…… ちなみにDiksamでは、バイトコード中の関数インデックスはコンパイル時に 決めています。これは「バイトコードごと」の関数インデックスであり、 ver.0.2～0.3系列では、リンク時に、これを「DVMごと」のインデックスに置き換えます。 ver.0.4では、置換は行わず、変換テーブルをバイトコードごとに持っています。 今のところ動的なバイトコードのアンリンクは実装していません。実装する場合、 DVM上のFunctionテーブルのis_implementedをfalseにすることになるかと思います。

　追記、変数名とか関数名も文字列バッファーに入れています。これは言語のIDE サポートのためです。今デバックのために使っているモニターシステムがあるの ですが、これを高機能にすればIDEになるので、言語デバック用に簡単なIDEをと 思い追加しています。このデバックモニターシステムはC#で作られています。

>2つ目と3つ目のオペランドは全部0, 0なのですが、関数の方はprintf, sprintf, printの はい、一つ目は文字列バッファーにある関数名インデックスを示し、二つ目はコン パイル単位カウンター、三つ目は関数ID＝インデックス、四つ目はパラメターの数 です。P2，P3は実行時に埋め込まれます。コンパイルカウンターは、１～最大値ま でのループカウンターで動的コンパイル実行時かコンパイル単位の消滅処理時に ＋１されます。コード上は最初は0そしてカウンターは1なので、値が違うためP1の 関数名から動的リンクをしてP2に１、P3に関数インデックスが埋めこめられ、この 関数インデックスで直接関数が起動されます。以後、P2のコンパイルカウンターが 一緒なら、P3で直接関数起動です。直接起動の前にIF文が一回入る程度です。 　このような感じで、スレッドセーフな動的リンクを実現しています。実はこれには 面白い副作用があって、例えば画面に文字を出す関数を動的コンパイル単位にすれば。 メインは一切い変更せず。あるときはゴシックで表示、コンパイル単位の消滅そして、 最コンパイルすると、その時から丸文字表示で文字が出される等が可能です。 　関数の内部機能を動的に変えることが出来ます。もちろん総てのスレッドにスレッ ドセーフで。でも、使い道はそんなに無いかもしれませんけどね。^^; そうそう、今の所同じ関数名でも違う文字列IDですが、暇が出来たら同一IDにする 予定。 VMを作り始めてから何度もも構文処理からの修正が必要になり。なかなか前に進み ません。書きあがって動いても、スレッドセーフの問題点が見つかり、書き直しも ごそごそと。言語としては最終的なつめなので、すぐには終わりそうにないです。 　でも、思った通りに作れるのはいい感じです。

自己フォロー。 >おそらく4つ目のオペランドが引数の数、2つ目か3つ目が関数のインデックス >なのだと思いますが(確か分割コンパイルはなかったと思うので、ひとつ余りますね…) >最初のオペランドは何でしょう? 2つ目と3つ目のオペランドは全部0, 0なのですが、関数の方はprintf, sprintf, printの 3種類ありますので、これが直接関数のインデックスということはないですね。 単なる場所取りで、実行前に第1オペランドの文字列を使ってインデックスを検索して ここに埋め込むとか……

おお、私はDiksamのほうにさっぱり手を付けられないでいる間に、 だいぶ進んでいますね。 ぱっと見で目を引くのは関数呼び出しのインストラクションのオペランドの 数の多さですが、 >1: 9 call_function 3 0 0 4 おそらく4つ目のオペランドが引数の数、2つ目か3つ目が関数のインデックス なのだと思いますが(確か分割コンパイルはなかったと思うので、ひとつ余りますね…) 最初のオペランドは何でしょう? 関数名を文字列のコンスタントプールで保持していて、そのインデックスに 見えますが、用途がよくわかりません。リンク用の情報で、実行時には使わない? >1:*** 文字列 数 = 9 *** >1: 0: "main" >1: 1: "str" >1: 2: "printf P1 = %d P2 = %d P3 = %d >" >1: 3: "printf" >1: 4: "sprintf P1 = %d >" >1: 5: "sprintf" >1: 6: "print" >1: 7: "---------- test ---------

　追記で、バイトコードも結構変わっています。下記に。 >---------------------------------- >int printf(string str); >string sprintf(string str); >int print(string str); > >int main() >{ > string str; > printf("printf P1 = %d P2 = %d P3 = %d\n",12,20,30); > str = sprintf("sprintf P1 = %d\n",13); > print(str); > print("---------- test ---------\n"); >} >---------------------------------- ↓ 　バイトコード ↓ 1:*** 一般関数情報ダンプ ****************** 1:--- int main() 1:*** ローカル変数の表示 no = 1 *** 1: 0:string str 1:*** 文字列 数 = 9 *** 1: 0: "main" 1: 1: "str" 1: 2: "printf P1 = %d P2 = %d P3 = %d " 1: 3: "printf" 1: 4: "sprintf P1 = %d " 1: 5: "sprintf" 1: 6: "print" 1: 7: "---------- test --------- " 1: 8: "print" 1:*** 使用予定のスタックサイズ = 240 1:*** 関数コードのディスアセンブラ size = 65 1: 0 push_string_const 2 1: 3 push_int_1byte 12 1: 5 push_int_1byte 20 1: 7 push_int_1byte 30 1: 9 call_function 3 0 0 4 1: 18 pop 1: 19 push_string_const 4 1: 22 push_int_1byte 13 1: 24 call_function 5 0 0 2 1: 33 pop_stack_string 0 1: 36 push_stack_string 0 1: 39 call_function 6 0 0 1 1: 48 pop 1: 49 push_string_const 7 1: 52 call_function 8 0 0 1 1: 61 pop 1: 62 push_int_1byte 0 1: 64 return 1:*** 行情報 数 = 6 *** 1: 8: from 0 size 19 1: 9: from 19 size 17 1: 10: from 36 size 13 1: 11: from 49 size 13 1: 13: from 62 size 2 1: 12: from 64 size 1 1:*** end of main() --------------

　ようやく下記のようなプログラムがVMで実行可能になりました。可変長 パラメータ用の書式は作らず、一部の組込み関数のみ可能にしました。 言語としての美しさは…、スタック情報も大きく変わり、VMはほとんど別の ものになりつつあります。VMの完成にはまだまだです。printfはCのprintf と同等ですが、中身はエミュレートを被せてオーバラン等の危険は一切 ありません。 ---------------------------------- int printf(string str); string sprintf(string str); int print(string str); int main() { string str; printf("printf P1 = %d P2 = %d P3 = %d\n",12,20,30); str = sprintf("sprintf P1 = %d\n",13); print(str); print("---------- test ---------\n"); } ---------------------------------- 　前に出した、組込み関数とのインターフェースは大幅に変更となり。 下記のようになっています。 //== スタック上の組込み関数データ =================================== struct NFstartDat { ushort vtype; // データタイプ E_StackDType ushort size; // スタック消費サイズ ushort m_vmid; // VMID = スレッドID ushort m_prm_inno; // 引き渡されたパラメータ数 void *m_sdatp; // スレッド別データ用ポインター S_Value *m_prmp[PRMMAX]; // 引き渡されたパラメータ S_Value m_return; // 関数からの戻り値データ }; //=================================================================== // 組み込み関数用定義 //=================================================================== class C_NFBase { protected: //-- VMから受け取る情報 ---------------- int m_fid; // 関数ID //-- VMに送る情報 ---------------------- char *m_name; // 関数名 int m_prmno; // 要求するパラメータ数0-10まで20は可変関数 ES_ValueType m_type[PRMMAX]; // 要求するパラメータの型 ES_ValueType m_return_type; // リターン変数タイプ public: C_NFBase() { this->m_name = NULL; this->m_prmno = 0; for(int i=0;i<PRMMAX;i++) { this->m_type[i] = ES_NON; } //----------------------- this->m_fid = 0; this->m_return_type = ES_INT; } virtual ~C_NFBase() { } virtual void * VMstart() { } // VM起動時実行 virtual void VMend() { } // VM終了時実行 virtual void funcexe(NFstartDat *nfd) { } // 関数起動メソッド inline char ** getname() { return &this->m_name; } inline int getprmno() { return this->m_prmno; } inline ES_ValueType getprmtype(int no) { return this->m_type[no]; } inline void setfid(int fid) { this->m_fid = fid; } inline ES_ValueType getrtntype() { return this->m_return_type; } };

>今度印刷してじっくり読んでみます。 ぜひ是非。Diksam でも活用可能かもしれません。 ＃ご出版、おめでとうございます。

>アマゾン詣でをしていたら、、 >こんなんありました！！ > >http://www.amazon.co.jp/dp/4774138959 >2009/6/20 あっ、まだ私のところに見本誌も届いていないのに! 価格とかページ数とか、今はじめて知りました。いやマジで。 >いやー楽しみです。 ありがとうございます(表紙がどんな感じになるのかとか、私も楽しみにしています)。 いやそのなんと言いますか、マイナーな分野だけに、ぜひともよろしくお願いいたします(_o_)

>ちゃんと知るには発案者のシェルリ自身が >書いたものに一度目を通しておくのが無難かと思います。 紹介ありがとうございます。片方は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の操作はアトミックであることを保証してはいないので、 割り切ってしまう、という考え方もあるかもしれませんけれど。 # ポインタが不正になってクラッシュするのはさすがにまずいのかなあ。 # でも、黙って間違った答を吐くアプリケーションはもっとひどいと思うけど。