K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]

新規投稿 | 開設者ホームページへ戻る | ヘルプ

[703] Re:オブジェクト指向「初」入門
投稿者:CES
2007/02/20 02:13:25

>>何が過剰なのかわからないのです。 > >[684]に書いたことを繰り返すつもりはありません。 #こういう終わり方は大嫌いなのですが 「意思の疎通ができてないみたいなので、これまでとしましょう」って打ち切っていいですか? >>「クラス」も「スーパークラス」も、全く過剰だとは思えないので。 > >もはや日本語むちゃくちゃになっていませんか? > >「スーパーサイヤ人に過剰な期待をするのはいかがなものか」 >「悟空もベジータも、全く過剰とは思えない」 > >意味不明です。 まだ酔っ払ってますか? 何故そんな言葉を持ち出されたのかさっぱり分かりません。 最初の文の意味が通じなかったのならば補足します。 「術語としてのクラス」に「辞書的な『分類』という意味」を期待するのは、まったく過剰ではないと思える、ということです。 何が「過剰な期待」で、何が「過剰でない期待」なのか。術語には何なら期待していいのか。 [684] を何度読み返しても、それがわからないんですよ。
[この投稿を含むスレッドを表示] [この投稿を削除]
[702] crowbar ver.0.4のバグを修正しました
投稿者:(ぱ)
2007/02/20 02:13:25

># つhttp://www.shiro.dreamhost.com/scheme/docs/cont-j.html 紹介していただいたshiroさんのページは、以前読んだことはあったのですが、 あまり理解できずにそのままになっていました。 そこで今回、以下のページのActionScript版をベースに、crowbar版を書いて 試してみたところ… クラッシュしました。 http://torus.jp/memo/x200403/nandemo_keizoku_as.rd.html 調べてみたら、「配列リテラルの要素にオブジェクトを格納すると、一時的に スタックからの参照が切れることがあり、そのタイミングでGCすると死ぬ」という 潜在バグが(おそらくver.0.2から)あり、かつ、ver.0.4では「毎回GCする」という テスト用の状態でリリースしてしまったために発覚しました。 取り急ぎ修正版をリリースしました。毎度テストが甘くすみません。 力尽きたので今日はここまでです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[701] Re:正規表現関連の関数の質問
投稿者:タイガー
2007/02/20 02:13:25

