Lisp Scheme Part41 (858ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
120: デフォルトの名無しさん [sage] 2019/10/28(月) 18:32:21.08 ID:yqfr49c7(1) AAS
Yコンビネーターも辞めたとかなんとか…
詳しく知らないけど、引退かな？
353(1): デフォルトの名無しさん [sage] 2021/03/20(土) 02:13:36.08 ID:SzdWYV/s(2/3) AAS
>>352352(1): はちみつ餃子 ◆8X2XSCHEME [sage] 2021/03/20(土) 02:00:29.14 ID:O2z0YRFR(2/4) AAS
>>351
Scheme で言う SRFI に相当するものとして Common Lisp にも CDR (Common Lisp Document Repository) があるんだが、
Common Lisp は Scheme よりも実務主義というか話し合いするよりも動くライブラリを置いときゃいいだろみたいな文化があって
共通仕様の策定に熱心ではないような気がするな。
今誰が主導してるかと訊かれて、答えに詰まるのは特異な状況だとは思う
商用(持ってないけど)ですら保守的にみえる
ぬるま湯に浸かるのを良しとしないISLISPの人を讃えたい
フリーでまともな処理系待ってるから出来たら起こしてくれよな！(讃えるだけ)
410: デフォルトの名無しさん [sage] 2021/07/12(月) 22:45:17.08 ID:u5zIJQm8(1) AAS
(let loop ((n 10)) (if (> n 0) (loop (- n 1)) #t))
↓
(((lambda (loop) (set! loop (lambda (n) (if (> n 0) (loop (- n 1)) #t))) loop) 'dummy-label) 10)
こういう仕組みだからCLで書けなくもないと思うけど
411: デフォルトの名無しさん [sage] 2021/07/12(月) 23:10:07.08 ID:eka9NNGK(1) AAS
現代のlispハッカーはみんなloopマクロ使ってるよ
475: デフォルトの名無しさん [sage] 2021/10/10(日) 10:54:30.08 ID:Td68Zwht(1) AAS
スレッド周りはpthreadのエミュレーションを自前で実装してたのを、直接Win32のAPIを呼ぶようになった
コードが一気にシンプルになったし、その時にバグの修正も行ったのだろう
606: デフォルトの名無しさん [sage] 2023/04/24(月) 08:39:19.08 ID:AD1D3xO/(1) AAS
最適化されたCLは最適化されていないCよりは速い
昔Common LispでCより速いHTTPパーサを書いたとか言ってたのを見かけた
コードを見るとnodejsのCで書かれたHTTPパーサをパクったみたいな感じなのに
比較対象はなぜかどっかの個人がCで書いたHTTPパーサだった
その個人が晒してたソースのMakefileはデフォルトでは最適化なし
なぜ比較する前にCの方を最適化することを思いつかなかったのだろうか
というかなんでnodjsの方と比較しなかったんだ？
誰か理由わかります？
624: デフォルトの名無しさん [sage] 2023/10/07(土) 23:47:40.08 ID:c4CFtcBt(1) AAS
要望ね。schemeは処理系としては構造が簡単だから適当に作ってもそこそこ良い具合に出来上がるだろうが、
問題はその後で、処理系の方向性を決める必要がある。処理系作るってことは目標が既に設定されている場合もあるが、
他人に使って欲しいのであるなら例えばpythonライブラリ流用できるとか.NETでGUIアプリ簡単に作れますとかwebだとか生成AIで何かいけるとかそんなのだね
俺がGaucheの名前を知りながら長年ほぼ触ったことないのはその辺りが原因だよ
673(1): デフォルトの名無しさん [sage] 2024/04/15(月) 06:50:07.08 ID:DfbFoW6K(1) AAS
>>671671(5): デフォルトの名無しさん [sage] 2024/04/15(月) 03:45:37.49 ID:KXqIDgH/(1) AAS
Cバックエンドで配列のviewをサポートしてるなら究極的には言語/処理系ではアルゴリズム瑕疵が無い限り有意な差はないよ
ただし最速言語Fortranを半分程度使うNumpyにも優位性はある
gccはじめ同じILにコンパイルされても配列多様コードでにおいてCより数倍は速い
ただしNumpyは書き方に細心の注意をしないとユーザの預かり知らぬ所で勝手にディープコピーする大きな罠も
そうした不透明性が嫌い
明示できるCLのFortran実装を待ち望む
>ただし最速言語Fortranを半分程度使うNumpyにも優位性はある
>gccはじめ同じILにコンパイルされても配列多様コードでにおいてCより数倍は速い
この部分、Fortranで配列多用したらCより数倍速い的な意見なのかな？
1ミリも分からんので、詳細求む
693(1): デフォルトの名無しさん [sage] 2024/04/16(火) 13:59:54.08 ID:HsOietmi(1) AAS
>>690まじかー𓃠
愛読しろにゃ
695: デフォルトの名無しさん [sage] 2024/04/18(木) 15:57:15.08 ID:L09lN/Y8(1/3) AAS
>>652652(3): 645 [sage] 2024/04/12(金) 15:53:49.12 ID:OhyEPSVL(1) AAS
lispの話をしよう
onlisp.lispのようなオレオレutil(s).lisp/scmから引用し過ぎるのはあまり宜しくない？
macroはコンパイル順の関係で引く方が問題起きにくいけど
名前がdescriptiveなのは前提として
too generalであれば初見の人に読みにくいのではと思うこの頃
一方でspecificであるかぎり、手続きを分かつ働きすら無い関数抽象も読み易い:
carにget-operator、cdrにget-operandsなど単なるリネームでも重用する
これらはpackage内にレキシカルな意味で近傍に置くべきよね？(使い捨てならflet/labels、共用ならdefun)
より一般的な小物をコーディングを楽にする為だけに引くならば、lisp書きなら定義も大体覚えてるだろう有名な小物util集(alexandria、sfri)に依存した同梱するのも(ライセンスが許しても)憚られる…
このスレやSO等見ても必読書なOn Lispは知名度あるだろうから、onlisp.lisp由来のものは初見で読めてコンパクトでバランス取れた妥協点だと思って使ってるんだけど
(ライセンスや再帰志向で性能難アリなので、手習いがてら書き直したクローン版、念の為)
なおonlisp.lispは手続き名がいにしえのlispかよってくらいヤバいのが欠点
acl2.lispもたぶん参考にしてるかもだけど
On LispにもANSI CLにも載ってないのを集めた utx.lispってのもあるよ
念の為
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s