K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>>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の使い方
>みたいな文章も欲しいところです。
>時間がないでしょうが、いつも楽しみにしていますので
>頑張ってください。
>

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！