>crowbarでも、CRB_dev.hにあるオブジェクト確保系の関数群において、自動的に >参照をスタックに積んでしまうことは可能です。ネイティブ関数実行後スタックを >戻す処理も、処理系側で苦もなくできます。 >なぜ今そうなっていないかというと… うーん、何故なんでしょう? (^^; >たとえば、オブジェクトを確保して、すぐに既存の配列の要素にセットする、 >という場合、特にスタックに積む必要はないのでその辺の無駄を嫌ったような >気がしますが、現状の仕様は、「いつGCが起きる可能性があるか」という点について >crowbarの内部実装をネイティブ関数の作者に晒していることになりますから、 >大変よろしくないですね。次バージョンでは修正します。 > >ネイティブ関数側で、大量のオブジェクトの確保/破棄を繰り返すような処理が >あるとすると、スタックが大量に無駄になりますが、そんなことわざわざ >ネイティブ関数で書かないですよねえ… あるいはその場合でも、 >ネイティブ関数用を呼び出したときのCRB_LocalEnvironmentに >local referenceの表を持ち、スタックではなくそちらに参照を入れるようにして >おけば、ネイティブ関数のプログラマに手で解放させることも不可能ではないですし。 ご教授ありがとうございます。 GCに少し興味を持ったのですが、お勧めのサイトなどありますか? 以下の本を購入しようと思ったのですが、(ぱ)さんは読んだことありますか? http://www.amazon.co.jp/exec/obidos/ASIN/0471941484/qid=1136566955/sr=1-1/ref=sr_1_10_1/250-0589622-2949018
[この投稿を含むスレッドを表示] [この投稿を削除]
[700] Re:多態性(ポリモーフィズム)について
投稿者:happie
2007/02/20 02:13:25

>そちらのblogも拝見しました。 ありがとうございます。 >「業務アプリケーションにはオブジェクト指向は >向かない」というのは同意見です。まあ業務アプリでも、フレームワークや、 >アプリケーションの「機能」の側でOOを使うところはたくさんありますが、 >「データ」に処理は結びつかないと思います。 そうなんですね。処理系、GUIアプリだとOOは相性はいいのですが、多くの本で、その辺の区別をせずに何でもOOがいいとして、で業務アプリを例にとって解説しているのですが、構造を見るとあまりOOっぽくない。最近流行のDIも、シングルトンを使ってかつインターフェースに対する実装クラスは一つが基本なので、これってOOなのって思ってしまいます。 >ということで、総論では賛成ですが、「メモリ中心では無理だから」という方の >理由付けはいらないんじゃないでしょうか。メモリに載ろうが載るまいが、 >あるいはオブジェクト指向データベースがディスク上のデータを透過的に見せて >そのへんの問題をすべてクリアしてくれようが、データに処理が結びついていない以上、 >やっぱりオブジェクト指向には合わないのだと思います。 確かにそのとおりですね。データと処理が結びつかないという議論とは別でした。 形上、オブジェクト指向的に作ったところでデータベースとの絡みでいろいろと問題が出てくるし、データベース中心に考えていった方がいいんじゃない、ということで、業務アプリケーションはオブジェクト指向に向いていないということを言おうとしていました。現在のORマッピングツールでは駄目ですね。おっしゃるとおり、たとえオブジェクト指向データベースで完全に透過的になったとしても、やっぱり「オブジェクト指向的」としか言えないでしょうね。
[この投稿を含むスレッドを表示] [この投稿を削除]
[699] Re:多態性(ポリモーフィズム)について
投稿者:(ぱ)
2007/02/20 02:13:25

>はじめまして。happieと申します。 はじめまして。 >また『ポインタの完全制覇』や「疑り深いあなたのためのオブジェクト指向再入門」 >については、本質的なところを突いているため大変興味深く読ませていただきました。 ありがとうございます。 >(ぱ)さんは、ポリモーフィズムに関してあまり記述がなかったように思いますが、 >どのようにお考えですか。 ポリモルフィズムは重要な概念だと思います。 「疑り深い~」でポリモルフィズムについて触れていないのは、今のところまで書いて 力尽きたというか、優先度がそれほど高くないと思ったからです。 マルチプルインスタンスについては、オブジェクト指向を普通に使っている人なら 誰でも普通に使っているにもかかわらず、そして初心者は結構そこでつまずくにも 関わらず、ほとんど誰もそれを重要であると声に出して言わないので、 これはまずいだろ、と思いあれを書いたわけですが、インタフェースと ポリモルフィズムに関しては、私は重要だと思いますし、誰もが重要だと言いますから、 特に声を上げる必要もないかなあ、と。 ただ、ポリモルフィズムが実際にどういう場面でどこまで使えるか、という点に ついては注意を払う必要があるとは思います。 最近、この掲示板の[649]にも書いていますが、「CADを作るとき図形にdraw() メソッドを付けるのは正しいのか」という話を、私はしょっちゅう出しています。 そちらのblogも拝見しました。「業務アプリケーションにはオブジェクト指向は 向かない」というのは同意見です。まあ業務アプリでも、フレームワークや、 アプリケーションの「機能」の側でOOを使うところはたくさんありますが、 「データ」に処理は結びつかないと思います。 業務アプリでは、たくさんのテーブルがあり、また、さらにたくさんの「機能」が あります。そして、しょっちゅう機能追加を行っても、そうそうテーブル定義には 変更を加えません。データが何よりえらいのであって、処理がデータに依存しても、 データが処理に依存してはいけない。これは基本的には「CADで図形にdraw()メソッドを 付けるべきではない」というのと同じことだと思います。 ということで、総論では賛成ですが、「メモリ中心では無理だから」という方の 理由付けはいらないんじゃないでしょうか。メモリに載ろうが載るまいが、 あるいはオブジェクト指向データベースがディスク上のデータを透過的に見せて そのへんの問題をすべてクリアしてくれようが、データに処理が結びついていない以上、 やっぱりオブジェクト指向には合わないのだと思います。
[この投稿を含むスレッドを表示] [この投稿を削除]
[698] Re:正規表現関連の関数の質問
投稿者:(ぱ)
2007/02/20 02:13:25

>>これは、Cの関数を抜けた後の話ですよね。レジストリに登録するという。 >>crowbarでは、Cの関数の実行中でも、ヒープ関連の関数を呼び出すと >>GCが動く可能性がありますから、ひとまずスタックに積まなければなりません。 > >私はよく分かっていないのですが、このcrowbarのアプローチは >メジャーなのですか? たぶん、メジャーでも、望ましいものでもないと思います。 Rubyだと、GCがCスタックをスキャンするから何もしなくてよく、 Pythonだと、参照カウンタを上げたり下げたりを手でやらなければいけなかったと 思いますが(過去形?)、たとえばJavaのJNIでは、別にCスタックをスキャンする わけでもないのに、確保したオブジェクトについては特に何もする必要はありません。 JavaHouseにある首藤さんの記事によれば、 http://java-house.jp/ml/archive/j-h-b/013314.html | JNI: native method のフレームごとに local references (の表) を用意、 | local references から辿れるオブジェクトは回収しない。 とのことです。 crowbarでも、CRB_dev.hにあるオブジェクト確保系の関数群において、自動的に 参照をスタックに積んでしまうことは可能です。ネイティブ関数実行後スタックを 戻す処理も、処理系側で苦もなくできます。 なぜ今そうなっていないかというと… うーん、何故なんでしょう? (^^; たとえば、オブジェクトを確保して、すぐに既存の配列の要素にセットする、 という場合、特にスタックに積む必要はないのでその辺の無駄を嫌ったような 気がしますが、現状の仕様は、「いつGCが起きる可能性があるか」という点について crowbarの内部実装をネイティブ関数の作者に晒していることになりますから、 大変よろしくないですね。次バージョンでは修正します。 ネイティブ関数側で、大量のオブジェクトの確保/破棄を繰り返すような処理が あるとすると、スタックが大量に無駄になりますが、そんなことわざわざ ネイティブ関数で書かないですよねえ… あるいはその場合でも、 ネイティブ関数用を呼び出したときのCRB_LocalEnvironmentに local referenceの表を持ち、スタックではなくそちらに参照を入れるようにして おけば、ネイティブ関数のプログラマに手で解放させることも不可能ではないですし。 >>ただ、たぶんこの場合、グローバル変数を共有して動かしたいのだと思います。 >>そうだとすれば、外部crowbarスクリプトのトップレベルを動かす方法は >>ありません。ただし、外部crowbarスクリプト中の関数であれば、 >>CRB_compile()とCRB_call_function()を使えば実行可能です。 > >外部crowbarスクリプト中の関数を呼べるということは、 >データを引数でC側からcrowbarの関数側にプッシュしてあげて、 >crowbarスクリプトのglobal変数に保存しておけば、 >データの共有はできると思います。 誤解させる書き方をしてしまったかもしれませんが、CRB_compile()と CRB_call_function()を使う方法なら、インタプリタを共有できますから、 グローバル変数によるデータ共有が可能です(まあ、引数で受け渡しするほうが よいのはよいでしょうけど)。 >私は、(ぱ)さんの本はほとんど持っていますが、もう少し内容を濃くして >「プログラミング言語を作る」もぜひ出版して欲しいです。 >早くていつ頃になりそうですか? いやあ、それはさっぱりわかりません。 まだ企画が動き出したわけですらないですし。
[この投稿を含むスレッドを表示] [この投稿を削除]
[697] Re:オブジェクト指向「初」入門
投稿者:(ぱ)
2007/02/20 02:13:25

>何が過剰なのかわからないのです。 [684]に書いたことを繰り返すつもりはありません。 >「クラス」も「スーパークラス」も、全く過剰だとは思えないので。 もはや日本語むちゃくちゃになっていませんか? 「スーパーサイヤ人に過剰な期待をするのはいかがなものか」 「悟空もベジータも、全く過剰とは思えない」 意味不明です。
[この投稿を含むスレッドを表示] [この投稿を削除]
[696] 昨晩は酔っ払ってました
投稿者:(ぱ)
2007/02/20 02:13:25

 えー、すみません、興味深い投稿がたくさんされてますが、昨晩は酔っ払って帰って きてそのまま寝てしまいました (^^;  お返事は今晩ということでよろしくお願いします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[695] イテレータ(とCPS)
投稿者:NykR
2007/02/20 02:13:25

http://kmaebashi.com/programmer/devlang/regexp.html > Java流の、要素を取り出すだけで強制的にポインタを進めてしまう仕様は、 > ちょっとどうかと思うんですがねえ。 同感です。マージとかやりにくそう。 というわけでどちらか片方にするなら、GoFの方が良いな、と思ってたりするのですが、以下のような関数を用意すれば、GoF方式とJava方式の両方をあまり手間をかけずに作ることができます。(両方欲しい、という訳ではありませんが) function iterator_GoF(foreach_CPS) { this = new_object(); this.first = closure () { this.isDone = closure () { return false; }; foreach_CPS(closure (item, cont) { this.currentItem = closure () { return item; }; this.next = closure () { cont(null); }; }, closure (ret) { this.isDone = closure () { return true; }; }); }; this.first(); return this; } function iterator_Java(foreach_CPS) { this = new_object(); closure () { this.hasNext = closure () { return true; }; foreach_CPS(closure (item, cont) { this.next = closure () { cont(null); return item; }; }, closure (ret) { this.hasNext = closure () { return false; }; }); }(); return this; } function foreach(foreach_CPS, proc) { # ついでに作った foreach_CPS(closure (item, cont) { cont(proc(item)); }, closure (ret) {}); } # foreach_CPSは CPS(continuation passing style, 継続渡し形式)で書かれたforeachです。 # つhttp://www.shiro.dreamhost.com/scheme/docs/cont-j.html これらの関数に対し、コレクション側でforeach_CPSを用意して渡せば それぞれの関数に対応したイテレータが返されます。 例えば以下のような2分木があったとすれば tr = {13,{5,{3,{},{}},{13,{12,{},{}},{}}},{16,{16,{15,{},{}},{}},{17,{},{}}}}; function foreachTree_CPS(tree) { return closure (proc, fin) { closure internalIterate(node, cont) { if (node.size() == 0) { cont(null); } else { internalIterate(node[1], closure (ret) { proc(node[0], closure (ret) { internalIterate(node[2], cont); }); }); } }(tree, fin); }; } という関数を1つ定義するだけで print("foreach:"); foreach(foreachTree_CPS(tr), closure (item) { print(" " + item); }); print("\n"); print("GoF :"); for (i = iterator_GoF(foreachTree_CPS(tr)); !i.isDone(); i.next()) { print(" " + i.currentItem()); } print("\n"); print("Java :"); for (i = iterator_Java(foreachTree_CPS(tr)); i.hasNext();) { print(" " + i.next()); } print("\n"); のように、3種類のイテレータが使えてまあ便利。 でもシーケンシャルなコレクションだとそれほど嬉しくはありません。 CPSではforやwhileがまともに使えないので、例えば配列用のforeach_CPSは function foreachArray_CPS(array) { return closure (proc, fin) { closure loop(index, cont) { if (index == array.size()) { cont(null); } else { proc(array[index], closure (ret) { loop(index + 1, cont); }); } }(0, fin); }; } なんてことになって、要素数が多いとforeachに渡したときにクラッシュするなあ、とか、初期値と変数が遠いなあ、とか。 今の実装だと末尾再帰の最適化は物凄く大変そうですしね。 # でもこの形式のループは個人的にはむしろ欲しかったりします、crowbar ver.0.3.02にcall/ccを付けたので。ちなみに、この時点で末尾再帰の最適化はやりやすくなったのですが、CRB_Objectが増えたので先にGCを改造しなければならないのでした(どうでもいい報告)。 この手法は、 ・外部イテレータを直接作るのが難しくて ・ループによらないアクセスが簡単な データ構造(木とか) *では* 役に立ちます。 # ライブラリが簡単に書けます。というのはそれほど嬉しいことではない気がする
[この投稿を含むスレッドを表示] [この投稿を削除]
[694] Re:正規表現関連の関数の質問
投稿者:タイガー
2007/02/20 02:13:25

>LuaやJavaScriptの方法だと、名前空間が動的になるんですよね。 >環境作ってないので試してませんけど、Luaで「hoge = string」と書くと、 >hoge.sub()で文字列置換ができるようになるんじゃないでしょうか。 試してみたらできました。 静的、動的な違いというのも理解しました。 ありがとうございます。 >また、単なるテーブル(crowbarならオブジェクト)を名前空間に使うと、 >ライブラリ関数が壊せてしまうというのも、問題だと思います。 >Luaでは、string.subに代入できるんですよね? こちらも試してみたらできました。 確かに問題になりそうですね。 >と言いつつ、実は今crowbarに予約語finalを持ち込んで定数を作れるように >したりしてるので、ライブラリ関数のメンバとか名前空間オブジェクトをfinalに >してしまえば、これでもいい気がしてきました。うーん。 crowbarでfinalで定数作れるようにしてたんですね。 よくimmutableなクラスを作るときにはfinalにしないといけないと 書いてあるので、そういう意味ではfinalは必須な気もします。 Luaには定数にする方法はなかったような…。 >これは、Cの関数を抜けた後の話ですよね。レジストリに登録するという。 >crowbarでは、Cの関数の実行中でも、ヒープ関連の関数を呼び出すと >GCが動く可能性がありますから、ひとまずスタックに積まなければなりません。 私はよく分かっていないのですが、このcrowbarのアプローチは メジャーなのですか? >Luaの仮想スタックって、まさにcrowbarのスタックのような独自スタックでは? >crowbarのような手間がなさそうなところからして、Cの関数の部分だけ、 >Cスタックをスキャンするconservative GCなのかなあ、とも思ったのですが、 >テーブルを確保すると勝手にスタックに積まれること、他の参照型というと >文字列くらいですがCRB_Stringのような型では扱っていないことからして、 >コンサバGCではないようですね。 Luaの仮想スタックは、確かに独自スタックです。 しかし、私の知識不足とLuaのGCのメカニズムは記述がなかったため よく分かりません。 >うーん、CRB_add_native_function()は別にinterface.cの中で呼ぶ必要はないんですが >(実際今はnative.cとかの中で呼んでますし)。実行中でも呼べますから、 >ネイティブ関数内でも登録可能です。 実行中に呼べるのは応用範囲が広がりそうですね。 >これに近いことをするのであれば、(ver.0.4で新設された)CRB_create_closure()で >クロージャ作って、CRB_add_assoc_member()でオブジェクトに登録するなり >CRB_add_global_variable()でグローバル変数に登録するなりもできます。 crowbarのように実際のデータを直接扱えるとコードが分かりやすいと 思います。 Luaみたいに仮想スタック上にデータを作っておいて…みたいのは 分かりにくいです。 >crowbarスクリプトをまったく独立して動かせばよいのなら、インタプリタを >もうひとつ作って実行すればよいです。 >ただ、たぶんこの場合、グローバル変数を共有して動かしたいのだと思います。 >そうだとすれば、外部crowbarスクリプトのトップレベルを動かす方法は >ありません。ただし、外部crowbarスクリプト中の関数であれば、 >CRB_compile()とCRB_call_function()を使えば実行可能です。 外部crowbarスクリプト中の関数を呼べるということは、 データを引数でC側からcrowbarの関数側にプッシュしてあげて、 crowbarスクリプトのglobal変数に保存しておけば、 データの共有はできると思います。 C側に戻したいときもC側から渡す引数につめてあげれば 戻せます。 私は、この(例えば)Cとスクリプトとのデータの共有が一番 重要と思っているのですが、crowbarでも簡単にできそうですね。 だとすれば、既に組み込み言語として十分使えるレベルだと思います。 実は、Luaではこの一番重要な部分が一番面倒くさいです。 >やりたいこと・やるべきことはいろいろあって、その中にはcrowbar以外のことも >含まれます。もう少ししたら、crowbarほっぽりだして別の言語を作り始める >可能性も(かなり高い確率で)あります。企画の趣旨的には、crowbarを実用言語に >するよりも、バイトコードインタプリタのような違う実行形態の言語をもうひとつ >作る、という方が合っている気がしますし。 バイトコードインタプリタはかなり興味深いです。 楽しみにしています。 >ということで、crowbarに期待してくださるのは大変嬉しいことですし、 >私としても励みになるのですが、私の時間が有限である以上お応えできるかどうかは >わからない、ということで、すみませんがご理解ください。 私は、(ぱ)さんの本はほとんど持っていますが、もう少し内容を濃くして 「プログラミング言語を作る」もぜひ出版して欲しいです。 早くていつ頃になりそうですか? >あと、今だと鬼車のライセンス表記をどこかに含めなければいけませんよね。 >次バージョンで検討します。 ソースの理解は、まず動作が分かってからだと思うので、 とりあえず簡単に動かしてみたいという気持ちはあります。 あと、Cとの連携方法など、ユーザの視点でのcrowbarの使い方 みたいな文章も欲しいところです。 時間がないでしょうが、いつも楽しみにしていますので 頑張ってください。
[この投稿を含むスレッドを表示] [この投稿を削除]
[693] 多態性(ポリモーフィズム)について
投稿者:happie
2007/02/20 02:13:25

はじめまして。happieと申します。 以前、拙HPで勝手に(ぱ)さんのページを紹介させていただきました。 また『ポインタの完全制覇』や「疑り深いあなたのためのオブジェクト指向再入門」については、本質的なところを突いているため大変興味深く読ませていただきました。 オブジェクト指向の本質が、マルチプルインスタンスにあるということについても全く同意見です。 ところで、一部のオブジェクト論者の中には、ポリモーフィズムこそがオブジェクト指向の本質で、インターフェースでプログラミングすることが最も重要なことのように謳っています。実際、デザインパターンの解説書ではそのことがたびたび強調されています。 (ぱ)さんは、ポリモーフィズムに関してあまり記述がなかったように思いますが、どのようにお考えですか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[692] Re:オブジェクト指向「初」入門
投稿者:CES
2007/02/20 02:13:25

>>もっと言ってしまえば、「クラス」ではなくて「りんご」でも別に良かった…ということ? > >私は「術語に*過剰な*期待をするのはいかがなものか」と言っているのです。 >「術後にまったく期待するな」などと言った覚えはありません。 何が過剰なのかわからないのです。 「クラス」も「スーパークラス」も、全く過剰だとは思えないので。
[この投稿を含むスレッドを表示] [この投稿を削除]
[691] Re:正規表現関連の関数の質問
投稿者:(ぱ)
2007/02/20 02:13:25

>しかし、私はLuaの方法と、モジュールによる名前空間の分割の >本質的な違いを説明することはできません。 LuaやJavaScriptの方法だと、名前空間が動的になるんですよね。 環境作ってないので試してませんけど、Luaで「hoge = string」と書くと、 hoge.sub()で文字列置換ができるようになるんじゃないでしょうか。 Javaなどでもimportでパッケージ指定を省略できたりしますが、その規則は あくまで静的です。これを動的に変えられると、どこで何呼んでるんだか さっぱり、という状態になりそうな気がします。もっとも、 「そんなことしないでしょ」という考え方もありますが。 # でも、s = stringとかしてタイプ量を節約する人はいる気がする。 また、そういう規則では、統合開発環境はお手上げでしょうが、それは 形無し言語全般に言えることかも。 RDEとやらの入力保管機能はどうなってるんだろ、とマニュアルを見てみたら… ううむ。 http://rubyde.sourceforge.net/hiki/ja/Auto%2BComplete.html また、単なるテーブル(crowbarならオブジェクト)を名前空間に使うと、 ライブラリ関数が壊せてしまうというのも、問題だと思います。 Luaでは、string.subに代入できるんですよね? と言いつつ、実は今crowbarに予約語finalを持ち込んで定数を作れるように したりしてるので、ライブラリ関数のメンバとか名前空間オブジェクトをfinalに してしまえば、これでもいい気がしてきました。うーん。 >配列とハッシュが同列なら、配列リテラルがあるので、 >ハッシュリテラルも欲しいところです。 >初期化ができないと不便なので私は必須だと思っています。 ご意見ありがとうございます。 …と言いつつ、やりたいことは他にもあるので、すみませんが優先順位は高くないです。 >(2)に関しては、Luaは、GCされたくなければ、グローバルとして >別に残しておかなければなりません。 これは、Cの関数を抜けた後の話ですよね。レジストリに登録するという。 crowbarでは、Cの関数の実行中でも、ヒープ関連の関数を呼び出すと GCが動く可能性がありますから、ひとまずスタックに積まなければなりません。 >また、LuaがコンサバGCかどうかは不明ですが、 >crowbarのようなcrowbarスタックはLuaには、ないと思います。 Luaの仮想スタックって、まさにcrowbarのスタックのような独自スタックでは? crowbarのような手間がなさそうなところからして、Cの関数の部分だけ、 Cスタックをスキャンするconservative GCなのかなあ、とも思ったのですが、 テーブルを確保すると勝手にスタックに積まれること、他の参照型というと 文字列くらいですがCRB_Stringのような型では扱っていないことからして、 コンサバGCではないようですね。 >現状のCRB_add_native_function()で、ネイティブ関数を登録 >しておかなければならないのは、interface.cのソースを直接 >いじらないといけないので、これはLuaの方が楽だと思います。 うーん、CRB_add_native_function()は別にinterface.cの中で呼ぶ必要はないんですが (実際今はnative.cとかの中で呼んでますし)。実行中でも呼べますから、 ネイティブ関数内でも登録可能です。 >Cで書いた関数(例えば、l_sin()という関数)を、 >lua_pushcfunction(L, l_sin) >lua_setglobal(L, "mysin") >で、登録することによりLuaでmysin()という関数が使えます。 これに近いことをするのであれば、(ver.0.4で新設された)CRB_create_closure()で クロージャ作って、CRB_add_assoc_member()でオブジェクトに登録するなり CRB_add_global_variable()でグローバル変数に登録するなりもできます。 >また、Luaでは、CからLuaのコードを呼ぶ際に、 >Lを、lua_State型の変数とすると、 >lua_dofile(L, "test.lua") >により、test.luaが実行されるのですが、 >crowbarでは、これはどうやればできますか? crowbarスクリプトをまったく独立して動かせばよいのなら、インタプリタを もうひとつ作って実行すればよいです。 ただ、たぶんこの場合、グローバル変数を共有して動かしたいのだと思います。 そうだとすれば、外部crowbarスクリプトのトップレベルを動かす方法は ありません。ただし、外部crowbarスクリプト中の関数であれば、 CRB_compile()とCRB_call_function()を使えば実行可能です。 >ただのプログラミング練習言語で終わらせるのはもったいないと >思います。 >何か特徴を付けて、存在価値のある言語にして欲しいです。 やりたいこと・やるべきことはいろいろあって、その中にはcrowbar以外のことも 含まれます。もう少ししたら、crowbarほっぽりだして別の言語を作り始める 可能性も(かなり高い確率で)あります。企画の趣旨的には、crowbarを実用言語に するよりも、バイトコードインタプリタのような違う実行形態の言語をもうひとつ 作る、という方が合っている気がしますし。 ということで、crowbarに期待してくださるのは大変嬉しいことですし、 私としても励みになるのですが、私の時間が有限である以上お応えできるかどうかは わからない、ということで、すみませんがご理解ください。 >あと、できれば、Windows版のcrowbar.exeもダウンロード >できるようにして欲しいです。 確かに便利だと思いますし、今まで考えなかったわけでもないのですが、 企画の趣旨的にどうかという気もします。 あと、今だと鬼車のライセンス表記をどこかに含めなければいけませんよね。 次バージョンで検討します。
[この投稿を含むスレッドを表示] [この投稿を削除]
[690] Re:オブジェクト指向「初」入門
投稿者:(ぱ)
2007/02/20 02:13:25

>もっと言ってしまえば、「クラス」ではなくて「りんご」でも別に良かった…ということ? 私は「術語に*過剰な*期待をするのはいかがなものか」と言っているのです。 「術後にまったく期待するな」などと言った覚えはありません。 >例示が必要でしょうか? 「is-a」「汎化-特化」の考えは、まさに分類だと思うのですが(「汎化」「特化」という用語を誰が考えたかは知りませんが、いくらこれが術語だからと言って「低機能」「高機能」という意味でないのは明らかでしょう)。 そんな話をした覚えもありません。
[この投稿を含むスレッドを表示] [この投稿を削除]
[689] Re:正規表現関連の関数の質問
投稿者:タイガー
2007/02/20 02:13:25

>ここを見る限り、stringというテーブルに、いろんなメソッドを >クロージャとして埋め込んでいる、という認識でよいでしょうか? その通りです。 私の表現は間違ってました。 stringテーブルにクロージャが入っているですね。 >ここでのstringの使われ方は、純粋に名前空間としてのものですよね。 >現状のcrowbarには、名前空間を分割する機能がないので、今回はreg_で >逃げたわけです。モジュールによる名前空間の分割はいずれそのうちやろうと >思っていますから、現時点で、Lua的な方法(crowbarでやるなら、グローバルな >stringというオブジェクトにクロージャを格納することになるのでしょう)で >解決しようとは思いません。 おっしゃる通り、名前空間と同じ仕組みです。 事実、Luaにはパッケージという概念がなく、テーブルにより パッケージを表現します。 しかし、私はLuaの方法と、モジュールによる名前空間の分割の 本質的な違いを説明することはできません。 しいて言えば、モジュールが一般的な意味のモジュールであれば、 文法を用意してあげることにより、ソースを見たときの 分かりやすさ(明確さ)は増すような気はします。 Javaみたいな感じだとpackageが名前空間を表していることが明確です。 Rubyのモジュールだと結局Luaと同じになるような気がします。 >crowbarの場合、スコープチェーンは「最上位の関数の中」までで止まっていますが、 >これをグローバルな領域まで広げ、グローバルな名前空間もassocで表現するようにして、 >グローバル変数もそのassocに、またグローバルな関数はクロージャとして >格納するようにすれば、名前空間の考え方が統一されるとともに、 >モジュールが欲しければトップレベルのオブジェクトをモジュールとして考えればよい、 >ということになります。実際JavaScriptはそんな感じになっています。 これもおっしゃる通りです。 Luaでは、グローバルなテーブルというものが、あらかじめ存在し、 stringなどは、その中に登録されています。 >ハッシュはですねえ… >もちろん考えていないことはないのですが、問題は、どの階層で実現するかです。 >言語の外で、ライブラリとして提供しても十分だと思うんですが、 >どうでしょうか(基本型のハッシュキーの取得方法は考えるにしても)。 >ハッシュのリテラル(「{"a" => "hoge"}」みたいなの)って要りますかねえ。 >考えるべきところはたぶんふたつあって、 私のイメージでは、配列(リスト)とハッシュは、同じ階層だと 思っています。 私の中で、リスト、ハッシュ、文字列は基本的なデータ構造だと 思います。 また、Luaでは、Table型により、配列とハッシュの両方を表現可能です。 >a)ハッシュのリテラルを言語仕様として用意するかどうか。 >b)ハッシュのオブジェクトを、(JavaScriptやLuaのように)現状のassocの > 別の見え方として考えるかどうか。 > >私としては、a)はまあやるならやってもいいけど(ただし優先順位は低い)、 >b)は嫌、というところです。 a)に関しては、 配列とハッシュが同列なら、配列リテラルがあるので、 ハッシュリテラルも欲しいところです。 初期化ができないと不便なので私は必須だと思っています。 b)に関しては、 assocの別の見え方にするというより、ハッシュを作り、 それでassocを表現するというイメージだと思いますが、 個人的には分けても統一化してもどちらでも良いと思います。 >ええと、私はLuaを使っていないのでご意見をお聞かせ願いたいわけですが、 >現状で、Luaとcrowbarを比べてみてどうでしょうか? >Luaとcrowbarでネイティブ関数を書くときのことを比較すると、 > >(1)引数や戻り値 > Lua…スタックを直接操作 > crowbar…引数や戻り値なので、ちょとはわかりやすいかな。 >(2)GC > Lua…何もしなくていい(?) Ruby的コンサバGC? >  lua_newtable()が「新しい空のテーブルを作り、スタックに積む。」そうだから、 >  スタックにないものは勝手にGCされそうな気もするんですが。 > crowbar…GCされたくなかったらスタックに積んどけ。 >  正直、これは面倒くさいです。せめて、最後のスタックの後始末を処理系側で >  やれば、というか実はそれは造作もないのですが。 >(3)アプリケーション固有データ > Lua…ユーザデータ > crowbar…ネイティブポインタ >  ファイナライザの仕様も含め、そっくりに見えます。また車輪を再設計したか。 (1)に関しては、crowbarの方は、CRB_Valueの構造が一度 分かってしまえば分かりやすいと思います。 Luaでは、常に目に見えない仮想スタックの状態がどうなっているかを 把握しておかないといけないのでかなり分かりづらいです。 (2)に関しては、Luaは、GCされたくなければ、グローバルとして 別に残しておかなければなりません。 また、LuaがコンサバGCかどうかは不明ですが、 crowbarのようなcrowbarスタックはLuaには、ないと思います。 (3)に関しては、Luaの方は、仮想スタック経由で扱うので 関数により抽象化されていて、 crowbarの方は、CRB_Valueで直接アクセスするので、 私個人の考えでは、crowbarの方が、何をやっているのかが 分かりやすいような気もします。 とにかくLuaでは常に仮想スタック経由なので、 そこら辺の仕組みが分かってしまえば良いのですが、 それがメリットなのかはまだ分かっていません。 >いっそ今みたいに特定の引数を持ったネイティブ関数が呼ばれる仕様ではなく、 >また、CRB_add_native_function()で関数を登録する必要もない、というようにして、 >もっと楽にネイティブ関数を書けるようにするというのも考えられますが… >処理系依存のコードはあんまり書きたくないですし。 現状のCRB_add_native_function()で、ネイティブ関数を登録 しておかなければならないのは、interface.cのソースを直接 いじらないといけないので、これはLuaの方が楽だと思います。 Luaでは、ライブラリとして登録するのは同様に面倒ですが、 ただLua側からC側の関数を呼びたいだけなら、 Cで書いた関数(例えば、l_sin()という関数)を、 lua_pushcfunction(L, l_sin) lua_setglobal(L, "mysin") で、登録することによりLuaでmysin()という関数が使えます。 このぐらいの手軽さがないと組み込みとは言えないと思います。 また、Luaでは、CからLuaのコードを呼ぶ際に、 Lを、lua_State型の変数とすると、 lua_dofile(L, "test.lua") により、test.luaが実行されるのですが、 crowbarでは、これはどうやればできますか? >まあ、別にRubyと張り合う気はないんですけど。 >方向性として、組み込み用スクリプトというのは、[685]にも書いたように >そもそも言語処理系に興味を持った時点からありました。 >ただ、今は別の方向も考えています。こんなの↓とか。 > >http://kmaebashi.com/zakki/zakki0027.html#lang ただのプログラミング練習言語で終わらせるのはもったいないと 思います。 何か特徴を付けて、存在価値のある言語にして欲しいです。 あと、できれば、Windows版のcrowbar.exeもダウンロード できるようにして欲しいです。 新しいバージョンをすぐテストしたいので。 よろしくお願いします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[688] Re:オブジェクト指向「初」入門
投稿者:CES
2007/02/20 02:13:25

