Lisp Scheme Part41
>>99 ちゃんとメンテされている商用以外のフリーの処理系はSBCLしかないという… Scheme で安心感の強い処理系っていうと Racket とか Guile とかかな。 そう簡単に廃れなさそう。 Schemeの無料で使える処理系で例の大顰蹙買ったR6RS対応してるのってあるの? >>103 あるよ。 Racket Chez Vicare Sagittarius Ikarus IronScheme Ypsilon Mosh Larceny R6RS に準拠ってほどではないけど一部をサポートしているものとしては Guile BiwaScheme もある。 Sagittarius と Larceny は R7RS もサポート (R6RS と R7RS を混在させることも出来る) しているよ。 Vicare, Ikarus, Ypsilon は実質的に動きが無くなっているのでこれから使うのはやめた方がいいかもね。 なんでGaucheが出てこないんだ? R7RS準拠と書いてあるよ >>105 ここでは >>103 に対する回答なので R6RS の話をしてる。 >>104 お教え下さり、どうも有難うございました。 RacketもR6をサポートするようになってたんですね。 R6発表後も数年間はRacketはR6対応じゃなかったようなのでサポートする気がないのかと勝手に思い込んでました。 R7RS⊃R6RS⊃R5RS ではないんだっけか CommonLISPから何も学んでねーな Scheme はまだ未完成という意識がある気がするな。 だから実務指向な言語と違って現段階では互換性を重要視してない。 重要視はしてないけど突飛な変更が入ってるわけでもなくて、割と正統進化してると思うよ。 R6RS が異端なだけ。 その R6RS にしたところで R7RS と共存が可能な程度に近しいわけだし。 関数の値が最も0に近くなる引数を求めたい時、どう書けばいいんでしょう? 繰り返しで引数を少しずつ変えていけばいいのはわかるのですが、定石とかあるんですか? その関数が線形なのかとか微分可能なのかとか分からんとなぁ 微分可能ならニュートン法が簡単 そうでないなら、範囲 [ a , b ] をステップ幅 (b-a)/n で 暫定値を探る。(n:分割数) それが範囲の左右半分どちらにあるかに応じて値 a, b を更新、あとは再帰的に投入。 ステップ幅 が指定誤差未満になったら a を返して脱出 そのまま愚直に組むだけならそんなに長くならない。 >>113 の言ってる関数は数学の関数じゃなくてプログラムの関数の事でしょ… 多分線形でも微分可能でもないだろう 乱数使って適当な範囲で試行してずらしながら一番近そうな範囲を選択して絞り込んでいくという位しか思い付かない どちらの関数にせよ考え方は一緒じゃないかな。 値の変化が連続的でなければそのやり方では求められないし、連続的であっても極小値に落ち込んでしまう可能性がある。 関数がハッシュ計算するようなものだったら総当たりしかないのでは? 誰かと思ったらグレアムか 奴は口だけのポンコツになって久しいよ もう実装は無理 Yコンビネーターも辞めたとかなんとか… 詳しく知らないけど、引退かな? ポール・グレアム (54歳) 庵野秀明 (59歳) 引退するような歳か? arcだかはどうなったの まあどうでもいいんだけど グレアムは金には困らんのだから残りの人生は全部が趣味みたいなもんだろ。 引退もクソもねぇよ。 闇の書を永久封印するために暗躍しているのかもしれん。 fooもねえ、barもねえ hyperspecナニモノだ グラハムはハーバード、MIT人工知能研、イタリアの美術大出てるんでしょ? アメリカの大学は学費も相当かかる ビジネス始める前から「普通の奴等の上」を行ってる人なんだと思うなぁ 頭さえ良ければ、とか思うかもしれないが環境、友人は大事だよ ビアウェブのパートナーはMITの教授だよね、確か いまPLAIの8章をよんでいるんだけど、次のExerciseの不変条件と言うのがよく分からん・・ ttp://cs.brown.edu/courses/cs173/2012/book/mut-struct-vs-var.html#%28elem._%28chunk._~3cms-setbox.C-case~3e~3a1%29%29 ソースコードはこれ https://bitsend.jp/download/d7ebf31e84a7dc5d8b55a3e3b66ce803.html Storeに束縛を追加するのはbox、その束縛を参照するのはset-box!とunboxだけだから、 set-box!を評価するときに、ロケーションがStoreに存在しないことは無いように考えているんだけど、もっと数学的に 証明しなきゃいけないんですよねこれ・・ $ ros run * (+ 31000 33500 1000 2300 16500 300 1000 10100) 64700 おいおい,なんだこのメチャクチャな値 こんなんじゃ,まったく信頼できないんだが どうなってんだ しかも再現できないし $ ros version roswell 19.09.12.102(NO-GIT-REVISION) 正しい値は 95700 なのだが (- 95700 31000) が 64700 になることに気づいた 最初の引数,抜かしてんじゃん... REPL の + 関数,バグってるんだが それとも WSL がいけないのか? tmux がいけないのか? $ ros run -- --version SBCL 1.5.5 Gauche の 0.9.9 がリリースされたよー >>134 Lispworks 8 でる情報あったんですか? てっきり次は 7.2 かと。 Racket 7.6リリースされたよー https://blog.racket-lang.org/2020/02/racket-v7-6.html Chez Schemeの取り込みが進んで、プロダクション・レディになったそうな。 デフォルトにはまだなっていないようです。 SICPを勉強したくてschemeを一通り勉強したけど schemeが本当に好きになった 綺麗な言語だなと思ったのはschemeが初めて SICPで4.4論理プログラミングがでてきたけど、論理プログラム言語(Prolog)なんて 一生使わんのじゃないのか・・・?俺みたいな雑魚PGは特に。 そもそも俺はなんでインタプリタ作ってるんや・・・ >>146 SICP はコンピューターサイエンスの本だから、 いろんなパラダイムについて説明しているよ。 知ってれば便利なこともあるとは思うけど、 必ずしも日常的に役立つというものでもないのも確か。 prologはともかくユニフィケーションはパターンマッチでたまに使うかも 歴史、哲学、思想を勉強しても目の前の仕事には直結しない みたいなことなのかな PrologはSQLに近い(同じ?)という人もいるね 事実を列挙すれば解を求める処理をやってくれるってのは理想のひとつではあるよな。 実際にはには Prolog が答えを出すメカニズムを理解していないと 答えを (効率的に) 出しやすい事実を上手く与えられない場合もあるし、現実は厳しい……。 思うんだけどLispというと悟りとか、ゲーデル云々みたいな話がよく言われるけど Prologではあんまり関連付けて言われないですよね 上にもあるけどprologは論理がそのままプログラムになるっていわれてんだろ 似たようなもん hy面白いけどlisperにはrubyの方が人気なんだ >>152 > Prologではあんまり関連付けて言われないですよね Prologは「論理プログラミング言語」と呼ばれたりするけれど書かれたプログラムを実行可能にするためのプログラミング言語であるために 論理のための言語(つまり論理式を記述するための言語)とはかなり違ってしまっているからね その典型がPrologで動くプログラムを書く上で不可欠なカット “!” ね あれは本来の論理には対応物がなく論理とは全く縁のないコンストラクトだが カットを使わなければほとんどのPrologプログラムはまともに動かなくなってしまうだろう その点、Schemeから命令的な言語コンストラクトおよび標準手続きであるset!とset-car!, set-cdr!を除いた部分は 弱い(weak, つまりλ抽象の本体式中のβ-簡約基(redex)は簡約せずに放置しておく) 作用的順序(applicative order)の評価戦略(reduction strategy)のλ計算そのものだ call-ccは継続(continuation)というメタな(つまり意味論上の)値を対象レベルに持ち込むmeta-circular的な拡張であり Schemeに限らずLisp一般で広く採用されているS-式という構文は自分の構文に対する抽象構文の表現になっているから プログラムが自分自身(や同じ言語で書かれた他のプログラム)のソースコードを記述している言語を対象言語として 自分自身がそれを素直な形で操作できるメタ言語レベルの存在として振る舞えることになるからね 言い換えればS-式という表現形式のために括弧をやたらと多用させられるLisp言語では ソースコードをその抽象構文(木構造)と同型な形で記述させていると言っても良い だからLispのプログラムをLispで処理する場合には、C等のような普通のプログラミング言語で書かれたプログラムを処理する場合には 不可欠な字句解析や構文解析が実質上は不要なんだよ 何故ならば処理する側のLispプログラムにとって処理される側のLispコードは最初から抽象構文木と1:1対応する形式で提供される訳だから 正にゲーデルの不完全性定理で行っている形式化された論理のゲーデル数による表現とそれを原始再帰的函数や同述語を含むメタ論理のレベルで 処理する構造が、Lispの世界に対応していると言えるわけですよ 要するにPrologはメタ論理レベルのプログラミングが出来ないってこと? >>50 需要の問題だろ Lisp自体がマイナーで Common Lispでやっと本が出せる位なのに >>54 昔の一時期は妥当だったんだろうけど 今ならPythonの方が向いてるだろう >>57 >>58 要は人工知能というより記号処理なんだよ >>82 >>84 MITの件もあるし 今ならPythonでいいでしょ MITレベルの頭ならLispなんて すぐ読み書きできると思うが >>146 >論理プログラム言語(Prolog)なんて ほとんどのプログラマが 仕事では一生使わないだろうな? でも設計をする上で参考になる >>149 Prologの勉強は無駄ではないと思うが すぐ成果には結びつかないだろうね? でも長期的には流行りの言語やFWに飛びつくより 地力につながる可能性もあるだろう >>150 宣言型という点では近いけど言語としては同じじゃない ユニフィケーションやバックトラックの挙動があるから >>151 AIはディープラーニングが主流になったが それはそれとしてアレでPrologがもう少し 分かりやすければ日常的に使うんだけどな これどうやって書くんだってのが多すぎる >>156 Lispはメタプログラミングしやすいって理屈は分かるが 実際にそれでものすごい作業効率が上がるかは疑問だな? なぜんあらメジャーな言語はライブラリが充実してて それ使えば最初から書かなくても済むわけだから早い >>159 本当にできるかできないかは知らんが そういえばメタプロやってるって 声ほとんど聞いたことないな Lisp勢はマクロマクロうるさいのに hy マクロの入力にpair入れたのに マクロ実行時にunquoteするとlistに化けるバグがある気がする Clozure CL 1.12 がでてきた。 https://github.com/Clozure/ccl/releases/tag/v1.12 ぜんぜん 1.11 からバージョンあがらないから死んじゃったのかと思ったよ。 SBCL 2.0.4 リリースされたよ。RISC-V プロセッサに対応したのが目玉みたいだよ。 http://www.sbcl.org/news.html#2.0.4 Scheme の map 手続きについて、 手続きを適用する順序 (副作用が発生する順序) は仕様上は未規定ということになっています。 各処理系として保証するということは有りえるんですが、 Racket の場合は保証されていると読み取って良いでしょうか? https://docs.racket-lang.org/reference/pairs.html?q=map#%28def._%28%28lib._racket%2Fprivate%2Fmap..rkt%29._map%29%29 わざわざ "from the first elements to the last" という書き方をしているからには順序を意図しているように 解釈するのが自然かとは思うんですが、単に範囲を言っていると解釈できなくもないので、 英語と Racket に明るい方がいればご教示賜りたいです。 >>187 racket使ってるわけでも英語ができるわけでもないけど。 最初から最後までって範囲の話してるんじゃなかろうか。 順序の保証があるなら IN ORDER とか付きそうな気がする。 >>188 R5RS などでは手続きが各要素に適用される dynamic order は unspecified である というような表現になってるんですよ。 order という語が主語になってます。 https://docs.racket-lang.org/r5rs/r5rs-std/r5rs-Z-H-9.html?q=map#%25_idx_580 だからわざわざ変えた表現をするからには違うこと (順序が保証される) を言おうとしているんだろうと思いつつも、 明確に順序を強調してるわけでもないな……? というところで解釈に迷ってました。 私は R5RS (など) と言い回しが違うという点に引きずられていましたが、 "from the first elements to the last" というフレーズ単体で見ると範囲のニュアンス で捉える方が自然ですかね。 私自身はいずれにしても map の副作用の順序に期待しないんですが、 しばらく前に Qiita に投稿されていた記事の中で map の順序が効いてくるコードがあったので、 これってありなんかなぁと思ったという経緯です。 >>187 保証とはどういうことを指しているのだろう 将来仕様を変更しないとは書いていないのは確かなようだ racketでは引数の評価もleft to rightとは書いてあった schemeでもfor-eachは先頭から順番に評価する 実際に評価順の違いが観察できるのはchezかな >>189 > 私は R5RS (など) と言い回しが違うという点に引きずられていましたが、 > "from the first elements to the last" というフレーズ単体で見ると範囲のニュアンス > で捉える方が自然ですかね。 いや、違う。 R5RSとRacket Reference v7.6とでのmapが手続き(proc)を適用する要素の順番に関して言及しているのは 各々、以下の箇所だが、両者では明らかに全く異なる。 R5RS>The dynamic order in which proc is applied to the elements of the lists is unspecified. Racket>Applies proc to the elements of the lsts from the first elements to the last. R5RSは>>187 で君が述べていた通り、リストの要素への適用順序はunspecifiedだと明確に書いてある。 これに対してRacket v7.6ではprocをlstsの最初の要素から最後の要素へと適用すると書いてある、 つまりリストlstsの要素の並びの順番に手続きprocを適用して行くと明記している。 だからprocとして受け取った値を標準出力に書き出す手続きを渡せば、R5RSでは表示される要素の順番はどんな順序でも良いのに対して Racket v7.6では元のリストlstの要素の並び順に必ず表示せねばならない。 これは私の想像だが、R5RSでmapが手続きを適用する要素の順番を規定しないと明記しているのは長大なリストに対する並列処理を可能にするためだろう。 逆に言えば手続きの適用順序を確実に把握したい場合にはmapでなくfor-eachを使えというのがR5RSを定めたチームの言語設計上の意図だろう。 >>190 > 保証とはどういうことを指しているのだろう その言語仕様書のそのバージョンに準拠していると宣言している言語処理系は、それを守らねばならない(守っていなければバグだ)という意味だよ。 だから今の例では、Racket Reference v7.6準拠と処理系が宣言したら、その処理系はmapで手続きを適用する要素の順番を必ずリストの並び順に する義務が生ずる(Racket v7.6の定める言語仕様=Racket v7.6ユーザとの約束の順守を保証せねばならない)、ということだ。 当然ながら、言語仕様書のバージョンが変われば約束(つまり言語仕様による規定の内容)も変更され得る。 >>187 処理系によって(A B C)の評価順序が (1 2 3)だったり(3 1 2)だったり(3 2 1)だったりするから mapのようなリストで処理結果を返すような関数のクロージャ内では原則副作用は起こさないことが求められる for-eachみたいな初めから副作用を期待する関数はどう並べようが問題は起きない >>192 それは承知しているのです。 ここでは Racket のドキュメントをどう解釈すべきかというのが論点です。 >>191 > 最初の要素から最後の要素へと適用すると書いてある 順番に (in order) とは書いていません。 順序が意味を持つ箇所ではおおよそ order という語で強調しているのに それがないここでも順番であることを確信してよいほどに (英語のニュアンスとして) 自明でしょうか。 >>191 > 長大なリストに対する並列処理を可能にするためだろう 手続きの引数の評価順序については未規定ではあるものの "some sequential order of evaluation" という制約がついています。 https://docs.racket-lang.org/r5rs/r5rs-std/r5rs-Z-H-7.html#%_sec_4.1.3 ちょっとわかり難いんですが、これは「同時ではない (かのように動作する)」と解されるそうです。 たとえば (list (begin (display 'a) (display 'b) 1) (begin (display 'c) (display 'd) 2)) とあったときに表示は abcd か cdab のどちらかであり acbd だったり cabd だったりはしない ということです。 map についてはこういう制約は書かれてはいないものの、 順序は規定しないという文言は「既定はしないけどなんらかの順序を想定する」 とも読めなくもないので並列化を許しているとは言い切れない気がします。 副作用がないときに限っては並列化しても仕様に反しないのは間違いないですけど、 その場合は順序に関して有るとも無いとも書く必要がないんですよね。 どうせ観測できないので。 >>194 mapについては、まえからか、うしろからか好きな方で実装すればいいよ、程度のはなしだとおもってた。 継続を突っ込むとどうとかいうのがあったとおもうけどだれか解説pls >>195 継続については「call/cc は副作用を生じる」というひとことで説明できます。 副作用とは何かというのは色々なモデル化のやり方があってはっきりしたひとつの定義を 定められないみたいなんですが、この説明が納得感があって参考になると思います。 https://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3Acall%2Fcc%E3%81%A8%E5%89%AF%E4%BD%9C%E7%94%A8 副作用がないなら順序なんか考える必要はないんですよ。 どの順序で実行されようと並列であろうと (観測できる) 結果は同じなので順序を気にする意味がありません。 結果が同じにならない場合 (副作用がある場合) がどうあるべきか考えるから順序が効いてくるんです。 で、副作用がある手続きの中でも特に第一級継続は (観測できるだけでなく) 流れを変えることが出来るから どれが妥当なのか結論が出ないなぁってことです。 グラフかくのってどうしたらいい?gnuplotの🎺使うの? gnuplot使ったことないけど難しいのか? >>193 "from the first elements to the last"は最初の要素から最後の要素へだから当然ながらin orderの意味を含む もしも、上の表現を使ってin orderを保証しないことを意図する言語仕様があったら、 その言語仕様を書いた人間が英語(というよりも人間の使う言葉)の常識を知らないと言うべきレベルの代物 procの適用にin orderを保証したくないのならば"from the first elements to the last"などではなく、例えば “(map) Applies proc to every elements of the lsts exactly once”とでも書くべき というか、そもそもR5RSでのmapに関する表現をそのまま使えば良い >>194 なるほど、インターリーヴを起こしてはならない、ということですね 良い反例ですね、了解しました 確かにそれだと並列処理という話は排除されますね 実用性皆無の話だなschemeらしいや racketとの比較ならr6だと思うのだが しかもr7でなくr5とな scheme間でさえ移植性は低いんだからどんな挙動でも良いんじゃねえか racketはまだ実装が複数存在するような状況ではないらしいが schemeとは文化が違うんで実用性に舵切った仕切りになりそうね read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる