Lisp Scheme Part41 (855ﾚｽ)
上下前次1-新
169: 2020/03/05(木)20:39 ID:h922Dn8C(6/11) AAS
>>146
＞論理プログラム言語（Prolog）なんて
ほとんどのプログラマが
仕事では一生使わないだろうな？
でも設計をする上で参考になる
170: 2020/03/05(木)20:41 ID:h922Dn8C(7/11) AAS
>>149
Prologの勉強は無駄ではないと思うが
すぐ成果には結びつかないだろうね？
でも長期的には流行りの言語やFWに飛びつくより
地力につながる可能性もあるだろう
171: 2020/03/05(木)20:42 ID:h922Dn8C(8/11) AAS
>>150
宣言型という点では近いけど言語としては同じじゃない
ユニフィケーションやバックトラックの挙動があるから
172: 2020/03/05(木)20:44 ID:h922Dn8C(9/11) AAS
>>151
AIはディープラーニングが主流になったが
それはそれとしてアレでPrologがもう少し
分かりやすければ日常的に使うんだけどな
これどうやって書くんだってのが多すぎる
173: 2020/03/05(木)20:47 ID:h922Dn8C(10/11) AAS
>>156
Lispはメタプログラミングしやすいって理屈は分かるが
実際にそれでものすごい作業効率が上がるかは疑問だな？
なぜんあらメジャーな言語はライブラリが充実してて
それ使えば最初から書かなくても済むわけだから早い
174: 2020/03/05(木)20:48 ID:h922Dn8C(11/11) AAS
>>159
本当にできるかできないかは知らんが
そういえばメタプロやってるって
声ほとんど聞いたことないな
Lisp勢はマクロマクロうるさいのに
175: 2020/03/05(木)23:31 ID:ilhNvGHV(1) AAS
3文字で頼む
176: 2020/03/06(金)05:04 ID:nWpA6pnf(1) AAS
スレチ
177: 2020/03/10(火)18:23 ID:BcZoFSIR(1) AAS
hy
マクロの入力にpair入れたのに
マクロ実行時にunquoteするとlistに化けるバグがある気がする
178: 2020/03/26(木)18:40 ID:jDMenf5s(1) AAS
日本の理系人のLisp好きは異常
179: 2020/03/26(木)21:06 ID:x3TTE31H(1) AAS
土日はおとなしくLispでも
180(2): 2020/04/24(金)18:37 ID:3QH+ANBn(1) AAS
Clozure CL 1.12 がでてきた。
外部ﾘﾝｸ[12]:github.com
ぜんぜん 1.11 からバージョンあがらないから死んじゃったのかと思ったよ。
181(1): 2020/04/24(金)19:04 ID:aAxBS6wC(1) AAS
死んでるんじゃない
枯れてるんだ😡
182(1): 180 2020/04/25(土)00:16 ID:iXfl78KC(1) AAS
>>181
ごめんなさい
ECL(Embeddable Common-Lisp)もバージョンアップしてた。
16.1.3から20.4.24になってる。
まだトップページ更新がないけど……。
外部ﾘﾝｸ[html]:common-lisp.net
変更点は以下
外部ﾘﾝｸ:gitlab.com
183: 2020/04/25(土)01:57 ID:u9oymkho(1) AAS
>>180
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
184: 2020/04/25(土)07:07 ID:q++AEQsZ(1) AAS
小学校でlispを教えたらいいのに
185: 182 2020/04/25(土)13:34 ID:tfHLOmTJ(1) AAS
News が更新されたよ。
外部ﾘﾝｸ[html]:common-lisp.net
186: ＿ 2020/04/28(火)00:30 ID:moc7J10E(1/2) AAS
SBCL 2.0.4 リリースされたよ。RISC-V プロセッサに対応したのが目玉みたいだよ。
外部ﾘﾝｸ[html]:www.sbcl.org
187(5): 2020/04/28(火)11:03 ID:jkGkDNpV(1/2) AAS
Scheme の map 手続きについて、
手続きを適用する順序 (副作用が発生する順序) は仕様上は未規定ということになっています。
各処理系として保証するということは有りえるんですが、
Racket の場合は保証されていると読み取って良いでしょうか？
外部ﾘﾝｸ[html]:docs.racket-lang.org
わざわざ "from the first elements to the last" という書き方をしているからには順序を意図しているように
解釈するのが自然かとは思うんですが、単に範囲を言っていると解釈できなくもないので、
英語と Racket に明るい方がいればご教示賜りたいです。
188(1): ＿ 2020/04/28(火)14:05 ID:moc7J10E(2/2) AAS
>>187
racket使ってるわけでも英語ができるわけでもないけど。
最初から最後までって範囲の話してるんじゃなかろうか。
順序の保証があるなら IN ORDER とか付きそうな気がする。
189(1): 2020/04/28(火)14:43 ID:jkGkDNpV(2/2) AAS
>>188
R5RS などでは手続きが各要素に適用される dynamic order は unspecified である
というような表現になってるんですよ。 order という語が主語になってます。
外部ﾘﾝｸ[html]:docs.racket-lang.org
だからわざわざ変えた表現をするからには違うこと (順序が保証される) を言おうとしているんだろうと思いつつも、
明確に順序を強調してるわけでもないな……？ というところで解釈に迷ってました。
私は R5RS (など) と言い回しが違うという点に引きずられていましたが、
"from the first elements to the last" というフレーズ単体で見ると範囲のニュアンス
で捉える方が自然ですかね。
私自身はいずれにしても map の副作用の順序に期待しないんですが、
しばらく前に Qiita に投稿されていた記事の中で map の順序が効いてくるコードがあったので、
これってありなんかなぁと思ったという経緯です。
190(1): 2020/04/29(水)01:16 ID:y02v3tEE(1) AAS
>>187
保証とはどういうことを指しているのだろう
将来仕様を変更しないとは書いていないのは確かなようだ
racketでは引数の評価もleft to rightとは書いてあった
schemeでもfor-eachは先頭から順番に評価する
実際に評価順の違いが観察できるのはchezかな
191(2): 2020/04/29(水)03:18 ID:ALOjMFFX(1/2) AAS
>>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ユーザとの約束の順守を保証せねばならない）、ということだ。
当然ながら、言語仕様書のバージョンが変われば約束（つまり言語仕様による規定の内容）も変更され得る。
192(1): 2020/04/29(水)06:44 ID:bLWOmnfL(1) AAS
>>187
処理系によって(A B C)の評価順序が
(1 2 3)だったり(3 1 2)だったり(3 2 1)だったりするから
mapのようなリストで処理結果を返すような関数のクロージャ内では原則副作用は起こさないことが求められる
for-eachみたいな初めから副作用を期待する関数はどう並べようが問題は起きない
193(1): 2020/04/29(水)09:21 ID:sxS/u8Yc(1/3) AAS
>>192
それは承知しているのです。
ここでは Racket のドキュメントをどう解釈すべきかというのが論点です。
>>191
> 最初の要素から最後の要素へと適用すると書いてある
順番に (in order) とは書いていません。
順序が意味を持つ箇所ではおおよそ order という語で強調しているのに
それがないここでも順番であることを確信してよいほどに
(英語のニュアンスとして) 自明でしょうか。
194(2): 2020/04/29(水)09:54 ID:sxS/u8Yc(2/3) AAS
>>191
> 長大なリストに対する並列処理を可能にするためだろう
手続きの引数の評価順序については未規定ではあるものの
"some sequential order of evaluation" という制約がついています。
外部ﾘﾝｸ[html]:docs.racket-lang.org
ちょっとわかり難いんですが、これは「同時ではない (かのように動作する)」と解されるそうです。
たとえば
(list (begin (display 'a) (display 'b) 1)
(begin (display 'c) (display 'd) 2))
とあったときに表示は abcd か cdab のどちらかであり acbd だったり cabd だったりはしない
ということです。
map についてはこういう制約は書かれてはいないものの、
順序は規定しないという文言は「既定はしないけどなんらかの順序を想定する」
とも読めなくもないので並列化を許しているとは言い切れない気がします。
副作用がないときに限っては並列化しても仕様に反しないのは間違いないですけど、
その場合は順序に関して有るとも無いとも書く必要がないんですよね。
どうせ観測できないので。
195(1): 2020/04/29(水)12:39 ID:qQMMu/UY(1) AAS
>>194
mapについては、まえからか、うしろからか好きな方で実装すればいいよ、程度のはなしだとおもってた。
継続を突っ込むとどうとかいうのがあったとおもうけどだれか解説pls
196: 187 2020/04/29(水)13:42 ID:sxS/u8Yc(3/3) AAS
>>195
継続については「call/cc は副作用を生じる」というひとことで説明できます。
副作用とは何かというのは色々なモデル化のやり方があってはっきりしたひとつの定義を
定められないみたいなんですが、この説明が納得感があって参考になると思います。
外部ﾘﾝｸ[cgi]:practical-scheme.net
副作用がないなら順序なんか考える必要はないんですよ。
どの順序で実行されようと並列であろうと (観測できる) 結果は同じなので順序を気にする意味がありません。
結果が同じにならない場合 (副作用がある場合) がどうあるべきか考えるから順序が効いてくるんです。
で、副作用がある手続きの中でも特に第一級継続は (観測できるだけでなく) 流れを変えることが出来るから
どれが妥当なのか結論が出ないなぁってことです。
197: 2020/04/29(水)14:57 ID:u7alO7eW(1) AAS
グラフかくのってどうしたらいい？gnuplotの🎺使うの？
gnuplot使ったことないけど難しいのか？
198: 2020/04/29(水)18:27 ID:OS1rodDF(1) AAS
やりたいことをやろうとすると難しい
上下前次1-新書関写板覧索設栞歴
あと 657 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.013s