>「術語に対して」過剰な期待をしてもしょうがないのでは、ということです。 >この議論の最初のほうで、CESさんは > >>例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 > >ということを書いています。 >でも、「クラス」という言葉の辞書的定義が「分類」だったからといって、 >術語として使われるときそのままの意味とは限らないし、「クラス」という >言葉を選んだ人が間違えたのかもしれない。だから、その言葉の意味に >過剰な期待をしてもしょうがないのでは、と言っているのです。 ># クラスを分類とする考え方を否定しているわけではありません。 では、極論すれば、辞書的な「分類」という意味と、術語としての「クラス」という用語は切り離して考えるべきだ、ということ? もっと言ってしまえば、「クラス」ではなくて「りんご」でも別に良かった…ということ? 「りんご」の辞書的な意味は明らかに違うけれど、術語なんだから、それで通じれば別にいいじゃん…と。 しかし、如何に述語だとは言っても、何の根拠もなく選ばれた言葉であるはずはなし、そして、「クラス」には「分類」という意味があって、オブジェクト指向のクラスを「分類」として捉えると自然なのは事実なんだから、その言葉はそのような意味を持って選ばれたと考えるのは、過剰ではないと思うのですけれど。 本当に「何の根拠もなく選ばれたはずはない」のかどうか、あるいは根拠があったにしても「『分類』という意味を意図して選んだ」のかどうか、その真相はわからないのですが、別に後付けの意味だとしても、それはそれで構わないと思います。意味がないよりはずっといい。 >「それはそうかもしれませんけど」「それほど無理はない」んならいいじゃん、 >術語に過剰な期待をしてもしょうがない、と私は言っているわけです。 「りんご」だったら「それほど無理は無くない」と思うけれど、まぁ極論だからそこに突っ込むのは無し。 >クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に >有効であるケースを、例示して主張するのがよいのではないでしょうか。 例示が必要でしょうか? 「is-a」「汎化-特化」の考えは、まさに分類だと思うのですが(「汎化」「特化」という用語を誰が考えたかは知りませんが、いくらこれが術語だからと言って「低機能」「高機能」という意味でないのは明らかでしょう)。
[この投稿を含むスレッドを表示] [この投稿を削除]
[687] Re:正規表現関連の関数の質問
投稿者:(ぱ)
2007/02/20 02:13:25

