Lisp Scheme Part22
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2008/05/21(水) 23:58:40Part21: ttp://pc11.2ch.net/test/read.html/tech/1207300697/
Part20: ttp://pc11.2ch.net/test/read.cgi/tech/1205021786/
Part19: ttp://pc11.2ch.net/test/read.cgi/tech/1200237296/
Part18: ttp://pc11.2ch.net/test/read.cgi/tech/1186922295/
Part17: ttp://pc11.2ch.net/test/read.cgi/tech/1177065699/
Part16: ttp://pc11.2ch.net/test/read.cgi/tech/1172404795/
Part15: ttp://pc10.2ch.net/test/read.cgi/tech/1151025773/
Part14: ttp://pc8.2ch.net/test/read.cgi/tech/1132275726/
Part13: ttp://pc8.2ch.net/test/read.cgi/tech/1115901841/
Part12: ttp://pc8.2ch.net/test/read.cgi/tech/1100229366/
Part11: ttp://pc5.2ch.net/test/read.cgi/tech/1091456033/
Part10: ttp://pc5.2ch.net/test/read.cgi/tech/1075630259/
Part9: ttp://pc2.2ch.net/test/read.cgi/tech/1069594582/
Part8: ttp://pc5.2ch.net/tech/kako/1058/10582/1058263391.html
Part7: ttp://pc5.2ch.net/tech/kako/1042/10421/1042167213.html
Part6: ttp://pc3.2ch.net/tech/kako/1031/10315/1031560687.html
Part5: ttp://pc3.2ch.net/tech/kako/1023/10230/1023091882.html
Part4: ttp://pc.2ch.net/tech/kako/1016/10162/1016211619.html
Part3: ttp://pc.2ch.net/tech/kako/1008/10082/1008220265.html
Part2: ttp://pc.2ch.net/tech/kako/1002/10025/1002584344.html
Part1: ttp://piza2.2ch.net/tech/kako/987/987169286.html
0153デフォルトの名無しさん
2008/05/27(火) 00:33:27>>140の「そういえば」はどこに掛かるんだよ。酔っ払いか？
で？間接参照で遅くなるから何すか？
0154デフォルトの名無しさん
2008/05/27(火) 05:10:09特定の二人だけであまりに必死な会話を展開してるときは
そう言いたくなることもある。たまに。
0155デフォルトの名無しさん
2008/05/27(火) 05:14:49元の書き込みも１Ｋワードのマシンじゃforthだって書いてるじゃん（っていうか他に選択肢あるのか1Kで）
0156デフォルトの名無しさん
2008/05/27(火) 07:22:55lispスレに何の御用ですか？
0157デフォルトの名無しさん
2008/05/27(火) 07:48:17単に頭が悪いキャラなのは勘弁して欲しいなぁ
0158デフォルトの名無しさん
2008/05/27(火) 07:51:530159デフォルトの名無しさん
2008/05/27(火) 08:30:20使った人いる？
0160デフォルトの名無しさん
2008/05/27(火) 12:07:40メモリ以上に食って終わらなくなるのですが。
(define add1
(lambda (n)
(+ n 1)))
(define A
(lambda (n m)
(cond
((zero? n) (add1 m))
((zero? m) (A (sub1 n) 1))
(else (A (sub1 n)
(A n (sub1 m)))))))
0161デフォルトの名無しさん
2008/05/27(火) 12:11:480163163
2008/05/27(火) 12:34:360164へだま ◆7JLFh7E/wI
2008/05/27(火) 12:34:56ttp://mathworld.wolfram.com/AckermannFunction.html
このへんの記事が御参考になればよいのですが
0165デフォルトの名無しさん
2008/05/27(火) 12:42:26どうもです。
0166デフォルトの名無しさん
2008/05/27(火) 13:48:490167デフォルトの名無しさん
2008/05/27(火) 16:17:250168デフォルトの名無しさん
2008/05/27(火) 17:46:00Pointer(Address Reg)のサイズが 16bits って 8BitsMPU とかだよね？ メモリー空間が64Kの世界かぁ。うむむ。
0169デフォルトの名無しさん
2008/05/27(火) 18:35:29たまには8086も思い出してください（個人的には嫌いだがw）
0170デフォルトの名無しさん
2008/05/27(火) 19:02:480171デフォルトの名無しさん
2008/05/28(水) 07:53:43#!E:/Gauche/bin/gosh.exe
(display "Content-Type: text/plain;\n\nHello, Gauche!\n")
と書くとInternalServerErrorが出ます。
goshのパス自体はこれで正しいのですが、何かやり方を間違っている所があるでしょうか？
初心者質問ですいません。
0172デフォルトの名無しさん
2008/05/28(水) 08:05:14まずHTTPサーバのログを確認。
つぎにコマンドプロンプトで
C:\foo> E:\Gauche\bin\gosh.exe bar.cgi
とかやってみる。これで動くなら設定が悪い。
0173デフォルトの名無しさん
2008/05/28(水) 10:41:42サーバーのログ見たら
Premature end of script headers: mb.cgi
*** ERROR: cannot find file "./D:/ws/hp/scheme/mb.cgi" to load
との事。
プログラムのあるフォルダで、コマンドプロンプトで動作させたときはきちんと動きますが
gosh "プログラムの絶対パス"
とすると同じエラーが返るのでこれが原因のようです。
もうちょっと頑張らないと…
0174デフォルトの名無しさん
2008/05/28(水) 11:04:50goshの引数で「-l」付けたら行けました
ご助言ありがとうございます。
#!E:/Gauche/bin/gosh.exe -l
(display "Content-Type: text/plain;\n\nHello, Gauche!\n")
0175デフォルトの名無しさん
2008/05/28(水) 21:10:25ttp://cadr.g.hatena.ne.jp/g000001/?word=*%5BLisp%E3%83%9E%E3%82%B7%E3%83%B3%5D
0176デフォルトの名無しさん
2008/05/28(水) 21:16:53ttp://victor.se/bjorn/lispm.php
0177デフォルトの名無しさん
2008/05/28(水) 21:28:420178デフォルトの名無しさん
2008/05/28(水) 21:32:51ttp://www.bitsavers.org/pdf/ti/explorer/
0179デフォルトの名無しさん
2008/05/28(水) 21:39:310180デフォルトの名無しさん
2008/05/29(木) 00:27:160181デフォルトの名無しさん
2008/05/29(木) 12:32:08ICOTはKL1 UNIX版その他を公開したから、
まだ研究が続いているものもあるのにねえ
http://www.icot.or.jp/ARCHIVE/Museum/IFS/about-IFS-J.html
NTTは今や私企業だから難しいかね
0182デフォルトの名無しさん
2008/05/29(木) 18:39:36というか、正式に依頼するなり手順踏めば手に入るものだよ。
0183デフォルトの名無しさん
2008/05/29(木) 20:46:09case-Aは常に同じ状態からのcontinuation再開となるのに対し，
case-Bは前回の結果を反映したcontinuation再開となります．
continuationが生成されたときの状態をそのまま保存したものであり
continuationが呼び出されるとその状態が復元されて続きの評価が行われる
という理解からするとcase-Bの結果が理解できません．
前回のcontinuation呼び出しの影響はどこに記録されるのでしょうか．
0184183
2008/05/29(木) 20:46:54(define continuation #f)
(let loop ((counter 0))
(write counter)
(if (< counter 3)
(begin
(if (= counter 1)
(call-with-current-continuation
(lambda (k) (set! continuation k))))
(loop (+ counter 1))) ;;ここが違う
'finished)) ;==> 0123finished
(continuation #t) ;==> 23finished
(continuation #t) ;==> 23finished
(continuation #t) ;==> 23finished
0185183
2008/05/29(木) 20:47:30(define continuation #f)
(let loop ((counter 0))
(write counter)
(if (< counter 3)
(begin
(if (= counter 1)
(call-with-current-continuation
(lambda (k) (set! continuation k))))
(set! counter (+ counter 1)) ;;ここが違う
(loop counter)) ;;ここが違う
'finished)) ;==> 0123finished
0186183
2008/05/29(木) 20:49:13[case-Bの続き]
(continuation #t) ;==> 3finished
(continuation #t) ;==> 4finished
(continuation #t) ;==> 5finished
0187デフォルトの名無しさん
2008/05/29(木) 21:18:32case-Bの場合で説明すると、continuationはcounterが記録されている位置だけを覚えていて、その値を覚えているわけではない。
なのでset!をすると次回は前回にセットされた値が読み出されるのでそのようになる。
って感じでいいのかな？
0188デフォルトの名無しさん
2008/05/29(木) 21:23:58MLをちょろっと勉強して、Schemeの破壊的に変更する変数は
MLではセルになるんだと考えれば理解が早いと思う。
0189デフォルトの名無しさん
2008/05/29(木) 21:33:32ちゃんと帰ってきてくれよな！
ラムダの門が君を待ってるよ〜（w
0190デフォルトの名無しさん
2008/05/29(木) 21:35:21C言語を学んでスタックフレームを理解すれば早いという説もある。
0191デフォルトの名無しさん
2008/05/29(木) 21:56:00保存した状態（つまりクロージャ）をスタックしてバックトラックする例を勉強すればどこが違うか理解できるだろう。
非決定性とか論理プログラミングを探して読んでみると良いと思う。
0192183
2008/05/29(木) 22:27:39なるほど．言葉の使いかたが間違っているかもしれませんが，まとめると，
「変数の束縛関係はどこかにあるsymbol-tableに記録されているが，
『continuationは，生成時のsymbol-tableをdeep-copyしたものを保持するわけではなく
単にそのsymbol-tableへの参照を保持するだけである』」
と考えてよろしいでしょうか．
だからcontinuation生成後にそのsymbol-tableに変更が加えられると，
continuation呼び出し時には変更分が反映されている，と．
0193デフォルトの名無しさん
2008/05/29(木) 22:31:22symbol-tableって言い方は誤解を招くけど、大筋はそんなもんかな
0194デフォルトの名無しさん
2008/05/29(木) 22:40:150195デフォルトの名無しさん
2008/05/29(木) 23:11:27明日役に立つのはrubyやpythonだけど
数年後に役に立ってくれるんだろうか
0196デフォルトの名無しさん
2008/05/29(木) 23:19:58(define continuation #f)
(let loop ((counter 1))
(if (< counter 2)
(begin
(if (= counter 1)
(call-with-current-continuation
(lambda (k) (set! continuation k))))
(write counter) (newline)
(loop (+ counter 1)))
'finished)) ;==> 1finished
(continuation #t) ;==> 1finished
(continuation #t) ;==> 1finished
(continuation #t) ;==> 1finished
0197デフォルトの名無しさん
2008/05/29(木) 23:20:34(define continuation #f)
(let loop ((counter 1))
(if (< counter 2)
(begin
(if (= counter 1)
(call-with-current-continuation
(lambda (k) (set! continuation k))))
(write counter) (newline)
(set! counter (+ counter 1))
(loop counter))
'finished)) ;==> 1finished
(continuation #t) ;==> 2finished
(continuation #t) ;==> 3finished
(continuation #t) ;==> 4finished
0198デフォルトの名無しさん
2008/05/29(木) 23:21:15面白そうなのにもったいないよね。
0199183
2008/05/29(木) 23:22:21厳しいご指摘もないようですので>>192で考えてみます．
どうもありがとうございました．またよろしくお願いします．
0200デフォルトの名無しさん
2008/05/29(木) 23:23:34なぜ末尾コンテクストじゃなくても
末尾呼び出しされるんだろう。
普通の関数と同じ扱いにすれば
参照透明性も損なわれないような気がする。
深く考えてないけど。
0201デフォルトの名無しさん
2008/05/30(金) 00:05:48symbol-table → binding
0202デフォルトの名無しさん
2008/05/30(金) 00:06:59帰ってくるのかよ！
0203デフォルトの名無しさん
2008/05/30(金) 00:11:35帰還方法を（継続として）渡すような双方向継続フレームワークを作るのが良かろう
0204デフォルトの名無しさん
2008/05/30(金) 00:20:42「束縛関係(binding)を記録している所」なら「環境(environment)」なんじゃね？
0205デフォルトの名無しさん
2008/05/30(金) 00:26:38環境というとフラットな印象だなあ。（グローバルみたいな）
スタック状に積み重なってるイメージは束縛のほうかな。
0206デフォルトの名無しさん
2008/05/30(金) 00:32:47「環境(environment)」=「クロージャ」
0207デフォルトの名無しさん
2008/05/30(金) 00:50:22おいおい、大事なものが抜けてないか〜
それじゃ仕事になんないよ（w
0208デフォルトの名無しさん
2008/05/30(金) 06:46:31それは「環境」に対して持ってるイメージが狭すぎるよ。
SECDのEはenvironmentのEだぜ。
0209183
2008/05/30(金) 10:41:05語弊があるかもしれませんが，変数の束縛関係が登録されている場所のことを「symbol-table」ということにします．
symbol-table が何枚も重なって，scope 全体の階層構造を表現しているとします．
昨日お教えいただいた「continuation は，自分が生成されたときの symbol-table への『参照』を持っている」という理解だと，
今度は >>196 の挙動が理解できません．
(>>183 の「symbol-tableの『deep-copy』を持っている」という私の最初の理解だと，>>197 の挙動が理解できませんでした．)
ここで生成される continuation が参照しているのは，let がつくる「top-level よりも 1 レベル深い symbol-table」だと思います．
>>196 の場合，末尾再帰の際に (+ counter 1) が評価されて，その結果の 2 が新たな counter の束縛値としてこの symbol-table
に書き込まれ，その後に let の本体が評価されますよね？
そうすると，loop の引数として (+ counter 1) を渡す >>196 も，set! で直接 symbol-table に束縛関係を書き込む >>197 も，
どちらも同じ >>197 のような結果を示すはずだと思うのです．なぜ >>196 が counter の最初の束縛値 1 を覚えているのでしょうか．
>>196 と >>197 の違いはどこにあるのでしょう？まさにそれがこの 2 つのコードを書いてみた動機だったのですが…
(多分 >>196 の評価過程をどこか間違えて理解しているのだと思います)
0210デフォルトの名無しさん
2008/05/30(金) 11:54:43この例だと、 (loop (+ counter 1)) を評価するたびに、 counter の値が違う symbol-table が作られる。
だから、継続に戻ると、元の symbol-table がそのまま残ってる。
0211183
2008/05/30(金) 12:18:01実はそれも考えましたが，この場合そうあるべきではないと思うのです．
loop を呼び出すたびに新たな symbol-table を作るとなると，末尾再帰呼び出しの回数が
大きくなるにつれて symbol-table の枚数が増え続けることになり，それを表現する stack
がどんどん伸びてしまいませんか？
これは「末尾再帰処理」の「余計なメモリ消費を行わずに繰り返しを表現する」という掟に
反するように思うのですが…
これが末尾再帰でなく通常の関数呼び出しなら >>210 さんのおっしゃる挙動で理解できます．
0212デフォルトの名無しさん
2008/05/30(金) 12:33:04もしかしたら「末尾呼び出しはジャンプに最適化される」とあちこちに書いてあるから、loopの呼び出しがジャンプになるならcounterが上書きされると思ったのかもしれないけど・・・
schemeレベルからはそう見えることはないです。
ではどうやって末尾再帰呼び出しの保証をしているのかなのですが・・・時間が無いのでだれか書かない？
0213デフォルトの名無しさん
2008/05/30(金) 12:59:06普通に再帰呼び出ししてると考えたほうが判りやすいのではないかな。
0214デフォルトの名無しさん
2008/05/30(金) 13:08:16積まれた引数を移動させるコストが発生する。
コンパイラがフロー解析していたり、単純な呼び出しならば
直接不要になった変数を破壊する書き換えが行われる場合がある。
それと、コンパイルされれば局所変数は相対位置で参照されるので
通常は名前なんかはスタック上に保持していない。
つまりsymbol-tableという言い方はおかしい。
0215デフォルトの名無しさん
2008/05/30(金) 15:20:37スタックというと「ひとつしかない」「配列」を思い浮かべるかもしれないが、
概念的にはヒープ上のリストと同じように扱えるものと考えたほうがいい。
0216デフォルトの名無しさん
2008/05/30(金) 16:05:16>>215
がいいこと言った！
というわけで、誘導しようと思ったらリンクが無かったわ＾＾；
Three Implementation Models for Scheme
ttp://www.cs.indiana.edu/~dyb/pubs/3imp.pdf
久しぶりにラムダの門磨いときますね（w
0217デフォルトの名無しさん
2008/05/30(金) 21:19:30Schemeの識別子はC言語などと一緒で
式ではなく記憶領域の場所に束縛される。
末尾再帰の最適化に関しては
スタックフレームの参照で考えると
A→B→C ;;普通の関数呼び出しのスタックフレームの参照連鎖
A→ →C ;;末尾呼び出しの場合はAとCを直接つないじゃえ、どうせCから値を直接返そうがBが値を返そうがプログラマから見れば同じだし
B
A→C ;;Bはどのスタックフレームからも参照されてないのでGCに回収されました
ってな感じで定数空間で末尾再帰されてると考えてもいいかも。
実際の処理系はもっと効率よくやってるはずだけど。
0218デフォルトの名無しさん
2008/05/30(金) 23:15:06> それを表現する stack がどんどん伸びてしまいませんか？
末尾再帰の場合はそうせずに済むってことだよ。
0219デフォルトの名無しさん
2008/05/30(金) 23:17:44良い説明だと思う。
こういう風にきちんと考えないと、継続が絡んだときの挙動を説明できないんじゃないかな。
0220183
2008/05/30(金) 23:27:08末尾再帰呼び出しについて >>217 さんのご説明が私のイメージにいちばん近くわかりやすいです．
この例で，C の呼び出しは実際には A を呼び出しているわけで，>>214 さんのいわれるような
「末尾コンテキストでの呼び出し(C)は、実際には(Cの)スタックフレームに積まれた引数を(Aに)移動させる」
処理が起きるわけですよね．
問題は，この中に continuation が混在していることなのですが，この図に continuation の
スタックフレームへの参照を追加するとどのような図になるのでしょうか．
再帰呼び出しの中で，どのようにすれば continuation が「正しい」scope を持ち続けることが
できるのかということなのですが…
0221デフォルトの名無しさん
2008/05/31(土) 00:11:22だから再帰などで同じ手続きが呼ばれてもそれぞれの変数の束縛（アドレス）はユニーク。
λ式中の自由識別子はそのλ式がevalされ（て手続きが生成され）た時に可視な束縛（ポインタ）が参照される。
だから再帰などで同じ手続きがよばれても同一の場所（アドレス）を参照する。
call/ccが引数の手続きに渡す継続は
case-Aの場合は(lambda (x) (write counter) (newline) (loop (+ counter 1)))
case-Bの場合は(lambda (x) (write counter) (newline) (set! counter (+ counter 1)) (loop counter))
この中に現れている自由識別子（というか束縛識別子は参照されてないけど）は何度呼ばれても同一の場所を参照する。
case-Bの場合はset!でcounterが束縛されているメモリの値を書き換えてるから
書き換えられた値を参照している。
ここで(loop (+ counter 1))は手続き呼び出しだから(loop 3)等の値に評価されてから手続きに渡されている事に留意。
そして1回目のloopのcounterと2回目のloopのcounterは同一でない場所を参照してる。（スタックフレームの再利用などの最適化されていなければ）
0222デフォルトの名無しさん
2008/05/31(土) 00:15:27手続きと実体は一緒だから同じように考えればOK
0223デフォルトの名無しさん
2008/05/31(土) 00:16:190224204
2008/05/31(土) 00:35:20末尾再帰や継続を勉強する前にせめてschemeの評価モデルの勉強をすべきだと思うんだ
まず「環境フレームモデル」について勉強することをお勧めするよ
0225デフォルトの名無しさん
2008/05/31(土) 00:50:58そういう意味じゃ>>183にとってGauche本は良書じゃなかろうか?
0226デフォルトの名無しさん
2008/05/31(土) 01:37:50説明してみます。
C1はcounterが1の束縛、C2はcounterが2の束縛だとすると、
最初にnamed letに入ったときはスタックは
C1
ここでcontinuationをセーブしている。
loopを呼び出すと
C1->C2
の状態になる。
で、ifからfinishで抜けている。スタックは空。
"空"
(continuation #t)を評価すると、スタックは先にセーブした
C1
の状態になって(call/cc ...)の次の式から評価が開始される。
続く
0227デフォルトの名無しさん
2008/05/31(土) 01:38:23そこからloopが再び呼び出されると
C1->C2'
の状態となる。ここで先のC2とC2'になる。
さてC1がどこに記録されているかだけど、これはcontinuationにぶら下がる形でヒープに保管するのが簡単な実装方法。
ところでloopは末尾再帰呼び出しなので、C1->C2やC1->C2'になるところでC1を潰してC2やC2'で上書きしてしまいそうなのだが、
これは実装がC1が破壊できないことを知っているので行われない。
これはC1がヒープに保管されているかどうかで判定するのが簡単な実装方法になる。
(continuation #t)の#tはどこにいくのか？
C1->C2'の途中に#tを持った束縛ができないか心配になるけど、この#tは(call/cc ...)の帰り値となって、スタックから取り去られることになる。
う〜ん、どうだろうか？
0228デフォルトの名無しさん
2008/05/31(土) 01:42:53「の状態となる。ここで先のC2とC2'になる。」
は
「の状態となる。ここで先のC2とこのC2'は違う束縛になる。」
のつもり。m(_ _)m
0229183
2008/05/31(土) 01:52:17>>221 さんのご説明が具体的で核心をついた答そのものだと思います．
さらに >>226 - >> 228 さんのご説明は >>217 さんの例に則していて
わかりやすそうです．
少し時間がかかると思いますが処理をなぞって考えさせていただきます．
0230デフォルトの名無しさん
2008/05/31(土) 11:55:56(1) upward onlyの継続 (例外はこれで可能)
(2) 一回使ったらおしまいの継続 (コルーチンはこれで可能)
(3) 汎用的な継続
0231デフォルトの名無しさん
2008/05/31(土) 11:57:340232デフォルトの名無しさん
2008/05/31(土) 12:15:11(1) ひとつしかないスタックを破壊的に変更しながら使う
(2) いくつかのスタックを破壊的に変更しながら使う
(3-a) スタックを退避したりリストアしたり
(3-b) immutableパターン
0233183
2008/05/31(土) 12:52:01基本的な規則は
・closure が呼び出されれば(たとえそれが末尾再帰呼び出しであっても)，
新たな束縛環境が作られ，その環境に視点が切り替えられていく．
・continuation には，自分が生成されたときの束縛環境への参照が保持されている．
・通常処理を続けている間は，末尾再帰呼び出しに伴い次々と生成されて
切り替えられる束縛環境をもとに評価が進められるのだが，
ひとたび continuation が呼び出されると，その continuation 上に保持されていた
束縛環境に視点が切り替えられる．
であり，これらに従って評価を繰り返していけば case-A と case-B の挙動の違いを
説明できるように思います．
みなさんのご説明以上の内容ではありませんが，最初のルールを充分にわかっていなかった
(つまり，末尾再帰呼び出しの場合，同じ束縛環境のまま束縛関係を上書きしてしまうと考えていた)
ことが混乱の原因であったように思います．
まだ理解が不充分だと思いますが，少しだけわかりかけてきた気がします．
0234デフォルトの名無しさん
2008/05/31(土) 14:41:090235デフォルトの名無しさん
2008/05/31(土) 14:51:28本気で面白いと思って書き込んだのでないなら少し反省してもらおうか。
0236デフォルトの名無しさん
2008/05/31(土) 15:45:470237デフォルトの名無しさん
2008/05/31(土) 15:49:470238デフォルトの名無しさん
2008/05/31(土) 18:10:23もうしばらく静かにしておいてやれYO！
0239デフォルトの名無しさん
2008/05/31(土) 21:55:26(lambda (a lat)
(cond
((null? lat) #f)
((eq? a (car lat)) #t)
(else (member? a (cdr lat))))))
(member? 'sardines '(Italian sardines spaghetti parsley))
0240デフォルトの名無しさん
2008/05/31(土) 21:56:04(lambda (set1 set2)
(letrec
((I (lambda (set)
(cond
((null? set) '())
((member? (car set) set2)
(cons (car set)
(I (cdr set))))
(else (I (cdr set)))))))
(I set1))))
(intersect '(tomatoes and macaroni) '(macaroni and cheese))
0241デフォルトの名無しさん
2008/05/31(土) 21:57:19; (1) upward onlyの継続 (例外はこれで可能)
(define intersectall
(lambda (lset)
(let/cc hop
(letrec
((A (lambda (lset)
(cond
((null? (car lset))
(hop '()))
((null? (cdr lset))
(car lset))
(else
(intersect (car lset)
(A (cdr lset))))))))
(cond
((null? lset) `())
(else (A lset)))))))
(intersectall '((tomatoes and macaroni) (macaroni and cheese) (tomatoes and cheese)))
0242デフォルトの名無しさん
2008/05/31(土) 22:52:40(lambda (a lat)
(let/cc skip
(letrec
((R (lambda (lat)
(cond
((null? lat) '())
((eq? (car lat) a)
(skip (R (cdr lat))))
(else (cons (car lat) (R (cdr lat))))))))
(R lat)))))
(rember-upto-last
'cookies
'(cookies chocolate mints caramel delight ginger snaps sesserts chocolate mousse
vanilla ice cream German chocolate cake more cookies gingerbreadman chocolate chip brownies))
0243デフォルトの名無しさん
2008/06/01(日) 00:18:03>>241-242ではlet/ccと書いてある。（Seasoned Schemerからの例）
0244デフォルトの名無しさん
2008/06/01(日) 00:22:49「う〜ん、それならこれで十分なんじゃな〜い」ってきっと言われる・・・
(define rember-upto-last
(lambda (a lat)
(let loop ((ans lat) (lst lat))
(cond ((null? lst) ans)
((eq? (car lst) a) (loop (cdr lst) (cdr lst)))
(else (loop ans (cdr lst)))))))
(define intersectall
(lambda (lset)
(fold intersect (car lset) (cdr lset))))
なんか簡潔で説得力のある一級継続の使用例は無いものだろうか・・・
0245デフォルトの名無しさん
2008/06/01(日) 00:55:50継続の動作の仕組みを調べる材料に使うなら>>239-242は十分な例だと思う。
継続を理解することよりも何かに例えることに力点があるうちは理解できないだろう。
0246デフォルトの名無しさん
2008/06/01(日) 01:28:21(lambda (goto)
(letrec ((start
(lambda ()
(print "start")
(goto next)))
(froz
(lambda ()
(print "froz")
(goto last)))
(next
(lambda ()
(print "next")
(goto froz)))
(last
(lambda ()
(print "last")
(+ 3 4))))
start))))
0247デフォルトの名無しさん
2008/06/01(日) 01:29:020248デフォルトの名無しさん
2008/06/01(日) 01:29:09(call/cc (lambda (bar) bar))))
(yang ((lambda (foo) (write-char #\*) foo)
(call/cc (lambda (bar) bar)))))
(yin yang))
0249デフォルトの名無しさん
2008/06/01(日) 01:29:330250デフォルトの名無しさん
2008/06/01(日) 01:30:21そのレベルでやってるやつには不要。
0251デフォルトの名無しさん
2008/06/01(日) 01:33:52ｸﾚｸﾚうるせーんだよ。氏ね。
0252デフォルトの名無しさん
2008/06/01(日) 01:50:09■ このスレッドは過去ログ倉庫に格納されています