#Nu というS式で書くRuby みたいな言語があるんですね http://programming.nu/ MacのGUIアプリが簡単に書けるのかな・・・・ #聞いたことあるな
#import の件、入れ子はそもそもあまり使わないですね。prefix, except, only, rename を1階層だけで使うだけだ。
#仕様を決めたときに、いくつか仮想的にライブラリを書いてみれば良かったのかもしれませんね。実際に書いてみれば不要な仕様は明らかになりそう。
#MLでは指摘したような気がするけどformal commentにしなかったんだよな。library formの仕様は最終段階まであんまり注意してなかったんで
#なるほど。R6RS Library の最大の功績は、未束縛変数エラーの導入だと思っています。それ以外は、改善の余地があるかなあと。
#それについても、実行時にインクリメンタルに束縛を追加してゆくようなモデルには優しくないんだよね。
#>実行時にインクリメンタルに束縛を追加してゆくようなモデル
#って、例えばどんなケースでしょうか？
#typoをキャッチしてくれてありがたい、っていうのは、別に言語仕様じゃなくてツールでやってもいい気がするし。
#既にimportしてるライブラリについて、bugのworkaroundとか一時的な実験のために後からdefineとexportを注入するとか (Gaucheなら(with-module foo (export new-binding) (define (new-binding) ...)) みたいに)
#んー。なるほど。確かにそういうケースは少なからずありますね。
#R6RS 的には wrap ライブラリを書くのが良いんですかね。
#まあR6RSは「静的でポータブルなサブセット」であって、動的な部分はみんな処理系拡張って考えればいいんだけどね。
#でもr6rsのネスト可能なimport set指定方法は、後からライブラリに束縛が加わる可能性を考えると結構厄介。
#マッピング方法がいくらでも複雑になり得るので、(1)束縛が加わった時点で、それをインポートしているところでimport setを全部計算しなおすか、
#(2)インポートしている側がlookupする時に、ネストしたimport set演算の「逆演算」を行って元の識別子と照合するか
#静的なのが前提な仕様ですね。
#識別子のセットが固定なら何てことはないんだけどね。
#自分は R6RS に慣れてしまったので、動的な束縛の追加とかの便利さを気にしなくなってしまったなあ。
#バランスをとるには Gauche でもごりごりコードを書くべきかもしれん。
#まあ「動的」のレベルにも色々な主張があって、
#今のr6rs-discussの議論の中では、「マクロを再定義したらそれを使ってた関数全部マクロ展開し直し」みたいな主張さえある
#結局押したり引いたりしながらみんなが議論に疲れたあたりで適当なところに落ち着くんじゃないかなあ。
#その主張は気持ちは分かりますが、厳しいですねw。
Gauche > Archives > 2009/09/25