補遺。 >現状のcrowbarには、名前空間を分割する機能がないので、今回はreg_で >逃げたわけです。モジュールによる名前空間の分割はいずれそのうちやろうと >思っていますから、現時点で、Lua的な方法(crowbarでやるなら、グローバルな >stringというオブジェクトにクロージャを格納することになるのでしょう)で >解決しようとは思いません。 crowbarの場合、スコープチェーンは「最上位の関数の中」までで止まっていますが、 これをグローバルな領域まで広げ、グローバルな名前空間もassocで表現するようにして、 グローバル変数もそのassocに、またグローバルな関数はクロージャとして 格納するようにすれば、名前空間の考え方が統一されるとともに、 モジュールが欲しければトップレベルのオブジェクトをモジュールとして考えればよい、 ということになります。実際JavaScriptはそんな感じになっています。 crowbarがそうなっていないのは、ver.0.1からの流れ、というのも否定できないですが、 printに代入できるのはいかがなものか、とか、名前空間はやっぱり静的なほうが わかりやすいんじゃないか、とか、グローバル変数とローカル変数は分けて考える べきじゃないか、とか、いろいろ考えてこうなっています。この選択が正しかったか どうかはよくわかりませんが。 このへんはいずれ「crowbarプログラマのためのJavaScript入門」(仮題)で 書こうかと思っています。 # タイトルはネタなのであまり怒らないように。
[この投稿を含むスレッドを表示] [この投稿を削除]
[686] Re:正規表現関連の関数の質問
投稿者:(ぱ)
2007/02/20 02:13:25

