CommonLisp Scheme Part13

1 名前：デフォルトの名無しさん [2005/05/12(木) 21:44:01 ] 過去スレ 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: pc5.2ch.net/tech/kako/1042/10421/1042167213.html Part8: pc5.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/ Part11: pc5.2ch.net/test/read.cgi/tech/1091456033/ Part12: pc8.2ch.net/test/read.cgi/tech/1100229366/ 関連リンクは>>2-10あたり 281 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 16:02:01 ] >>280 > そういう意味では「アリティ」のほうがましかも。 それはない。 282 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 17:52:52 ] アリティ（引数の個数）... として、以降アリティで良いんじゃないかな 283 名前：ミミ mailto:sage [2005/06/11(土) 18:15:03 ] ちなみに、「引数の数」と「引数の個数」では、 後者ののほうが分かりやすいと思うんだけど、 「個数」って訳する人、意外と少ないんだよねぇ。 284 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 18:18:41 ] アニキィ 285 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 18:26:10 ] ありていにいって>>281に同意。 286 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 18:35:56 ] >>285 全米が凍った 287 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 20:54:02 ] 確かにGaucheのマニュアルで説明無しにarityという 用語が出てきて困ったな〜。 288 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 21:25:31 ] めんどいからもう引数数でいいんじゃね 289 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 21:26:57 ] アミティ 290 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 21:27:48 ] arityという単語を覚えて貰うためにも、ちゃんと説明した上で「アリティ」で良いと思う。 どうせいつかは英文のマニュアルとか読む機会もあるだろうからね。 291 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 22:15:51 ] だったら変なカタカナにするよりarityのままの方がいいような 292 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 22:39:14 ] それは翻訳としては不完全。 商用レベル文書の品質としては失格。 293 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 22:46:35 ] そんな業界基準があるなら正してもらう必要があるな。 間違っている。 294 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 22:56:50 ] そろそろ誰かコードを… コードをくれ 295 名前：デフォルトの名無しさん mailto:sage [2005/06/11(土) 23:05:08 ] 商用レベルの邦訳って変な拘りがあるんですね。 それで分かり難い訳本が多いんですね。 納得しますた。 296 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 00:15:55 ] まともな翻訳には日本語で表現できる概念を増やすという役割もあるから。 297 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 00:22:08 ] . o O (理想が高過ぎると返って悪い結果を生む良い例だな...) 298 名前：通りすがり mailto:sage [2005/06/12(日) 00:29:43 ] いやだから、人類の知性の向上に役立ってない屑は関係ないって。 屑はいつもみたくν速で一日中遊んでりゃいいやん 299 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 00:38:36 ] 元数は納得できる訳語だな。 方程式でも変数がxだけなら1元、xとyなら2元というのを そのまま函数にも適用したという感じだ。 (方程式の変数の数を元数というのは日本でも普通) 今辞書を引いて初めて知ったんだが、函数というのは中国由来で functionのfunと同音の字を当てたらしい。関数は日本で更に同音の字を 当てて書き換えたものとか。 googleで関数(簡体字で)を検索すると世界で4件しか引っ掛からん。 300 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 00:56:59 ] 四元数とかの元数か。悪くないね。 ただ、やっぱり使う前に説明が必要だね。 301 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 01:10:03 ] ここ数ヶ月、随分レベルの低い話題ばっかだな。 302 名前：3歳児 mailto:sage [2005/06/12(日) 01:11:00 ] レベルが低いのは、ここ数ヶ月ではなく ここ数日のまちがいだとおもいます。 303 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 01:20:17 ] >>302 3歳は もう寝ろYO! 304 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 01:21:48 ] 最高につまんねぇレスだな。 305 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 01:27:16 ] 自演コテが湧くよりゃマシだ 306 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 02:17:46 ] Joswig ﾀﾝの Concordia デモムービー見たんだが、あれが本物の CLIM かぁ 今見ると、やっぱりちょっと古くさいね… 307 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 13:23:58 ] えぇぇ〜CLIM(Common Lisp Interface Manager)？ Symbolics みたいなタイルウィンドウシステムでしょ。 一度触ってみたいなぁ。 Macintosh CommonLispのdigitoolには Mac用バイナリがまだ置いてあるみたいだけど 308 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 20:45:30 ] >>301 君のいうレベルの高い内容を提示してくれよ。 309 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 21:24:01 ] (gc) 310 名前：デフォルトの名無しさん [2005/06/12(日) 21:29:58 ] OS ネイティブのスレッドを扱える Lisp/Scheme 処理系はありますか？ 311 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 22:14:02 ] >>310 >>262 312 名前：デフォルトの名無しさん mailto:sage [2005/06/12(日) 22:27:55 ] 誰かILC2005行く香具師いる？ 313 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 02:08:41 ] Commonclipseかと思った。 www.eclipsewiki.net/eclipse/?Commonclipse 314 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 04:05:46 ] >>310 scheme なら gauche と KSM も Lisp/Scheme 以外でもフリーの処理系でネイティブスレッドを サポートしている物は非常に少ない 知ってるのは OCaml, GHC, Perl, Python, Erlang くらいかな SML 系は全滅っぽいね 315 名前：デフォルトの名無しさん [2005/06/13(月) 11:31:38 ] >>314 > サポートしている物は非常に少ない なぜ少ないのでしょうか？ 316 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 11:55:13 ] >>315 面倒なんだろ。 317 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 12:02:55 ] >>315 おこちゃまだから。。 318 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 12:07:21 ] 頭の悪いレスだ 319 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 12:52:33 ] >>318 おまえがな。 320 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 13:04:14 ] 必死だな 321 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 13:12:15 ] >>320 See: 319 322 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 13:18:21 ] × おまえがな ○ おまえモナー 323 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 13:37:46 ] >>322 See: 320 324 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 14:02:20 ] ・・・・・・ここからはLispに関係ないレスは禁止・・・・・・ 325 名前：デフォルトの名無しさん [2005/06/13(月) 20:38:12 ] 後藤英一先生のご冥福をお祈りします。 326 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 20:49:40 ] IPSJ コンピュータ博物館 後藤英一　- 日本のコンピュータパイオニア www.ipsj.or.jp/museum/pioneer/gotou.html 327 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 20:57:40 ] この人か。HLISP 作った人なんだね。 www.ipsj.or.jp/katsudou/museum/pioneer/gotou.html www.mainichi-msn.co.jp/shakai/fu/news/20050614k0000m060060000c.html ttp://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/essay/omoide >>315 理由はここら辺じゃないかな 1. 実装が面倒 2. 1CPU のマシンではネイティブスレッドのメリットが見えにくい 3. Linux のスレッドがイケてなかった 1 は GC 絡みとかなのかな 2 は最近の CPU のデュアルコア化でちょっとはメリットが出てくるかも 3 は 2.6 以降問題なくなった（らしい） 328 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 21:01:10 ] ｽﾏｿ。リロードしてなくて被った。 Lisp Machine ってスレッドとか LWP みたいな概念はあったのでしょうか? 329 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 21:04:33 ] GUI作ったりメリットは沢山あるよ。 やっぱ面倒なんじゃないかね。 作るとしたら、GCやコンストラクタは排他制御して、 オブジェクトの更新毎にWriteバリアかね。 やっぱGC周り面倒だなあ。 適当に作ったらすぐ破綻しそう。 330 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 21:54:17 ] JavaのGCなんかを見るとネイティブスレッディング自体はそれほど性能的な ハンデにはならないのかなという気もする。面倒なのは同意だけど。ｗ 331 名前：デフォルトの名無しさん mailto:sage [2005/06/13(月) 22:03:28 ] >>325 まじか。 中西（正和）先生も少し前に亡くなったが、今度は後藤先生か。 332 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 10:56:27 ] このスレでもおなじみの新山ゆうすけ氏が、Common Lisp の仕事を始めたらしい。 tabesugi.net/memo/2005/62.html#111413 > しかし相手はそこそこ有名なLisp ハッカーであり、習うべきことは多い。 > Lisp で仕事できる機会なんてそんなにないと思う。 などと書いている。今まで Lisp の悪口ばかり書いていたのになあ。 と思ったら、今日はさっそく Lisp の悪口であった。 tabesugi.net/memo/2005/62.html#131404 やっぱり新山氏はそう来なくっちゃ！ 333 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 12:56:36 ] >>332 なんか有名な人なの？ 嫌いな言語使って仕事してるっていう愚痴のようにしか読めんが。 334 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 14:50:02 ] >>333 NY市立大の院生で、Python や Scheme、OpenSSH の世界ではそこそこ有名な人。 www.unixuser.org/~euske/doc/index.html Shiro さんが wiliki で取り上げたこともある。 www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro%3alog%3a2004%b8%e5%c8%be 335 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 15:01:18 ] >>334 何言ってんの？ この人ぜんぜん有名じゃないよ。 336 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 18:25:51 ] 有名かどうかは人それぞれが判断すればいいこと。それより、内容についての 話をしようよ。 Common Lisp のライブラリが、過去互換性のために見通しが利きにくいこと、 package は実用上不可欠なのに、Scheme にはまだ標準がなく、実装依存だと いうこと、これらはもっともな批判だと思うのだけど。 337 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 19:06:44 ] ごく一部の日本人で英語が読めない奴限定で有名かも知れんが >>334 > Python や Scheme、OpenSSH の世界ではそこそこ有名 なんていうような仕事はしとらん。 まあ言ってみればプチ岩谷宏。 338 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 19:08:14 ] LispはJavaにMLはC#に昇華しましたので、そのようなことを考えること自体無駄です。 339 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 19:36:34 ] >>336 > Common Lisp のライブラリが、過去互換性のために見通しが利きにくいこと、 確かにそういう面は否定できないが、正直言って慣れてしまったね。 それを言うなら例えば C のライブラリとか UNIX のシステムコールにしたって 「過去互換性のために見通しが利きにくい」と思うし。 誰かが整然とした New Common Lisp を設計したとしても、それを布教するのは 大変だろうなぁ・・・ 340 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 20:04:52 ] Scheme はそういう整然とした Lisp の標準を作ろうとしているわけだが、議 論百出で、いつまでたっても Common Lisp 並のライブラリがそろわない件に ついて。 341 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 20:12:26 ] 今のペースだと、 あと50年は掛かるな 342 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 20:25:24 ] C や UNIX の設計のまずいところを一気に作り直そうとした Plan9(Inferno) も、いつまでたっても実験段階から離陸しないものね。 コンピュータ技術、ひいては技術一般に、いかに市場とのタイミングというも のが重要か、分かるように思う。 343 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 20:41:53 ] 「技術」の一般論を語るには、まだまだじゃない？ 現状と個人の経験なわけで。 このスレには厳密主義が多いかと思った。 344 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 20:47:54 ] >>338 ちょっと待て、聞き捨てならん。こんな書いてて楽しくないものが、LISP の 昇華物であってたまるかぁっ！ 345 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 21:03:17 ] >>344 昔、Lispの研究をしていた人がSunに行ってJavaを作り、それに対抗したMicrosoftが MLの研究グループを引き抜いてC#を作ったんだよ。 Lispは特にリサーチプロジェクトなんかには便利な言語だね。　Javaは大規模なプロジェクト 向きかな。　要するに、適材適所で使えば良いかと。 346 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 21:09:40 ] 昇華（しょうか）(Sublimation) 物理学では 　　省略・・・ 心理学では 　防衛機制の一つ。 　実現不可能な目標・葛藤や満たすことができない欲求から、 　別のより高度で社会に認められる目標に目を向け、 　その実現によって自己実現を図ろうとすること。 　例）かつてアクション映画で活躍したが、 　　障害を負ってアクション映画に出演できなくなった→障害者保護団体を設立する 347 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 21:18:09 ] >>345 本気で言ってるのだとしたら面白すぎる 348 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 21:22:16 ] → 数理論理学では ならば 349 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 21:33:23 ] >>345 それって、ガイ・スティールのことか？Java はやっぱりジェームズ・ゴスリ ングのものだと思うのだけどなあ。ゴスリングとビル・ジョイが Java の仕様 でもめたところを、ガイ・スティールがまとめたんだろう。彼は他にもいろん な言語の仕様に関わってるし。JavaScript とか。 ML とC# の関係は全然知らなかった。ありがとう。 350 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 22:08:05 ] 下らん ヒント：Java, Delphi, ObjectPascal 351 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 22:15:33 ] >>349 > 彼は他にもいろんな言語の仕様に関わってるし。 をいをい。Schemeを忘れるなよ。ｗ 時系列で言えば Scheme→Common Lisp→Java の順で手がけている。 もちろんこの順序と言語の優劣は関係ない。 漏れはGuy Steeleの絡んだ言語はすべて好きだよ。 352 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 22:24:29 ] >>351 初期のJavaの研究会行ったら「私の仕事はGuy L. Steele 仕事ですｗ」という奴が居て噴いたなぁ。 　Scheme → CommonLisp → StarLisp, C* (ThinkingMachine) → HighPerformanceFortran → Java のうち、漏れ自身ThinkingMachine以外はやってたｗ 353 名前：デフォルトの名無しさん mailto:sage [2005/06/14(火) 22:48:06 ] C: A Reference Manual を書いたり ECMAScript の標準化を手伝ったりも 354 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 00:09:09 ] ガイ・スティールの手のひらでころがされてる気分になってきた 355 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 00:20:44 ] >>344 反応するなよ >>349 騙されるなよ 356 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 00:31:28 ] >>345 ダウト 357 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 01:21:56 ] r6rs の作業が始まってから一年半経つけど、あとどのくらい掛かるんだろうか。 UNICODE サポート、例外機構、モジュール機構、構造体辺りが楽しみだ。 モジュールは長く標準化が待ち望まれた機能だしね。 358 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 01:28:41 ] 構造体作るから多値はいらないという 多値は受け取ったり受け取らなかったりと、今一不可解なプロトコルと言える 参照ベースな言語では構造体パックが正解なのかもしれない 359 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 03:35:45 ] >>339 そこで Arc ですよ。 >>358 個人的には多値で渡していくやり方は細かいことを気にせずに済んで好きなんだけど、 いまいち現状だと構文上すっきりしないところが多いのも確かですね。 wiliki であった、アリティに応じて返す値の数を変えられるようにする、 ってのは結構面白いなあと思った。問題が色々出て来ちゃうみたいだったけど。 ……でもその辺すっきりしたいなら他の関数型言語に転んじゃった方が楽な気が。 どうせ構造体でパックしちゃうなら 1-in 1-out で、型付けも静的な方が楽じゃないですか？ 360 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 07:09:22 ] 多値で受け取るのも、構造体のアクセッサ経由で値を受け取るのも、 手間は変わらないって考えて良いのかな。 361 名前：デフォルトの名無しさん [2005/06/15(水) 11:25:48 ] こんな感じかな？ (i) 構造体のコンストラクタが関数の末尾位置にあるときは、構造体 そのものをスタックにアロケートして、 (ii) その関数の呼び出し側で返値（構造体）がエスケープしないなら そのままスタックの上で使う。 362 名前：デフォルトの名無しさん mailto:sage [2005/06/15(水) 11:37:37 ] 割り込み失礼。スラドに載った。シンボルを HashTable にしたのが後藤氏の 仕事とは知りませんでした。 「日本のコンピュータ研究の先駆者、後藤英一さん他界」 slashdot.jp/article.pl?sid=05/06/14/0954213&topic=89&mode=nested&threshold=-1 363 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 11:02:58 ] 質問です。 『初めての人のためのLISP』を図書館で借りて読んでいるのですが、ちょっと 分からない点があります。 P147 ------------------------- 初心者は nconc の使い方でミスをするケースが非常に多い。例えば，プログ ラムの中で (setq x (nconc '(title =) y)) などとやると，プログラムの中の (title =) というリストの後ろに y の値がくっついてしまう。だからふたたびこの式を 評価すると，前回くっついたものの後ろにまた nconc することになる。プロ グラム中で quote されたリストもデータには代わりはないから要注意。 ------------------------- しかし、手元の処理系(emacs21, xyzzy)では、上の式は何度評価しても、x に は同じ(equalな)値がバインドされています。どんどん長くなったりしません。 私が勘違いしているのでしょうか？それとも、昔の処理系なら x はどんどん 長くなったのでしょうか？ 364 名前：ζ [2005/06/16(木) 12:21:12 ] こうゆーことが言いたいんじゃないのか？ (setq a "hi" ) => "hi" (setq a (nconc '(title =) a)) => (title = . "hi") => (title = title = . "hi") => (title = title = title = . "hi") => (title = title = title = title = . "hi") 365 名前：363 mailto:sage [2005/06/16(木) 12:37:21 ] ちょっと違うと思います。それだったら、nconc ではなく append でも同じで すから。 366 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 13:31:00 ] 評価するときに (setq x (nconc '(title =) y)) ってもう一度打ち込んでるとか。 そうすると '(title =) のリストが（多くの処理系では）再評価のたびに新しく作られる。 (defun f () (setq x (nconc '(title =) y))) のような関数を作って (f) を再評価してみては？ ちなみにANSI Common Lispの規定ではquote式のリストを書き換えることは禁止 になっていたと思う。 367 名前：364 mailto:sage [2005/06/16(木) 14:06:31 ] 当方の環境は emacs と xyzzy ですので、新たに手入力をしたりはしていませ ん。*scratch buffer* の同じ行で、C-j を繰り返しています。それでも x は 伸びないのです。 なお、念のため (defun f () (setq x (nconc '(title =) y))) も書いてみま したが、やはり emacs、xyzzy とも x が伸びたりはしません。 368 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 14:15:10 ] こうじゃないの？ (setq x '(1 2 3)) (nconc x '(4 5)) nconc を繰り返すと x は長くなっていく(@emacs21)。 369 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 14:15:44 ] >>367 ＞C-j を繰り返しています。 これはLispインタプリタ側から見たらテキストを再入力してるのと同じ。 内部的にはトップレベルの (read) がもう一回呼ばれるからね。 ところで y の値には何を入れて試してるの？ 370 名前：364 mailto:sage [2005/06/16(木) 14:36:05 ] (setq y 'hoge) としてから実行しています。ちなみに、先の関数 f をバイト コンパイルしても、やはり x は伸びません。 私の疑問をまとめますと、'(title =) を評価したら、それが再度の手入力で あれ、バイトコンパイル後の関数内であれ、毎回新たな cons セルが生成され るのが自然なのではないか、x が伸びるのはおかしいではないか、というもの です。 しかし、よく考えてみると、伸びないのが逆におかしいような気もします。混 乱してきました。 nconc に渡されるものの実体は何でしょうか？渡されるものがただの文字列で、 それを nconc が評価してリストを生成するなら、伸びないのが自然だし、渡 されるものが cons セルそのもので、その生成は最初にコードを書いたときに 行われるなら、伸びるのが当然のような気がします。 皆さんの処理系では、どうなるでしょうか？ 371 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 14:44:44 ] destructive か non-destructive の差だろ。 実装による。 372 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 14:48:44 ] >>370 '(title =)のセルが作られるのはトップレベルの内部で呼ばれるread関数の中。 エディタは文字列で持っているが、それがLispの世界に渡されるときにconsセル に変換される。君の場合はC-jを押したときに起こっているはず。 あとyの値がアトムでは面白いことは起きないだろ。 (setq y '(hoge)) (defun f () (setq x (nconc '(title =) y))) しておいて(f)を評価してみ。２回目の評価で凄いことが起きるぞ。ｗ 373 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 14:50:01 ] >>371 nconcがdestructiveでない実装ってある？ 374 名前：364 mailto:sage [2005/06/16(木) 16:39:48 ] 大変よく分かりました。ありがとうございます。というか、実に自分は分かっ てませんでした。 (setq y '(hoge); リストを入れる。 (f);　　　　　　評価にあたって、バイトコンパイルの必要はない。 =>(title = hoge) ; 1回目 =>(title = hoge hoge . #2) ; 2回目 =>無限ループ ;3回目...あわてて C-g で停止。 nconc は破壊的だから、同じリストを nconc で何度も結合すると、自己参照 が起きてしまうのですね。私のところで問題が起きなかったのは、一つはアト ムを nconc していたからなのですね。 まとめると、こんな感じでしょうか。 ・(setq x (nconc '(title =) y)) の評価は、これを素で評価するのと、関数 　に入れて評価するのとで、結果が違う。 ・(setq z '(title =)) として、(setq x (nconc z y)) を評価すると、素で 　評価しても、関数に入れても同じ結果になる。 ・だから、Common Lisp では、quote 式のリストに破壊的操作を行ってはなら 　ないことになっている。 375 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 18:54:46 ] 違う。それだと (setq x (nconc (list 'title '=) y)) でも同じだよね。 * '(a b c) のようなフォームはリテラルと呼ばれ、コンパイル時に作成される。 * だから (defun f () '(a b c)) の時、(eq (f) (f)) は真になる。 * もしここでリテラルの変更を許可してしまうと (f) => '(a b c) (nconc (f) '(d e f)) (f) => '(a b c d e f) となり、参照透過性が保てなくなる。 * また、コンパイラは同じ値のリテラルを同じオブジェクトにしてもかまわない。 (setq x '(a b c) y '(a b c)) において (eq x y) が真になってもかまわない ということ。そのような最適化をするコンパイラでは (setq x '(a b c) y (nconc '(a b c) '(d e f))) で x まで '(a b c d e f) になってしまう。 376 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 20:06:54 ] >>375 「コンパイル時に作成される」という言い方は抵抗あるなぁ。 基本的にはインタプリタでも事情は似たようなもんだから。 同一リテラルを再利用する最適化はread関数が行う可能性も あるし、もちろんコンパイラが行う可能性もある。 （実際にやる処理系は見たことないけど） 377 名前：363 mailto:sage [2005/06/16(木) 21:16:25 ] 興味深い、ありがとうございました。 しかし、後者の理由はわかりますが、前者の参照透過性については、副作用の ある関数も多いわけですから（カウントアップのクロージャとか）、純粋な関 数型言語でない LISP にとってそれほど重要なのか、よく分からないです。 あと、 (setq y '(hoge)) (defun f () (setq x (nconc (list 'title '=) y))) これだと、(f) を何度評価しても、結果は (title = hoge) なのですが。 378 名前：363 mailto:sage [2005/06/16(木) 21:17:16 ] あ、日本語がおかしい。「興味深いお話、ありがとうございます」でした。 379 名前：375 mailto:sage [2005/06/16(木) 22:16:50 ] >>376 インタプリタであっても、クロージャの作成等ある程度の変換処理が入るので、 そういった物も含めてコンパイラと書いたんだけど、 Common Lisp では 「コンパイラ」という用語は interpreted function を compiled function に 変換する機能として定義されてるからよくなかったね。 「処理系によって作成される」等に訂正。 ところで、read 関数が返すのは #n# 等の例外を除いて新規に割り当てられる ことが保証されてなかったっけ。reader の段階では '... を (quote ...) と 変換できることは知ってても (quote (a b c)) がリテラルであり再利用可能 であることは知らないはずだけど。 もし保証されてないとすると、prin1 で保存したデータを read して破壊的操 作してるコードを修正しないと。。。 >>377 一見参照透過に見えるのにそうでないのは混乱の元だってこと。 実際にはリテラルを直接返すのは呼び出し元の挙動に依存するので あまり好ましいやり方じゃないんだけどね。 あと、後半部についてはそのとおり。(setq x (nconc (list ... はまとめ の部分に対してのコメント。 380 名前：363 mailto:sage [2005/06/16(木) 23:07:13 ] なるほど、意図を逆だと勘違いしていました。すみません。 381 名前：デフォルトの名無しさん mailto:sage [2005/06/16(木) 23:26:37 ] すみませんが質問です。 Windows で Scheme を書いておられる方は、環境に何をお使いですか？Emacs の scheme-mode + run-scheme と似たような環境がほしいのです。 ・ChezEdit ... Shift + F2 で範囲選択した個所を評価・実行できるので、Emacs と 　かなり使い勝手は近い。しかし Petite Chez Scheme 専用。また Windows95 系の 　OS では動かない。 ・xyzzy ... scheme-mode はあるが、run-scheme はない。 ・Meadow ... 使ったことないけれど、run-scheme は Gauche ではうまく動かない 　らしい。 ・Dr.Scheme ... MzScheme 専用。英語なので使い方がよく分からない。

---

---

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

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