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

ハンドル名
件名
Link

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

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

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