>最後の方に、正規表現関連の関数がグローバルということが >書かれていましたが、私は、Pythonは、よく知らないのですが、 >何で正規表現の関数をクロージャに押し込んで提供していないのですか? >例えば、Luaであれば、Stringというクロージャに入っています。 Luaは以前リファレンスをちょっと眺めたきりなので、 ここで言う「クロージャ」が何であるのかがよくわからないのですが。 http://lua-users.org/wiki/StringLibraryTutorial ここを見る限り、stringというテーブルに、いろんなメソッドを クロージャとして埋め込んでいる、という認識でよいでしょうか? http://www.uri.sakura.ne.jp/~cosmic/yuno/lab/lua5_manual_ja.html#5.3 ここを見ても、 | 文字列ライブラリはすべて、テーブル string 内の関数として提供される。 と書いてあるし。 ここでのstringの使われ方は、純粋に名前空間としてのものですよね。 現状のcrowbarには、名前空間を分割する機能がないので、今回はreg_で 逃げたわけです。モジュールによる名前空間の分割はいずれそのうちやろうと 思っていますから、現時点で、Lua的な方法(crowbarでやるなら、グローバルな stringというオブジェクトにクロージャを格納することになるのでしょう)で 解決しようとは思いません。 >また、crowbarには、まだハッシュを組み込んでなかったと思うのですが、 >ハッシュは組み込まないのですか? >必須なデータ構造だと思います。 ハッシュはですねえ… もちろん考えていないことはないのですが、問題は、どの階層で実現するかです。 言語の外で、ライブラリとして提供しても十分だと思うんですが、 どうでしょうか(基本型のハッシュキーの取得方法は考えるにしても)。 ハッシュのリテラル(「{"a" => "hoge"}」みたいなの)って要りますかねえ。 考えるべきところはたぶんふたつあって、 a)ハッシュのリテラルを言語仕様として用意するかどうか。 b)ハッシュのオブジェクトを、(JavaScriptやLuaのように)現状のassocの  別の見え方として考えるかどうか。 私としては、a)はまあやるならやってもいいけど(ただし優先順位は低い)、 b)は嫌、というところです。 >あと、最近、Luaを勉強していて、組み込み言語と謳っている割りに >例えば、LuaとCとのインタフェースを書くのがかなり面倒で >少しがっかりしているのですが、crowbarはぜひとも組み込み部分を強化 >して欲しいです ええと、私はLuaを使っていないのでご意見をお聞かせ願いたいわけですが、 現状で、Luaとcrowbarを比べてみてどうでしょうか? Luaとcrowbarでネイティブ関数を書くときのことを比較すると、 (1)引数や戻り値  Lua…スタックを直接操作  crowbar…引数や戻り値なので、ちょとはわかりやすいかな。 (2)GC  Lua…何もしなくていい(?) Ruby的コンサバGC?   lua_newtable()が「新しい空のテーブルを作り、スタックに積む。」そうだから、   スタックにないものは勝手にGCされそうな気もするんですが。  crowbar…GCされたくなかったらスタックに積んどけ。   正直、これは面倒くさいです。せめて、最後のスタックの後始末を処理系側で   やれば、というか実はそれは造作もないのですが。 (3)アプリケーション固有データ  Lua…ユーザデータ  crowbar…ネイティブポインタ   ファイナライザの仕様も含め、そっくりに見えます。また車輪を再設計したか。 いっそ今みたいに特定の引数を持ったネイティブ関数が呼ばれる仕様ではなく、 また、CRB_add_native_function()で関数を登録する必要もない、というようにして、 もっと楽にネイティブ関数を書けるようにするというのも考えられますが… 処理系依存のコードはあんまり書きたくないですし。 >鬼車を搭載しても、まともに張り合ったら、Rubyに対抗するのは >難しいと思いますので、組み込み用スクリプトでメジャーなものは >なさそうなので、そういう方向はどうでしょうか? まあ、別にRubyと張り合う気はないんですけど。 方向性として、組み込み用スクリプトというのは、[685]にも書いたように そもそも言語処理系に興味を持った時点からありました。 ただ、今は別の方向も考えています。こんなの↓とか。 http://kmaebashi.com/zakki/zakki0027.html#lang ていうか、企画本来の主旨であったはずの「プログラミング言語の作り方の紹介」 という観点からすれば、crowbarは、crowbarのような実装方針の言語としては とっくにオーバースペックであり、たぶん私は暴走している状態なわけですが。 ええと誰か止めて。
[この投稿を含むスレッドを表示] [この投稿を削除]
[685] Re:すごいですね。
投稿者:(ぱ)
2007/02/20 02:13:25

