CommonLisp Scheme Part11

1 名前：デフォルトの名無しさん mailto:sage [04/08/02 23:13] 過去スレ Part1: piza2.2ch.net/tech/kako/987/987169286.html Part2: pc.2ch.net/tech/kako/1002/10025/1002584344.html Part3: pc.2ch.net/tech/kako/1008/10082/1008220265.html Part4: pc.2ch.net/tech/kako/1016/10162/1016211619.html Part5: pc3.2ch.net/tech/kako/1023/10230/1023091882.html Part6: pc3.2ch.net/tech/kako/1031/10315/1031560687.html Part7: ruku.qp.tc/dat2ch/0311/20/1042167213.html Part8: pc2.2ch.net/tech/kako/1058/10582/1058263391.html Part9: pc2.2ch.net/test/read.cgi/tech/1069594582/ Part10: pc5.2ch.net/test/read.cgi/tech/1075630259/ 関連リンクは>>2-10あたり 756 名前：デフォルトの名無しさん mailto:sage [04/10/14 01:54:45] アセンブラにすりゃただのジャンプ命令。 ジャンプ命令使わずにアセンブラでプログラム組めるわけが無い。 即ち、息をするようにgotoを使え。 757 名前：デフォルトの名無しさん mailto:sage [04/10/14 04:40:12] 引数つきgoto 758 名前：デフォルトの名無しさん mailto:sage [04/10/14 08:16:21] 〉〉753OSやリアルタイム制御の本みれば書いてあるよ。つーか知らないの？ 759 名前：デフォルトの名無しさん mailto:sage [04/10/14 08:28:20] ヘタレLisperと本物のプログラマを隔てるOSという一つの壁 760 名前：デフォルトの名無しさん mailto:sage [04/10/14 08:29:07] >>736-738 Prologの話? 761 名前：デフォルトの名無しさん mailto:sage [04/10/14 09:24:37] まだちんちんかゆいよーー！ なぜか皮が膨らんできてる・・・ 762 名前：デフォルトの名無しさん mailto:sage [04/10/14 11:39:34] >>751 ユーザモードのスレッドは、本質的にはコルーチンと同等だけど？ 763 名前：デフォルトの名無しさん mailto:sage [04/10/14 16:06:08] コルーチンって何？ 764 名前：デフォルトの名無しさん mailto:sage [04/10/14 16:18:27] >>763 www.google.com/search?hl=ja&lr=lang_ja&ie=SJIS&oe=SJIS&num=100&q=%83R%83%8B%81%5B%83%60%83%93 765 名前：デフォルトの名無しさん mailto:sage [04/10/14 17:26:42] >>762 ユーザーモードのスレッドは必ずしもそうでないと思うけど、 ユーザーモードのスレッドライブラリはそうだね。で、それが何か？ 話は変わって、 そもそもSchemeの継続ってプリミティブか？ 単にCPSで書けばいいだけじゃないの？こっちはどんな関数型言語にもできるし。 766 名前：デフォルトの名無しさん mailto:sage [04/10/14 17:43:15] 機械語のライブラリを実行中に継続を取ってきても きちんと動くように要請してるんじゃない？ 767 名前：デフォルトの名無しさん mailto:sage [04/10/14 20:38:44] >>765 なんでそこに CPS が出てくるのか意味がわからない 768 名前：デフォルトの名無しさん mailto:sage [04/10/14 20:45:57] >>768 Continuation Passing Style のことだよ? 769 名前：デフォルトの名無しさん mailto:sage [04/10/14 21:25:50] >>767 の言いたいことを推測。 CPSで継続を陽に扱うには、最初から全部CPSで書かなくちゃならない。 CPSで書かれていないコードから呼ばれるコードで継続を取り出したかったら call/ccはプリミティブにならざるを得ない。 …ってなとこか? CPSでもMonadみたいな形で継続を隠すことはできるけど、それだって 最初からそのつもりで書いてないと。 個人的には、Schemeの継続は言語の実験をするための道具って 感覚が強いな。 770 名前：765 mailto:sage [04/10/14 21:44:13] >>769 言語の要素のプリミティブじゃなくて、 >>750の > それこそ継続という概念が primitive なものであるということであり、scheme らしいところでは？ > primitive なものさえあれば他の機能はそれらを組み合わせてできる。美しい。 の話。 (Schemeの)継続なんて無くてもCPSで書けば、gotoでもコルーチンでも call/ccでも(w実現できるんだから、プリミティブな(基底をなす)機能ではないんでは？ ということ。 > 個人的には、Schemeの継続は言語の実験をするための道具って > 感覚が強いな。 同意。 771 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:03:36] やたら継続を美しいと賛美しているのは、つい最近大学の 講義で継続を知って嬉しくなってる厨房だよね？ 772 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:11:31] >>771 はい。 773 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:26:47] 四角いタイヤでも目盛がついていれば長さを測ったりできて便利かもしれんが、 それで高速道路を走るのは無理だ。 774 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:37:43] で? 775 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:42:13] ちんちんかゆいーー！ 776 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:44:58] >>775 切っとけ。 777 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:38:01] >>770 だから?基底をなす機能しか使っちゃいけないなら、 ラムダだけ使えば? 理論上は統べての計算はラムダ式で可能なんだから、 778 名前：デフォルトの名無しさん mailto:sage [04/10/15 00:28:51] 継続がプリミティブだからエライと言い出した のは継続厨房でしょうが 779 名前：デフォルトの名無しさん mailto:sage [04/10/15 01:15:03] だからつかわなきゃいいじゃん threadだろうがcall/ccだろうが理解してない 人間がつかうと危険なのは当たり前。 780 名前：デフォルトの名無しさん mailto:sage [04/10/15 01:20:39] >>778 エライなんて誰も言ってないよ 781 名前：デフォルトの名無しさん mailto:sage [04/10/15 10:39:17] >>777 基底をなす機能しか使っちゃいけないなんて誰も言ってないよ。 >>779 理解している人間が使ったって危険なんですが。 というか、誰が使っても危険なものだということを理解していない人間は 理解している人間ではないでしょうね。 782 名前：ミミ mailto:sage [04/10/15 14:26:27] >> 個人的には、Schemeの継続は言語の実験をするための道具って >> 感覚が強いな。 >同意。 私も同意。 例外処理のような代替機能があれば十分だと思う。 783 名前：デフォルトの名無しさん mailto:sage [04/10/15 16:26:43] どういう場合になにが危険といってるの？実装といっしょにあげてみてよ。 784 名前：デフォルトの名無しさん mailto:sage [04/10/15 17:19:01] >>782 で、言語の実験で良い結果が得られたらその度に代替機能を実装してくの? 785 名前：デフォルトの名無しさん mailto:sage [04/10/15 17:29:19] >>783 危険っぽいコード (define go #f) (call/cc (lambda(cc) (set! go cc))) (call-with-input-file "foo" (lambda(port) (go port))) はわわ〜 786 名前：デフォルトの名無しさん mailto:sage [04/10/15 17:32:26] >>784 パフォーマンスを上げたいなら専用化した方がいいからね。 限定的な継続にして万能な部分を切っていく。 VBのバリアント型みたいなものだよ。 787 名前：デフォルトの名無しさん mailto:sage [04/10/15 17:45:17] >>784 良い結果がって言うよりさ、そもそも言語の設計で「良い悪い」を 判断するのって使ってみないとわからんわけじゃん。で、処理系 ネイティブに実装する方式だと、その処理系を使ってる人しか 試せない。だけどSchemeの場合、かなり凝ったことまで言語組み込み のプリミティブを組み合わせで書ける。そしたら、R5RS準拠の 処理系ならどれでもその提案を試してみることができるわけだ。 こいういう場合に使われるcall/ccなんかは、むしろ提案する 言語機能の仕様記述なわけよ。ところが、Schemeの場合は その仕様記述が動かせるプログラムになる。 788 名前：!= 782 mailto:sage [04/10/15 18:26:51] >>784 そう。実装してく。 whileやらbreakやらgeneratorやらに抽象化してそれを安全に使う。 call/ccはそれを作る道具であって、call/ccのスパゲッティを毎回 ほどいて、俺には解けるから危険じゃないとか言って喜ぶための ものじゃないと思うね。 上手い抽象化を考えたりその抽象化を実装したりするのに頭をつかおう。 789 名前：ミミ mailto:sage [04/10/15 18:27:43] >>784 実用上の開発では言語実装にまで遡って設計の見直しを図ることは稀でしょう。 もちろん継続があったらあったらでよいと思いますが、 C における goto よろしく、大規模な開発では原則として禁じるのが妥当ではないかと。 ソフトウェア工学上は継続は狼男だと言っている方がいらっしゃいましたが、 その視点におけるその意見には同意するということです。 >>785 それは継続の問題というよりも、 プログラミングの腕の問題という気が。。。 do でも論理エラーがあれば無限ループが書けるわけだし。 >>786 >パフォーマンスを上げたいなら専用化した方がいいからね。 >限定的な継続にして万能な部分を切っていく。 これに同意。 Scheme に継続しか用意しないというのは実用的ではないという感じがします。 790 名前：デフォルトの名無しさん mailto:sage [04/10/15 19:46:48] 「実用的な」制御構造がいずれも継続の上に（マクロで？）構築した ライブラリとして書けるっていうのがSchemeの主張なんじゃないの？ 791 名前：デフォルトの名無しさん mailto:sage [04/10/15 19:52:56] 話がループしているのは継続のせいですか？ 792 名前：デフォルトの名無しさん mailto:sage [04/10/15 20:06:32] じゃあ高速な継続の実装の仕方でも考えるかい？ 793 名前：デフォルトの名無しさん mailto:sage [04/10/15 20:35:42] >>791 gotoのせいです。 794 名前：デフォルトの名無しさん mailto:sage [04/10/15 21:18:32] >>790 そう。 パフォーマンスとかが必要ならそれぞれの実装系においてライブラリ部分をCとかで実装していけばよい。 795 名前：デフォルトの名無しさん mailto:sage [04/10/15 22:36:02] 結局Ｓｃhｅmｅは非実用的ということですね 796 名前：デフォルトの名無しさん mailto:sage [04/10/15 22:39:54] わざわざ去勢する必要もなかろう 797 名前：デフォルトの名無しさん [04/10/16 01:39:19] CommonLispのマクロについての質問。 マクロはコンパイル時に評価を行う、ということは、コンパイルプロセスを 実行プロセスから分離することはできない、ということでOKでしょうか? また、関数の中でマクロが定義されている場合、関数が呼び出される度に マクロ展開(とコンパイル)が行われるのでしょうか? 798 名前：デフォルトの名無しさん mailto:sage [04/10/16 01:58:24] どういう動作をすると思ってるの？ 799 名前：797 mailto:sage [04/10/16 02:06:33] 実行とコンパイルがインターリーブしていて、マクロの展開関数の中 から他の変数なんかも参照できる。その変数の値によって、展開の結果 が変わるかもしれない...というふうに"思って"います。 根本的に間違ってますか? 800 名前：デフォルトの名無しさん mailto:sage [04/10/16 03:39:45] 継続の話。 Kawa(Java による Scheme 実装)の継続は例外処理(try - catch) によって実装されているね。確か大域脱出しかできなかったような気 がする(Common Lisp の block 相当)。 実際、おれの場合、大域脱出くらいでしか継続は使ったことないな。 801 名前：デフォルトの名無しさん mailto:sage [04/10/16 04:37:48] >>797 >コンパイルプロセスを実行プロセスから分離する lispには eval関数の様に実行時に式を評価する仕組みがあるので コンパイル環境と実行環境を分離するのは難しいと思う。 でもこの話は、マクロとは関係ないような気がする。 >関数の中でマクロが定義されている場合 関数内でマクロを定義した場合の動作など考えたことが無かった。 で、やってみた。 ;; 関数定義 (defun test (x) (cond ((equal x 1) (defmacro m () 10)) ((equal x 2) (defmacro m () 20)) (t nil)) (m)) ;; 実行結果 ・・・ clisp の場合 (test 0) => 20 (test 1) => 20 (test 2) => 20 ;; 実行結果 ・・・ xyzzy lisp の場合 (test 0) => 関数が定義されていません: m (test 1) => 10 (test 0) => 10 (test 2) => 20 (test 0) => 20 xyzzyではマクロ展開を実行時に行っていて、clispでは関数定義時に 行っているようだ。CLtL2 的にはどうなっているんだろう？ 802 名前：デフォルトの名無しさん mailto:sage [04/10/16 08:26:44] 重複定義でエラーが正解 803 名前：デフォルトの名無しさん mailto:sage [04/10/16 09:41:37] >>801 その例は実行時までプログラムの意味が決まっていないよね？ そういうマクロはたとえ可能としても悪いマクロだと思う (実際おれは不可能と思ってたし) 役に立つ場合って何かあるかな？ 804 名前：デフォルトの名無しさん mailto:sage [04/10/16 15:10:07] >>797 > また、関数の中でマクロが定義されている場合、関数が呼び出される度に > マクロ展開(とコンパイル)が行われるのでしょうか? コンパイルされたコードの中でのマクロ展開はコンパイル時に行われて、 実行時には再度行われない、てことになってます。 ですから、関数内でマクロを再定義するようになっていたとしても、 展開に使われる手続きはコンパイル時の環境にあるものになるはずです。 コンパイルしない場合には、何時、何度展開されるかは実装依存です。 cf. www.lisp.org/HyperSpec/Body/sec_3-2-2-2.html >>801 xyzzy でもコンパイルすると clisp と同じ結果になりますね。 でもいまいちピンとこない結果だなあ。 (defmacro m () 20) は展開時には、つまりコンパイル時であれ関数定義時であれ、評価されませんよね？ だったら (m) は展開できない気がするんですが。勘違いしてる？ 805 名前：ミミ mailto:sage [04/10/16 15:19:43] > (defmacro m () 20) は展開時には、つまりコンパイル時であれ関数定義時であれ、評価されませんよね？ リーダが読み取って、最適化された内部構造体に変換するときに、 ついでに defmacro を評価してしまうという実装はあり得ると思う。 (そんな処理系を見たことがある気がする。) その場合、最後に出てきた m の定義によってオーバーライドされてしまうので、 上記のような結果になるのでは。 806 名前：804 mailto:sage [04/10/16 15:34:00] >>805 あーなるほど、それなら納得いきますね。 確かに普通それで問題ないでしょうし。 807 名前：デフォルトの名無しさん mailto:sage [04/10/16 16:17:58] そういうマクロはエラーにして欲しいなあ。 eval介入するならともかく、使い道なんてないでしょ。 808 名前：デフォルトの名無しさん mailto:sage [04/10/16 17:47:56] Gaucheはエラーになった 809 名前：デフォルトの名無しさん mailto:sage [04/10/16 18:00:35] >>808 GaucheってSchemeでしょ？ Scheme的には>>801て文法的にありえんし… mのスコープが意味不明。 810 名前：デフォルトの名無しさん mailto:sage [04/10/16 18:27:24] >>797-799 > また、関数の中でマクロが定義されている場合、 これって macrolet のことを言いたいのかなあ、とふと思った。 > 実行とコンパイルがインターリーブしていて、マクロの展開関数の中 > から他の変数なんかも参照できる。その変数の値によって、展開の結果 > が変わるかもしれない...というふうに"思って"います。 これについては、こんな例もあるかな。 (defvar *foo*) (defmacro %foo (x) `(,(if *foo* 'car 'cdr) ,x)) (defun foo (ls key) (let ((*foo* key)) (%foo ls))) として、 (let ((ls '(a b c))) (values (foo ls t)(foo ls nil))) => ? , ? とりあえず今手元にある xyzzy では、コンパイルしないと a , (b c)、 コンパイルするとコンパイル時の *foo* の値によって a , a or (b c) , (b c) が、 更に *foo* の値が未定義だと (b c) , (b c) が返ってきました。 ……しかし、どうにも病的な例しか思い浮かばないなあ。 811 名前：デフォルトの名無しさん mailto:sage [04/10/16 20:26:58] letがないものが条件コンパイルのイディオムとして使われて てもよさそうだと思ったんだけど、そうでもないのかな？ 812 名前：797 mailto:sage [04/10/16 22:43:41] コンパイル時の環境・値をキーワードにしてHyperSpecを必死になって 読んで、部分的な理解を得ました。 マクロ展開のようなコンパイル時に実行される式はevaluation env.のもと で評価され、そうでない本当に実行時に実行される式はrun-time env.のもと で評価される。で、evaluation env.とrun-time env.が同一である保証は 無いと。 私の場合、この二つが同一と仮定していたので、797の発言になったわけ ですね。実際は、run-time env.の中の束縛とは異なるかもしれない束縛を evaluation env.に加えてやることでコンパイルプロセスを実行プロセスから 分離していると。 後は、コンパイルの過程でevaluation env.がどのように構築されていくのか が解ればいいのですが、これも理解に時間かかりそう。 >>810 まだ文法に自信がないですが、こんなのなら病的ではないかと。 期待通りには振る舞わないみたいですが。 (defun debug-print (form value) ...) (defvar *do-debug*) (defmacro debug-value (form) (if *do-debug* (list debug-print `(quote ,form) form) form)) 813 名前：Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞Ｓｃｈｅｍｅ mailto:sage [04/10/17 06:09:54] Scheme を駆使して、「普通のやつらの上を行け」るのは、(少なくとも現状では、そして恐らく永久に)ごく一部のプログラマであって、 普通のプログラマが少しでも「普通のやつらの上を行け」るのは、Ruby になるような気がしています。 jp.rubyist.net/magazine/?0002-WCNewsPaper#l7 814 名前：デフォルトの名無しさん mailto:sage [04/10/17 06:26:35] 結局のところ、CommonLispでマクロを安全に使うには、 (1)トップレベルで定義する。関数内では定義しない。 (2)同名のマクロの再定義はしない。 (3)スペシャル変数等の環境で動作が変わるマクロは書かない。 ということですか？ 815 名前：デフォルトの名無しさん mailto:sage [04/10/17 10:15:21] ものをちゃんと理解する、が一番じゃないかな。 まあ理解できないからこそ安全に〜とか言ってるんだろうけど。 816 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:04:12] >>815 それなりの指針を与えることは、有益だとおもうけどどうかな。 だれだって最初は初心者な訳なんだし。 817 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:11:48] >>816 指針としては、 マクロは単に式を変形する ・ソースを短かくするために書け ・いつ式が変形されたか気を付けろ(コンパイル時、実行時、再定義に注意) って基本を叩きこめば十分じゃないか？まだあるかな？ 818 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:52:18] >>816 > だれだって最初は初心者な訳なんだし。 これってよく使われるフレーズだけど全然言い訳になってないよな。 最初は初心者でも自力修得できる奴はなんぼでもいる。 819 名前：デフォルトの名無しさん mailto:sage [04/10/17 13:24:58] >>813 おそらくはマクロ等を駆使することで、 「問題領域における問題の記述とコードが同一になる」 Lisp/Scheme すげえ！ って思うんだがどうよ？ 820 名前：デフォルトの名無しさん mailto:sage [04/10/17 15:23:24] >>817 >・ソースを短かくするために書け これは同意できない。 結果としてソースが短くなるケースが多いとしても、ソースを短くすることは マクロを書く目的にはなり得ません。 821 名前：デフォルトの名無しさん mailto:sage [04/10/17 17:30:59] あんたにはならなくても俺はなるな 822 名前：デフォルトの名無しさん mailto:sage [04/10/17 17:59:41] 結果として短くなるのと、短くするのを目的として使うことを混同してませんか？ 823 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:11:15] >>818 わからないことを責めてはいけないとおもう。 わかろうとしないことだとしてもそうだと思う。 そういう人を取り込むことが言語のすそのを広げることになるんじゃないかな。 824 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:14:49] >>821, 822 ソースコードの性質によるのかな〜と思うけど、どうかな。 長く、広く使われるコードであれば、直感にあう抽象化を するためにマクロを使うべきだろう。 けど、テストコードなんかの場合はとにかく楽をするために マクロを使っても良いように思う。 825 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:31:27] >>813 言語に「上下」があるわけではないと思うけどなぁ。 俺は ruby も好きだけど、scheme で書いてる時とは気分が違うよね。 なんつうか、ruby は relax しながら書くけど、scheme だと、集中して 研ぎ澄まされてく感じがする。抽象的だけどさ。 826 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:34:07] (DQNﾆﾚｽｽﾝﾅﾖ) 827 名前：デフォルトの名無しさん mailto:sage [04/10/17 19:55:25] >>813 いいんだよそれで。「普通のやつら〜」が言ってるのは競争の激しい ベンチャー企業は最大限に生産性をあげないと生き残れない、そのために 最強の言語を使うべきだって言ってるんであって、その他大勢が 何を使おうが知ったこっちゃない。あの文章は生きるか死ぬかの極限での サバイバル術について語ってるんだ。そんな環境に置かれていないなら、 好みで言語を選べばいいのさ。 828 名前：デフォルトの名無しさん mailto:sage [04/10/17 22:38:11] 普通のプログラマにはjavaをお薦めします 829 名前：デフォルトの名無しさん mailto:sage [04/10/17 22:54:30] ノーマルプログラマにお薦め→java アブノーマルプログラマにお薦め↓ 830 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:01:54] C 831 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:41:06] この掲示板は何言語で運営してるの？ 832 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:46:39] >>820, 822 817 だけど(!= 821 ね) 煽りじゃなくて、どんな目的でマクロ書くのか教えてくれないか？ おれはマクロに関してはソースを短くする事しか考えてないんだけど… あ、「短く」じゃなく「明快に」、と格好良く言えば伝わるかな？ >>824 おれはテストコードは逆にマクロつかわないなぁ テストコードのテストなんてしたくないから コピペでも良いから単純に書く、どうせテストなんだし 833 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:04:11] >>832 私の場合:  * with-なんとか系 --- 最初と最後にお決まりの文句がある処理とか  * 関数のインターフェイス --- (foo-format t "~A" obj1 "~A" obj2 ...) とやりたい． 834 名前：デフォルトの名無しさん [04/10/18 00:04:20] Ｒｕｂｙ！！！！！！！！！！！！！！！！！！ 835 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:14:14] >>832 820でも822でもないですが イディオムや式に名前を付けるとき。短くなるとは限らない。 836 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:31:51] >>835 確かに短くても慣れてないイディオムを包むマクロは書くことあるけど (そしてその名前が長い時もある) 何回も使えば少なくとも行数は短かくなる気がするけど… (本当はタイプ量も少なくしたいけど補完があるから気にしない場合はある) 良い例がありますか？ 837 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:48:40] マクロの例は，いろんなプログラムのソースがヒントになるなと思ったよ． 名前は忘れたけど数値計算のやつでは，型チェックをやってた． ソースを見ると，その関数の引数の型が一目瞭然になってるの． 838 名前：デフォルトの名無しさん mailto:sage [04/10/18 01:53:24] ソースのバイト数を減らすってのもいいけど （例えば call-with-current-continuation → call/cc， multiple-value-bind → mvbind など）， 重要なのは定型的コード内のパターンを抽出して構文要素数を減らすことだぜ？ ただ，inline関数で実現できるならその方がいい． "On Lisp" を読めば抽象化手段としてマクロを使うべきかどうかの判断規準（の一例）が示されてるけど... 839 名前：デフォルトの名無しさん mailto:sage [04/10/18 06:36:49] cgiにschemeが使える無料鯖ってあるの？ 840 名前：デフォルトの名無しさん mailto:sage [04/10/18 07:31:33] >>838 が正しいな、おかげですっきりしたぜ 841 名前：デフォルトの名無しさん mailto:sage [04/10/18 08:58:39] さんざん既出だがSchemeの基本構文要素なんて10個に満たないが、 全く不便に感じないのは強力なマクロの記述能力があるからだよ。 処理系がI/Fを開放してればマクロを通してそのままマシンコードに落とせるし、 コンパイラとマクロの間には区切りがない。 LISPは本来処理系のコンパイラが貧弱でも後付でカバーできる程の能力を 秘めているが、あまりそれを認識してる奴はいないみたいだな。 ユーザーにスキルがあれば自力でinline-expandやlambda-liftingの様な プリコンパイルが簡単に追加できる。 コアの作りこみを最小限とすれば新しい処理系はすぐに完成する。 人間で言うと脳や神経だな。骨格や肉付けはすべて後回しでいい。 コアを何度も作ってる奴は、残りをすべて使い回しが利くS式で記述する筈だ。 だからGaucheの様なCでなんでもかんでも書く方針はちょっといただけないな。 確かに労せず速い処理系になるだろうが、それは処理系固有のモノになってしまい、 LISPの自己拡張性を否定しかねない。 どのみちブートストラップの真似事してるんだからVMに渡すプリコンパイラぐらい Scheme自身で書いてみろよ。パフォーマンスにさほど違いはないから。 と、Gaucheのソース流し読みして思った次第。 842 名前：デフォルトの名無しさん mailto:sage [04/10/18 09:24:51] I/Fって何？ 843 名前：デフォルトの名無しさん mailto:sage [04/10/18 09:28:23] それは処理系固有のモノになってしまい、LISPの自己拡張性を否定しかねない。 ってどういう意味？ 他の処理系でもマクロで拡張するんなら処理系固有とか関係なく思えるが。 844 名前：デフォルトの名無しさん mailto:sage [04/10/18 09:35:03] >>841 Gauche開発の動機と目標を知っててあえて言ってる？ 845 名前：デフォルトの名無しさん mailto:sage [04/10/18 09:56:30] >>844 これか? www.shiro.dreamhost.com/scheme/gauche/memo-c-j.html 846 名前：841 mailto:sage [04/10/18 10:27:07] >>842 ぐぐれ >>843 処理系に固定化され、固定化されたコードはそれ以上進化する余地なくなるということ。 >>844-845 そのリンクの文章のことではなかったけど、その中から異論を唱えると、 >実行時に、その言語のための環境(スクリプトライブラリ、初期化ファイルなど)を > フルセットで持てるとは限らない。 最悪の場合、アプリケーションはそのバイナリ > 単体で動作することが要求される。 これは単にアイデアが枯渇しているだけだろう。 実行ファイルに環境を埋め込む手段はいくらでもあるし、さらにその上に 環境の永続化という手段もある。 >アプリケーションの実行の主体はC/C++で書かれたコードで、 > その中から頻繁にちょっとしたリスト処理や文字列処理なんかが呼び出される。 これはevalそのものやVM、マシンコードの入り口を用意していれば済む事。 それに結局GCを伴うので、現実的には外部から頻繁には呼び出せず、一括して呼び出す方針になりがち。 そもそも外部のコンパイラが必要な時点でプロダクション環境とやらには論外だろう。 >むしろ、 memqなんて基本的なパーツはCで書いとくべきなんだ。 memqの様なすぐ代替が利く極端に小さいパーツならこの手も有効だろうが、 少しでも大きな処理になるとこの思想は破綻する。作者もそれはわかってるみたいだが。 結局実際は実装が二極化し、複雑性が増加しただけだろう。 組み込みスタブ関数郡のメンテナンス性の悪さを見ればわかる。 こんなところか。 847 名前：デフォルトの名無しさん mailto:sage [04/10/18 10:39:16] ぐぐってもわからんぞ。 848 名前：デフォルトの名無しさん mailto:sage [04/10/18 10:40:26] じゃあ、あんたがSchemeの処理系書いて配ればいい。 849 名前：デフォルトの名無しさん mailto:sage [04/10/18 10:44:37] 処理系に固定化され、固定化されたコードはそれ以上進化する余地なくなるということ。 進化させたかったら処理系に手をいれればいいじゃん。 850 名前：デフォルトの名無しさん mailto:sage [04/10/18 10:53:03] >>848 公開が面倒なだけでそういう処理系は数年前に作ったよ。 >>849 それは処理系の完成度が低いと暗に示しているにすぎないだろ。 商用にするなら論外の提案。 顧客毎に固有化して、いったい誰がメンテするんだ？ 851 名前：デフォルトの名無しさん mailto:sage [04/10/18 11:03:16] 公開してなければただの妄想言語 顧客ごとの固有化はマクロを使えばいいだろ。 852 名前：デフォルトの名無しさん mailto:sage [04/10/18 11:28:06] 841は組み込み系とかはやったことないんだろうなぁ 853 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/18 12:11:42] GaucheがCでの実装を多用しているのは、現バージョンでの実用性を考えると仕方のない部分が多いのではないだろうか。 VMでは各インストラクションごとにテーブルを使った間接分岐が行われるが、この時、ほぼ毎回分岐予測を失敗することになる。（PC用で、これの分岐予測をうまく行ってくれるプロセッサーは無いと思う） 今のプロセッサーでこのペナルティーはでかすぎる。1ワードのデータのLOADやPUSHを行うたびにパイプラインがフラッシュされるんだから... つまり、速度を出すにはVMのインストラクション数を減らすことが重要ということになり、そのためにCで書く部分が多くなるといったところではないだろうか。 根本的な解決にはネイティブコードに落とす必要があるが、これとインタラクティブな環境を両立するのは難しい。 商用のChez Schemeならそれが出来ているが、個人が作っている処理系でそれが出来ていなくとも、あまり乱暴な言葉遣いは良くないと思う。 真面目な開発者ならネガティブな意見は大歓迎だと思うし、それは遠慮なく伝えていいと思う。 変な信者のラブレターよりよっぽと嬉しいだろう。でも礼儀は忘れないでほしい。 854 名前：824 mailto:sage [04/10/18 13:55:18] >>832 へええ、おもしろい。 私もテストコードにはややこしいマクロはかきませんが、 いまいち自然じゃない、長くは覚えていられないような 展開をするマクロをかくことはあります。 以下の２つがその主な理由です: 1) テストはだいたい1ファイルに閉じてるので読めばわかると思う 2) テストは繰り返しや比較が多いのでなるべく自動化したい 855 名前：デフォルトの名無しさん mailto:sage [04/10/18 15:42:44] ＞そのためにCで書く部分が多くなるといったところではないだろうか。 話がつながってない気が 856 名前：デフォルトの名無しさん mailto:sage [04/10/18 17:13:28] >>855 「VMで実行するインストラクション数を減らすために処理系やライブラリー関数をSchemeでなくCで実装する」を意図しておりました。 説明がへたですまぬ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef