Lisp Scheme Part41 (858ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
201: デフォルトの名無しさん [sage] 2020/04/30(木) 02:18:30.11 ID:7t452aCV(1) AAS
>>199199(1): デフォルトの名無しさん [sage] 2020/04/29(水) 23:11:18.94 ID:ALOjMFFX(2/2) AAS
>>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
なるほど、インターリーヴを起こしてはならない、ということですね
良い反例ですね、了解しました
確かにそれだと並列処理という話は排除されますね
> "from the first elements to the last"は最初の要素から最後の要素へだから当然ながらin orderの意味を含む
この説明は説明になってなかったですね
ちゃんと書くと、前置詞fromとtoとを同時に使う場合、前者は動詞が表す行為の始点を、後者は終点を表す
つまり
> "from the first elements to the last"
という表現は先頭の要素たちがprocをapplyするという行為は、その行為の始点が先頭要素で終点が末尾の要素となる経路から成るということ
そうであるので、途中の要素に関しては193が心配している通り順序通り(in order)とは確かに書いていないけれど、
少なくとも最初に適用されるのは先頭要素たちで最後に適用されるのは最終要素だということは上の引用した英語句から確かだということ
applyを行う最初と最後はそれぞれ先頭と末尾でなければならないのに途中はランダムでも可というのは不自然すぎる
（なぜ最初と最後だけは変更を許さず先頭と末尾に確定させるのか？、ランダムを許すならば最初・最後も含め全部がランダム可にするのが自然）
ということだ
もし最初および最後だけはそれぞれ先頭および最後だけに限定し、それ以外の途中の順番だけは規定したくない、という極めて不自然な仕様にしたいならば
誤解させないように、「但し、最初・最後以外の途中の順番は自由で規定しない」という趣旨の語句を挟む必要がある
317: デフォルトの名無しさん [sage] 2021/02/17(水) 18:52:29.11 ID:zk5Pyjxw(1) AAS
アラン・ケイもそれを自分でやってみようとすることが重要だと言ってる
原始関数が変われば何もかもが変わるわけだから
変わった世界が良いのか悪いのか、は自己言及がどれだけよく出来てるかどうか
ということだと思うんだけど
つまり、僕らが使いやすいと感じるかどうかではなく
未来にそれに慣れた人たちがより効率の良い開発が出来るかどうか
で、グレアムは自分なりにBelは良く出来てると思ってるんだろう
オレにはよくわからんがｗ
356: デフォルトの名無しさん [sage] 2021/03/20(土) 03:47:36.11 ID:J9z4ezp0(1) AAS
SRFI出るや否や写経と称してシュババとクオリティ実装するclerが結構居るし、必要とあらば足りるしな
quicklispにも結構載ってるよね、clに混ぜるのは違和感あるからあくまでお手本としてアイデアを拝借するだけだが()
scheme処理系も多くのSRFIを標準で揃えてるわけじゃないから(ポートは容易だろうが)、やっぱまとめ役が居ないことに尽きる
qlがやる気出さないかな
363: デフォルトの名無しさん [sage] 2021/04/05(月) 19:12:20.11 ID:DVkxDxiZ(1) AAS
わだばさんのところに紹介があった
外部ﾘﾝｸ:g000001.cddddr.org
382: 本田 [] 2021/04/11(日) 07:05:56.11 ID:vMH2MoUG(1) AAS
>>381Unlambda.com | Main / Cadr
外部ﾘﾝｸ[php]:www.unlambda.com
Retrocomputing - MIT CADR Lisp Machines
CADR Emulation
493: ＿ [] 2022/01/04(火) 06:23:02.11 ID:rzEME/gD(1) AAS
>>491Gauche 0.9.11-p1 リリース
Windows での問題修正のみみたい。
>>4921.0に向けての作業入られているようだけど
今年中に出るかは判らんなぁ
654: デフォルトの名無しさん [] 2024/04/13(土) 18:14:03.11 ID:JilIuOKd(1/2) AAS
ストールマンがガンになったらしい
長髪も髭も落としてしまって別人みたいになってる
670(1): デフォルトの名無しさん [sage] 2024/04/15(月) 03:14:20.11 ID:YG3lrvG/(4/4) AAS
古いAIのバイブルPAIPすら恥ずかしながら未読の身ですが…
lispもデータドリブンなNN系はむしろ苦手とは思わない
NN系がマスメディアでもバズり出した頃にウィキペディア見たら、Pythonのサンプルコードが載ってたので
そのままCPython/Numpyとclで書いてみたら、ベンチはsbclぶっちぎりだったよ
もちろん個々の処理がバックのcライブラリより速いなんて言わない
同レベルのコーダが同ロジックで翻訳すればの話
その差はclの無駄に細かいarray/vectorコンストラクタ引数の設計
具体的にはR/W抑えるビュー相当の:displaced-*と:fill-pointer、配列の動的リサイズ指定の:adjustable引数ね
Numpyのndarrayはこの辺が裏で自動でやるのでコーダの裁量がない
まあNumpyでプラグマ/フラグ駆使してその辺のお節介挙動を切れば普通に負けるかも
あくまで並コーダが素直に書く限りの話
747: はちみつ餃子 ◆8X2XSCHEME [sage] 2025/07/09(水) 14:21:01.11 ID:ZKntcAAj(2/7) AAS
>>746746(1): デフォルトの名無しさん [] 2025/07/09(水) 14:05:12.47 ID:cmuoaTCa(1/10) AAS
>>745
＞処理系の実装方法の一部は言語仕様として強制すべきというのが前提になってる？
テイルコールはそうでしょ
最適化は処理系がやってくれることを保証するので
単純ループに相当するものでもどんどん再帰の形で書きましょうってことでしょ
ファーストラムダも同じ
制御構造相当のものをlambdaを使って書いても最適化されますよってこと
> テイルコールはそうでしょ
> 最適化は処理系がやってくれることを保証するので
仕様上は
・正しく末尾再帰が行われていること
・アクティブな末尾呼出しの回数制限がないなら正しく末尾再帰が出来ている
という迂遠な表現になっている。
つまり、何が出来るべきなのかという書き方であって、どう実装すべきかに言及することを避けてる。
同様に処理系のメカニズムに言及することを避けて提案を表現してみてよ。
816: 八大龍王・豊田聡志 [] 2025/09/30(火) 19:24:46.11 ID:rqdKtsao(4/24) AAS
sao
surveyscm.scm by さとばん
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.043s