>私は、LINUXで動くCADを作りたいと思っています。 リンク欄のsourceforgeのページから、ホームページを辿って見てみました。 http://sagcad.sourceforge.jp/ 浅学にてSagCADは知らなかったのですが、crowbarよりずっとすごいじゃないですか。 BBS(は見えなかったのですがそのGoogleキャッシュ)を見てみると、ドイツの人とか 英語圏の人とかも巻き込んで開発されているようですし。 実は私は10年くらい前、資料などに使う図を描くドローツールについて、 いいのがないので作りたいと思っていました。当時は、ていうか実は今も UNIX上でTgifを使っていますが使い勝手の点で満足していません。 たとえばシステム構成図などでは、データベースとかを円筒形を斜め上から 見た図で表現することがあります。Word付属のドローツールとかでも この円筒形は描けますが、縦に伸ばすと楕円部分の縦横比まで変わってしまう。 これは美しくないわけで、「中に入る文字列に合わせてサイズは自動調整。 でも楕円部分の縦横比は変わらない」という機能が欲しいわけですが、これを ドローツール本体に組み込むのも美しくない。となるとスクリプト言語が必要かなあ… と言語処理系に興味を持ち始めて今に至るわけです。 以後、いくつも言語を作ろうとして作りかけで放棄してきたわけですが (言語処理系を作りかけた人は誰もがこれをやってると思う)、crowbarは仕様で 無理をしなかったことと、何よりも「公開したこと」により、どうにかここまで こぎつけることができました。 というわけで、CADのマクロとして使うというのは、crowbarの実に正当な使い方と いうか、本来あるべき姿のように思います。バグがあったらすみませんですが、 よろしくお願いいたします。 >ホームページ上では、僕が作ったソースに組み込めるようなことが >描いてありました。まだ試していませんが、試せるところまで進んだら >ぜひ、使わせてください。 CADに組み込む際には、スクリプトから図形を作ったり、図形をスクリプトから 操作したりしなければならないでしょうから、「図形」とか「図面」とかを ネイティブポインタ型で表現することになると思います。 その上でネイティブメソッドをいくつか書けば、CADと連携できるのでは、 と思います。 # 「図形」や「図面」にメソッドを付けるには、今の仕様ではcrowbarの # オブジェクトでラップすることになりますが、ネイティブポインタ型に # 「メソッドもどき」を付ける機能があってもいいかな、とも思っています。 それでは、SagCADにcrowbarが組み込まれる日を楽しみにしています。
[この投稿を含むスレッドを表示] [この投稿を削除]
[684] Re:オブジェクト指向「初」入門
投稿者:(ぱ)
2007/02/20 02:13:25

