Lisp Scheme Part40 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>166
試した処理系は何? それは仕様上未定義だよ。
期待した動作をするように見えてもただの偶然。 全部(lambda()〜)で囲って遅延評価すればなんでもできるよ
SICPでマクロが無くても問題なかったのはこのおかげ >>167
gaucheっす。r[567]rsによると、my_or1はこう呼ぶべしと理解したけど、あってます?
(define my_or1 (syntax-rules () ((_ a b) (or a b))))
(let-syntax ((my_or1 my_or1)) (my_or1 #t (error "!!")))
変数と構文キーワードを区別しなきゃならない理由が、いまいちピンときません。
フォームの先頭が(lambda)を評価したものと(syntax-rules)を評価したもので
区別出来そうな気がします。(実際Gaucheはそうしてるから>>166で動いてる?) >>169
構文は第一級ではない。 (実行時に値として扱える存在ではない。)
「マクロ展開フェイズ」が完了してから「式の評価」を開始するので、実行時に束縛するのでは遅すぎるんだよ。
式ひとつごとに「展開」「評価」をする処理系でフェイズの分離を有耶無耶にしている処理系だと区別を曖昧にしてもなんとかなるのかもしれないが……
それは実装方針のひとつとしてそういうのもありえる、可能というだけ。 >>170
>構文は第一級ではない。 (実行時に値として扱える存在ではない。)
なるほど、疑問氷解です。 .oO( The Little Prover を読んだ香具師がスレの流れを作ってくれる予感 ) なぜ自由なlispより不自由なjavascriptが流行ったのか ウェブブラウザから使えるのが lisp だったら流行ったんじゃないの?
とはいえそこに lisp が採用されない理由も結局は一緒か。 IE4やNN4で実装されたスクリプト言語がLISP系だったら…
少なくともfirefoxのnoscriptアドオンは不要だったろうな 逆に考えるんだ、
「lisp でWebブラウザを作ればいいや」
と考えるんだ WebAssembly が一般的になれば Lisp にもワンチャンあるで Javaがダメ言語とあの時点で判明してればなあ。
当初の予定通りschemeが組み込まれてたに違いない。 emacs で Webブラウジングが出来るんじゃ無かったか。 技術系のドキュメントとかあまり凝った事してないものしかまともに見れんよ。 Emacs に Webkit 載せたりしてるのもあったぞ。
Emacs 側から Webkit をどれくらい操作できるのかは知らんけど。 ブラウザ競争っていかにCSSに意図通り対応してるかの勝負だし
サーバサイドならemacsでもjavaでも変わらん いや javascript が動かないと。
ああ、其処を lisp にするって話だったか。 いまだに、javascript が scheme だということについて納得できない 第一級の継続も末尾呼び出しの最適化もないしねぇ
手続きが無条件でクロージャになるってのがまあ当時としては特徴的ではあったけども CLみたいな余計な装飾子が無いところはschemeと考え方が近い
末尾最適化が標準のluaのがよりschemeに近い
継続は第一級にする必要ってあんのかな
使い所が難しいし言語に例外機構が備わってればいらないし
jsはライブラリ覚えるだけでもしんどい 今JSがコールバック地獄になってるからこそ継続がほしいんじゃん。フル継続じゃなくて限定継続でもいいから。 javascriptのように通信が頻繁に行われる環境で継続なんか入れたときに、例えば途中でブラウザを切ったときの継続がどうなってるのか考えるとワケ分からなくなる
schemeの継続ですら、資源を使いまくってるサーバが落ちたときにリソースのclose操作とかきちんと行われるのか不安になる >>188
jsはクロージャがあるからCPS方式で継続もどきは作れるんじゃないの
インスタンスが途切れちゃうなら継続使っても同じだし JavaScript 処理系の Rhino は第一級継続を持ってる。 実在する以上、言語処理系レベルでは可能ってことだろ。
だけど、 Scheme 処理系でも外部のライブラリ (バインディングとか) を通過したところで継続が途切れてしまう制限を持っているものがあることからもわかるように、
継続が処理系の外の世界をまたぐのは難しいんだわ。
(※参考 Gauche のドキュメント http://practical-scheme.net/gauche/man/?l=jp&p=call/cc )
JavaScript はアプリケーションに組込んで使うタイプの言語だから、当然、外の世界とのやり取りはあたりまえで、
そこに第一級継続を持ち込んでも途切れまくりであんまり役に立たんのじゃないか?
Gauche のドキュメントには限定継続の利用を勧めるようなことも書いてあるけど、
フル継続で途切れてしまうところを越えられるって意味ではなくて、
継続の範囲を明確に書けるから変なところをまたがないように注意しやすいって意味だと思う。 そういやGNU標準言語?だかのはずのguileって使われてるんだろうか GNU自体微妙な団体だし
そんな団体の標準になられても気持ち悪い guile って死んでると思ったけど、
結構頑張ってんよ unicodeサポートが微妙だったのはもう昔の話なのかな?なんかそれで使うのやめた事がある アプリケーションに組込むなら小さい実装の方がいいよな。 Guile は豪華すぎると思う。
かといってリッチな実装というカテゴリだと Racket が強いから Guile は微妙ということに……。
Guile の強みって何? javascriptでscheme組もうと思う
クロージャあるし継続なしで末尾再帰ぐらいなら結構楽勝かな racket で raco を使って exe 化したらやたらサイズがデカいのが出来たんだけど、
もっと小さくできないものなん? 自作処理系だと4KBセクタに収まるようにできる
512バイトブロック単位だが
けどschemeコアも含めたりすると結局数十KBにはなる
イメージまるごとexeにするタイプなら
参照切りまくれば小さくなるんじゃないの 初めまして。
早速ですが教えて下さい。
下のcall/ccの定義を解説できますか?
(define call/cc
(lambda (k f)
(f k (lambda (dummy-k result)
(k result))))) 例えば RnRS の call/cc を使ってこういうのを書いたとする。
(define (foo x)
(+ 3
(call/cc
(lambda(cc)
(if (> x 3) (cc (+ x 1)) x)))))
(display (foo 1)) (display (foo 5))
継続とは何かというのを綺麗に説明するのは難しいけど、
「残りの計算」という言葉で説明するのが一般的だね。
この例でいえば call/cc を呼出された後にするはずの計算、
すなわち「 (+ 3 」が変数 cc に入っている継続。
call/cc を呼出している外側全てと言い換えてもいいかもしれない。
(字句上の外側ではなくて実行時の外側。)
で、 >>209 の言うところの call/cc (名前がまぎらわしいから
ここでは call/cc* と変える) は残りの計算を陽に引数として
渡すバージョンということだと思う。
最初の例を call/cc* で書き直すと
(define (foo* x)
(call/cc*
(lambda(x)(+ 3 x))
(lambda(cc f)
(if (> x 3) (cc (+ x 1)) (f cc x)))))
(display (foo* 1)) (display (foo* 5))
となる。
「(+ 3」の計算を (lambda(x)(+ 3 x)) というクロージャにして渡しているのが
わかるかな。 >(+ 3 (call/ccc
式中の副作用(call/cc)は評価順序不定の罠が
判ってると思うけど一応 ついでにこの式の評価順序ってR6RS以降で何か変わったのかなーと思って調べたら変わってないっぽいね
式を多用するlisp族ではついつい書いてしまうからどっちかに決めた方がいいと思うんだけどな
継続は一見副作用に見えなかったりするからややこしい
そういや評価順の問題ってトップレベルにもあったなあ 横から初心者が何だけど、
>>209の定義のdummy-kって別に無くてもよさそうなんだけど、何か必要な理由って有るのかな? >>210
その例だと継続使っても使わなくても結果が変わらないので微妙。
fを適用する先も間違ってるし。
こんな感じでどうでしょう。
(define (foo x)
(call/cc
(lambda(cc)
(+ 3
(if (> x 3) (cc (+ x 1)) x)))))
(define (foo* x)
(call/cc*
(lambda (x) x)
(lambda (cc f)
(let ((ncc (lambda (x) (cc (+ 3 x)))))
(if (> x 3) (f ncc (+ x 1)) (ncc x)))))) 連投すまぬ。
引数の名前がきちんと対応していなかったのでfoo*を書きなおした。
(define (foo* x)
(call/cc*
(lambda (x) x)
(lambda (f cc)
(let ((g (lambda (x) (f (+ 3 x)))))
(if (> x 3) (cc g (+ x 1)) (g x)))))) >>215なら素直に理解できた
要するに、これは継続渡しのスタイルの中で使えるcall/ccってことか
あと、さっきの例をちょっといじって
(define (foo& x k)
(call/cc*
k
(lambda (f cc)
(let ((g (lambda (x) (f (+ 3 x)))))
(if (> x 3) (cc g x) (g x))))))
(foo& 1 (lambda (x) (display x)))
としたほうがわかりやすいかもしれない LFE(lisp flavor erlang)使ったことあるかたいますか?
どの辺が問題なんでしょうか。
バックエンドがerlangというのは大きいメリットだと考えるんですが。 >>217
使われない理由っていうことでいうと、↓のような感じかな。
読み直したら全面的にdisってるが、おもちゃとしては面白いと思ってる
・開発リソースが少ないのでおもちゃの域を出ない
特に、Common LispもしくはClojureを置き換えるほどのライブラリ・
成熟度・勢いは無い。
・そんなに速くない
・Erlang/BEAM自体の需要が少ない
Erlangスレでも書いたことがあるんだが、開発の現場でErlangを本当に必要とする
場面というのは少ない。良くも悪くもフォーカスを絞った言語だから。
エラー処理が楽とかいう人も多いが、乗り換えるほど大きなメリットでは無い
また、現実問題として、システム全部をBEAM上に載せる必要は無い。
一部だけErlangで書けば良いし、そのために
微妙な成熟度の微妙なLisp方言を入れる必要性ってあんまり感じられない
なお、Elixirで騒いでいる人たちも、Erlang系だからってよりはRubyっぽい
関数型言語っていう表面的な特徴で一時的に騒いでいる人の方が多い
・名前がダサい。これは馬鹿にできない >・そんなに速くない
これはBEAM特有の問題なんだよね、数値計算がちょっとでもはいるととても遅い
非同期IO処理だけさせるような所だとElixir含めてErlang系はものすごく便利だけど読める人が少ないし >>218 さん、
>>219 さん、
ありがとうございました。
Common Lispのライブラリが使えれば状況良くなるのかなぁ
※Lispはこれから勉強するのでどの程度違うものかは判っていなくて言っています。 haskellのlhs2texみたいなのって
LispやSchemeにはないの? あかんなぁ
俺、馬鹿になってきた
年ってやつかなぁ
Common Lisp始めたけど、あれこれの関数名をすぐ忘れる。
駿馬も老いては駄馬なんとかか >>223
不惑や知命でもぼける人はぼけちゃうからねぇ Schemeでsyntax-case使うとき、マッチングの第一要素にkって名前をよく見るし使うけどこのネーミングになんか由来とか理由とかあります?
なんで?って聞かれて答えられないんですが ソースがあるわけじゃないが自分は keyword の k だと思ってた。
仕様の中にある例でも k 使ってるからほとんどの人はそれに倣ってるだけだろうけど。 i と j じゃ整数の印象が強いんで、次の k を使ってるだけかと思った このあたりの例で使ってる i はたぶん identifier の i じゃないかと思う。
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-13.html#node_sec_12.7
t は疑問の余地なく temporary だな。 p は pattern で e は expression ってところか。 >>228
scheme限定のイディオムなんかね
clojureだと
(defn hoge [coll] (brabrabra))
coll(collection)をわたすんだぞーってイディオムになってるみたいな? パターン変数には全部頭に ? を付けるとかいう流儀もあるし、
そんなに確立したものではないと思うけどね。 >>232
constantな値にkFoo,kBarってつける習慣もあるからcontinuationにkプレフィックスはそんなに違和感持たないなぁ
class指向な処理系で classって名前使えないからClass klass = someObject.class って書くようなものかと思うのであるよ。
;;; 実は歌の続き?としばらく悩んだ 理解重視でオレオレlisp処理系をhaskellで書いててこれを改良しようとしてます
環境は[(名前,値)]というわかりやすい実装でラムダ式本体部を引用するとこんなのです
let env' = (zip param args) ++ closure ++ env in
last $ map (eval env') body
これって開発言語のスタックを使った実装になりますよね?
このコードはapplyの一部で、evalとapplyの相互再起の中の1コマなのですが
よく末尾再帰とかいいますがああいうのはどうやって判定するのですか? schemeはいい線行ってたと思う
不幸なのはほとんどの機能がjavascriptで足りてしまったこと
大多数の人は末尾再帰すらないjavascriptでいいと言う
繰り返し処理と言えばループしか脳から出てこないんだから
再帰はおろか末尾再帰なんか知らないだろう
再帰処理もスタック構造のコンテナとループで同じことができるんだから
実際知らなくても困らない JavaScriptの末尾再帰はもうすぐ実装されるし高階関数もずいぶん前からあるが WebAssembly が一般的になったら JavaScript の勢力は (クライアントサイドでは) 過去の資産を除いてフェードアウトしそう。
そのときこそ Scheme の復権が狙えるかもしれないぞ。 >>234
末尾コンテキストを判定する
末尾コンテキストの実行時はフレームで確保したスタックは使われない
よってその直前で削除してしまえるから関数呼び出し等でもループに置き換えられる
(define a (lambda (x y) (b x y) (a x y)))
の最後の(a x y)は末尾コンテキスト
最後のa呼び出し前のx yの引数の積み上げが完了した時点でaのフレームは削除できる
削除した後aを呼び出すとまた同じフレームレベルでaの処理が開始する 末尾コンテキストの伝播
tを末尾コンテキストとする
(lambda ()・・・t)
(if test t t)
(begin ・・・t)
(lambda()・・・・t))
組み合わせると次のように末尾コンテキストが伝播する
(lambda ()・・(begin ・・・×)・・・(begin ・・・(if test t t)))
×は親が末尾コンテキストでの実行でなければ子も末尾コンテキストにはならない事を示す 関数適用の末尾コンテキスト
上で(a x y)を末尾コンテキストと書いたが
より正確にはtの呼び出し時点が末尾コンテキストとなる
表記的には(t 引数)となるがt自身がいつ評価されるかはschemeでは規定されていない
よって処理系の都合順にt x yを評価した後、tの呼び出し前に末尾コンテキスト処理(フレーム削除等)が発生する 末尾コンテキストが移動する構文
(set! var exp)
(while test body)
set!はvarがフレーム内変数ならexpの評価、フレーム外変数ならvarをexpの結果で破壊した時点が末尾コンテキストになる
whileはtestで偽になった時点かbody内からbreak等で抜けた時点だが、
そもそもschemeでのループ構文は末尾再帰の構文糖衣として定義されることが多く、この限りではない
継続呼び出しの末尾コンテキスト
継続呼び出しは継続を保存した位置に移動すると共に環境も入れ替わるため
末尾コンテキストの対象外となる(考慮しなくて良い) >>241-244 素晴らしいIDですね
末尾コンテキストの伝播については理解できたと思います
ifは末尾コンテキストが2つに増えるので
もしif文が末尾に連なってたら末尾コンテキストがたくさんになるわけですね
これを使って末尾コンテキスト判定をするis-tailrecみたいなのを作れば
考え方として、関数fの定義でもしis-tailrecが真となる箇所以外でfが
呼ばれていれば末尾再帰でないと判定すればいいですよね
set!の部分がちょっとまだ理解できてませんが考えてみます >>237
紹介サンクス
かなり読みやすくなってる気がする Haskellのclassとinstanceに相当する型演算をSchemeで擬似的に作る方法ないのだろうか >>252
何だこれ。晒してるつもりなのか?
こんなことすべきじゃない。 >>252
これ読んでいるだけでも、すごく勉強になるよな なるよな?
同意を求めないで欲しい
気持ち悪いbot作ったなーとしか… SICP は専門書なわけで、どこの 140 文字を抜き出したって勉強になるってほどの情報量ないよ。 情報量うんぬん以前に
何言ってんのかわからない
日本語なのか
これは 変な翻訳を抜き出して笑うためのbotだと思うんですけど
SICPで翻訳と言えば例の翻訳炎上のはてブ勢の気持ち悪いこと気持ち悪いこと アスぺの人、和田訳を執拗に擁護するのはなんなんだろうな
専門知識で足りない英語力を補っているから、minghai訳よりはマシって程度なのに >>260
笑うためってのは言い過ぎだと思うけど、まあ、余興だよな。 和田訳こそ英文が読めなくて、日本語を適当にでっちあげた
真鍋のいうところの腐臭のする糞訳なのに、
どういうわけか擁護するんだよな 照り輝くbotはもともと糞訳をまとめたおもしろbotだろ
そもそも照り輝く自体相当前からネタにされてるし 糞約とはいえ他人の著作物云々の問題はクリアしてるのか? SICPを糞訳と言うと、おかしな連中が絡んできて面倒だったけど
これからはこれ貼るだけですむから楽でいいわ
https://twitter.com/illmnt_SICP_ja ■ このスレッドは過去ログ倉庫に格納されています