K.Maebashi's BBS

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

>最後の方に、正規表現関連の関数がグローバルということが >書かれていましたが、私は、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のような実装方針の言語としては とっくにオーバースペックであり、たぶん私は暴走している状態なわけですが。 ええと誰か止めて。

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

>ここを見る限り、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もダウンロード できるようにして欲しいです。 新しいバージョンをすぐテストしたいので。 よろしくお願いします。

>しかし、私は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もダウンロード >できるようにして欲しいです。 確かに便利だと思いますし、今まで考えなかったわけでもないのですが、 企画の趣旨的にどうかという気もします。 あと、今だと鬼車のライセンス表記をどこかに含めなければいけませんよね。 次バージョンで検討します。

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

>>これは、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()を使う方法なら、インタプリタを共有できますから、 グローバル変数によるデータ共有が可能です(まあ、引数で受け渡しするほうが よいのはよいでしょうけど)。 >私は、(ぱ)さんの本はほとんど持っていますが、もう少し内容を濃くして >「プログラミング言語を作る」もぜひ出版して欲しいです。 >早くていつ頃になりそうですか？ いやあ、それはさっぱりわかりません。 まだ企画が動き出したわけですらないですし。

>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

>ご教授ありがとうございます。 >GCに少し興味を持ったのですが、お勧めのサイトなどありますか？ 私のお勧めサイトというと、ここの参考URLですかねえ。 http://kmaebashi.com/programmer/devlang/array.html あと、紙ものの資料では、大昔の情報処理学会誌に「ごみ集めの基礎と最近の動向」 というのがあって、とてもよかったのですが、現在では入手不能だと思います。 私はというと会社で該当の情報処理学会誌が捨てられる直前に気が付いて、 コピーしておいたのですが、その後数回の引越しで現在行方不明です…だめだめ。 >以下の本を購入しようと思ったのですが、(ぱ)さんは読んだことありますか？ > >http://www.amazon.co.jp/exec/obidos/ASIN/0471941484/qid=1136566955/sr=1-1/ref=sr_1_10_1/250-0589622-2949018 すみません、読んでないです。

>私のお勧めサイトというと、ここの参考URLですかねえ。 >http://kmaebashi.com/programmer/devlang/array.html ありがとうございます。 １回は既に読んでいたのですが、頭に入っていなかったので 何回も読み直してみます。 >あと、紙ものの資料では、大昔の情報処理学会誌に「ごみ集めの基礎と最近の動向」 >というのがあって、とてもよかったのですが、現在では入手不能だと思います。 >私はというと会社で該当の情報処理学会誌が捨てられる直前に気が付いて、 >コピーしておいたのですが、その後数回の引越しで現在行方不明です…だめだめ。 もったいないですね。でも今回の記事に生かせているのでは ないでしょうか。 >>以下の本を購入しようと思ったのですが、(ぱ)さんは読んだことありますか？ >> >>http://www.amazon.co.jp/exec/obidos/ASIN/0471941484/qid=1136566955/sr=1-1/ref=sr_1_10_1/250-0589622-2949018 > >すみません、読んでないです。 有名らしいのですが、読んでなかったのですね。 GCに関してあまり勉強せずにできているなんてすごいですね。 また、投稿します。ありがとうございました。