>よくわかんなくなってきました。「過剰な期待をするな」とはどういうことですか? >「違和感を覚えるな」というのは無理な期待だ、ということでしょうか? 「術語に対して」過剰な期待をしてもしょうがないのでは、ということです。 この議論の最初のほうで、CESさんは >例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 ということを書いています。 でも、「クラス」という言葉の辞書的定義が「分類」だったからといって、 術語として使われるときそのままの意味とは限らないし、「クラス」という 言葉を選んだ人が間違えたのかもしれない。だから、その言葉の意味に 過剰な期待をしてもしょうがないのでは、と言っているのです。 # クラスを分類とする考え方を否定しているわけではありません。 CESさんはこうも書いています。 >「クラスとは分類である」という考えをすると、具体的なものはオブジェクトで、 >クラスは全て抽象的なものということになるからです(その点、「抽象クラス」 >ってのは良くないネーミングだと思います)。 私の返答がこう(「スーパークラス」の話は発散するので省略)。 >それはそうかもしれませんけど、具体的なオブジェクトにできないものが >抽象クラスで、具体的なオブジェクトを作れるものがconcrete classってのは、 >それほど無理はないんじゃないでしょうか。 「それはそうかもしれませんけど」「それほど無理はない」んならいいじゃん、 術語に過剰な期待をしてもしょうがない、と私は言っているわけです。 クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に 有効であるケースを、例示して主張するのがよいのではないでしょうか。 「そのへんの入門書にある考え方だと、こういう例ではこういうモデリングを してしまいがちだけど、分類として考えればこんなモデリングになって、 こういう拡張をするときのことを考えたらこっちのほうが修正箇所が はるかに少なくてすむよね」とか。 結城浩さんが書いておられるように、「例は嘘をつかない」ですから。 http://www.hyuki.com/dig/eg.html
[この投稿を含むスレッドを表示] [この投稿を削除]
[683] 正規表現関連の関数の質問
投稿者:タイガー
2007/02/20 02:13:25

いつも「プログラミング言語を作る」を楽しく拝見させて頂いています。 早速、「正規表現ライブラリ鬼車の搭載」を拝見させて頂きました。 最後の方に、正規表現関連の関数がグローバルということが 書かれていましたが、私は、Pythonは、よく知らないのですが、 何で正規表現の関数をクロージャに押し込んで提供していないのですか? 例えば、Luaであれば、Stringというクロージャに入っています。 また、crowbarには、まだハッシュを組み込んでなかったと思うのですが、 ハッシュは組み込まないのですか? 必須なデータ構造だと思います。 あと、最近、Luaを勉強していて、組み込み言語と謳っている割りに 例えば、LuaとCとのインタフェースを書くのがかなり面倒で 少しがっかりしているのですが、crowbarはぜひとも組み込み部分を強化 して欲しいです (例えば、C側で、LuaのTableをダイレクトに作れず、Luaのスタックを 経由しないとできないので面倒)。 鬼車を搭載しても、まともに張り合ったら、Rubyに対抗するのは 難しいと思いますので、組み込み用スクリプトでメジャーなものは なさそうなので、そういう方向はどうでしょうか? 私は、D言語やioはあまり知らないですが、組み込み用言語の デファクトスタンダードとか、存在するのでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[682] すごいですね。
投稿者:kappa
2007/02/20 02:13:25

私は、LINUXで動くCADを作りたいと思っています。 その中で、マクロのようなものを組み込みたいと思って、 自分で少し考えていたんですが、これは、これで、また新たな 専門的な知識が必要だと感じましたし、CAD自体まだまだな 自分には、いつになることかとたまに、どこかにないかなと探 し続けていました。 今回ここにたどり着いて、サンプルを動かしてみました。 すごいですね。 ホームページ上では、僕が作ったソースに組み込めるようなことが 描いてありました。まだ試していませんが、試せるところまで進んだら ぜひ、使わせてください。 僕は、プロでもないし、未熟者ですが、そのときは、いろいろ質問 させてください。 最近、あれもやりたい、これもやりたいと悩んで、CAD自体手を付けられない 状態でした。 このサイトに来て、このようなすばらしいものがあるのなら、 今は、マクロについては何も考えず、目標のCADに専念しようと やる気が起きてきました。ありがとうございます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[681] Re:オブジェクト指向「初」入門
投稿者:CES
2007/02/20 02:13:25

>何度も繰り返しますが、私が言っているのは、 >「術語に過剰な期待をするのはいかがなものか」 >ということだけです。 >スーパークラスという言葉を否定した覚えも、スーパークラスは集合論で言えば >スーパーセットである、というのを否定した覚えもありません。 よくわかんなくなってきました。「過剰な期待をするな」とはどういうことですか? 「違和感を覚えるな」というのは無理な期待だ、ということでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[680] OTDの掲示板を閉鎖しました
投稿者:(ぱ)
2007/02/20 02:13:25

