Lisp Scheme Part41 (855ﾚｽ)
上下前次1-新
163: 2020/03/04(水)12:50 ID:ujdXlrHA(1) AAS
SECD
Landin’s J
164: 2020/03/05(木)20:29 ID:h922Dn8C(1/11) AAS
>>50
需要の問題だろ
Lisp自体がマイナーで
Common Lispでやっと本が出せる位なのに
165: 2020/03/05(木)20:29 ID:h922Dn8C(2/11) AAS
>>53
今はAIといえばPythonだろ？
166: 2020/03/05(木)20:30 ID:h922Dn8C(3/11) AAS
>>54
昔の一時期は妥当だったんだろうけど
今ならPythonの方が向いてるだろう
167: 2020/03/05(木)20:32 ID:h922Dn8C(4/11) AAS
>>57
>>58
要は人工知能というより記号処理なんだよ
168: 2020/03/05(木)20:34 ID:h922Dn8C(5/11) AAS
>>82
>>84
MITの件もあるし
今ならPythonでいいでしょ
MITレベルの頭ならLispなんて
すぐ読み書きできると思うが
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みたいな初めから副作用を期待する関数はどう並べようが問題は起きない
上下前次1-新書関写板覧索設栞歴
あと 663 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.020s