旧掲示板として存続してきたOTD版の掲示板ですが、最近は広告書き込みばかりで、 その量も尋常ではないので、閉鎖しました。トップページにも案内を出しましたが、 過去ログは以下のURLから参照できます。 http://kmaebashi.com/bbs/otdindex.html どうでもいいことですが、過去ログは、30件ずつブラウザで表示し、 HTML保存(ここは手作業)したものに対し、crowbarで変換をかけることで 生成しました。crowbarで行ったのは、広告やJavaScriptの削除、前後の ページへのリンクの付加です。 バリバリにうちの掲示板のHTMLに依存したスクリプトなので、そのまま 他の人の役に立つ可能性はゼロですが、数少ないcrowbarのサンプルソースとして 以下に公開しておきます。 http://kmaebashi.com/bbs/conv_crb.html
[この投稿を含むスレッドを表示] [この投稿を削除]
[679] Re:オブジェクト指向「初」入門
投稿者:(ぱ)
2007/02/20 02:13:25

>ただ、違和感を感じるからといって否定するのでは、何かを学習することはできないでしょう。学習は違和感を覚え、それを解消することによって積み重ねていくものです。 だーかーらー。 いつ誰が、スーパークラス、サブクラスという言葉を否定しましたか? 何度も繰り返しますが、私が言っているのは、 「術語に過剰な期待をするのはいかがなものか」 ということだけです。 スーパークラスという言葉を否定した覚えも、スーパークラスは集合論で言えば スーパーセットである、というのを否定した覚えもありません。
[この投稿を含むスレッドを表示] [この投稿を削除]
[678] Re:オブジェクト指向「初」入門
投稿者:CES
2007/02/20 02:13:25

> 私が最初から言っているのは、「術語に過剰な期待をするのはいかがなものか」ということです。 > 集合論で見て、サイヤ人はスーパーサイヤ人のスーパーセットですが、やっぱりスーパーサイヤ人の方に「スーパー」が付いている。そういう言葉の使い方が現実にある以上、「スーパークラス」という言葉に違和感を感じる人もそりゃいるだろうねえ、と言っているだけです。 そうかなぁ、とも思ったのですが、一人で3連投するのもどうかと思ったのでやめときました。 「スーパークラス」という用語に違和感を感じるのは構いませんが、しかし「基底クラス」という言い方はもっとまずいと思うのです。前述したように、クラスは上下関係ではなく包含関係にあるからです。 「スーパーサイヤ人の方がスーパーだ」という考えに固執していると、「サブクラス(に属するオブジェクト)は機能が多いものだ」という誤解を招きます。 「スーパークラス」「サブクラス」という用語を使わなくても、自然に集合論的考え方ができるのであれば、それで結構だと思います。 ただ、違和感を感じるからといって否定するのでは、何かを学習することはできないでしょう。学習は違和感を覚え、それを解消することによって積み重ねていくものです。 前にも言いましたが、「スーパークラスはサブクラスよりも『含むものが多い』という点で集合の能力が上、すなわちスーパーだ」という考え方もできます。そして、「スーパーサイヤ人は機能が多い方がスーパーなのに、集合論は機能が少ないほうがスーパーなんだ。そういうものなんだ」と違和感を感じたまま暗記するよりは、是非、違和感を解消していただきたいと思うのです。 というわけで、俺は「スーパークラス」「サブクラス」という呼び方を布教していきたいと思います。 > で、集合論で考えるなら円は楕円のサブセットなのであって、それを「客観的な視点などというものは存在しません」などと言って否定してしまったら、それこそ数学を全部敵に回すと思うんですが、如何? 「円は楕円のサブセットである」というのは、集合論が決めることではありません。数学(幾何学)が決めることです。 (どんな論理に基づくかは知りませんが)「楕円は円のサブセットである」と言っても、それは幾何学的には間違えているかもしれませんが、集合論的には間違えていません。集合論は集合の関係を提供するのみで、その中身の妥当性にまでは関与しないからです。 そして、数学さえ真理ではありません。かつてはユークリッド幾何学が真理とされていた時代もありましたが、今では「ユークリッド幾何学は、いくつかの都合のいい前提の基にのみ成立する、一面の真実でしかない」ということは広く知られています。
[この投稿を含むスレッドを表示] [この投稿を削除]
[676] Re:リンク切れ報告
投稿者:(ぱ)
2007/02/20 02:13:25

>こんばんは。archerと申します。 >「プログラミング言語を作る」のページの下のほうにある、 >「現状の最新版のダウンロードはこちらから。」のリンクが切れている(Not Found)ようです。 ご報告いただきありがとうございます。修正しました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[675] リンク切れ報告
投稿者:archer
2007/02/20 02:13:25

こんばんは。archerと申します。 「プログラミング言語を作る」のページの下のほうにある、 「現状の最新版のダウンロードはこちらから。」のリンクが切れている(Not Found)ようです。 とりあえず、報告まで。
[この投稿を含むスレッドを表示] [この投稿を削除]
[674] Re:オブジェクト指向「初」入門
投稿者:(ぱ)
2007/02/20 02:13:25

>まさにその程度のプログラムにおいて、そしてそこから大きくしていく過程において、のこと >を自分は想定していました。 >for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく場合において、 >オブジェクト指向をうまく取り入れられないかな、と考えたわけです。 思うのですが、オブジェクト指向は目的ではなく手段なのだから、 for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく 場合において、「このままでは破綻する」という状況がオブジェクト指向でうまく 回避できる、というのが想像できればよいのではないでしょうか。 ま、とはいえ世の中には「5000行の関数」を書いてしまうツワモノもいるわけで、 力技でもできる奴(どういう意味で「できる」かはアレですが)はやってしまうという のもあります。実際、5000行はともかく数百行程度なら、どんな書き方をしていても なんとかなってしまう、という面はあります。では一万行に挑んで痛い目に遭ってみれば オブジェクト指向のありがたみがわかるのかというと…そうなのかもしれませんが、 それでは痛い目に遭うためのコストが大きすぎますよね。 そのあたりは、「この方法では、もっと規模が大きくなったときどうなるだろう?」と 想像力で補うのがよいのではないかと思います。 >しかし、これだとサブルーチンという考え方だけで大丈夫だという記述もあり、 サブルーチンで大丈夫な範囲ならサブルーチンで大丈夫。 オブジェクト指向の方がよいのなら、サブルーチンに比べて「どこがどうよいのか」が 説明できなければならない、というのが私の言いたかったところです。 >いろいろなオブジェクト指向入門で見た「コードの再利用」というのも、なんだか疑わしい >と思っています。継承することによって再利用というのがしっくりこなかったです。 これはたぶんRqさんの感覚のほうが正しいのではないかと。
[この投稿を含むスレッドを表示] [この投稿を削除]
[673] Re:オブジェクト指向「初」入門
投稿者:(ぱ)
2007/02/20 02:13:25

>この違和感が「集合論で考えればわかりやすいね」で解決しなくて「いや、どうしても直感的に受け入れられない」ってことだとすると、オブジェクト指向を集合論で考えちゃいけねぇってことになる。それはいくらなんでも横暴じゃないかなぁ…数学を全部敵に回しそうだ。  私が最初から言っているのは、「術語に過剰な期待をするのはいかがなものか」ということです。  集合論で見て、サイヤ人はスーパーサイヤ人のスーパーセットですが、やっぱりスーパーサイヤ人の方に「スーパー」が付いている。そういう言葉の使い方が現実にある以上、「スーパークラス」という言葉に違和感を感じる人もそりゃいるだろうねえ、と言っているだけです。  いつ私が「オブジェクト指向を集合論で考えちゃいけねぇ」と言いましたか? 言っていると思うのなら、その部分を具体的に引用して示してください。  んで、集合論で考えるなら円は楕円のサブセットなのであって、それを「客観的な視点などというものは存在しません」などと言って否定してしまったら、それこそ数学を全部敵に回すと思うんですが、如何?
[この投稿を含むスレッドを表示] [この投稿を削除]