Lisp Scheme Part41 (809ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
135(2): 2019/12/06(金)00:43:20.37 ID:KafRVWs2(1/3) AAS
$ ros run
* (+ 31000 33500 1000 2300 16500 300 1000 10100)
64700
おいおい，なんだこのメチャクチャな値
こんなんじゃ，まったく信頼できないんだが
どうなってんだ
しかも再現できないし
$ ros version
roswell 19.09.12.102(NO-GIT-REVISION)
289(2): 2021/01/17(日)11:47:31.37 ID:9ajuvsmH(1) AAS
>>288
defgeneric/methodは勢いで書き上げた触りたくないコードに機能追加するにはコード触らなくちゃならない
型の付いていない複雑なconsはどうせdestructuring-bindして振り分けるしかないんだから分けてdefmethodする利点もない
define-compiler-macroなら一切既存のコードに触れる必要は無いからすごく便利だよ
既存のライブラリに手を入れたいけど、直接書き換えるとアップグレードで無かった事にされるから嫌、って時にも活躍する
もちろんリファクタリング出来るならした方がいいけど、取り敢えず動けば良い時の話ね
293: 2021/01/17(日)12:36:52.37 ID:16Ro+9sx(2/4) AAS
>>290
plistの方が好きだな、pprintでkey-valのカラムに並べられるし、alistが要求されれば一段flattenすれば済む
consの数も同じだし好みでは
ただvalがlistだと(a . (b c))=(a b c)とformatされてしまうので(a . ((b c))) = (a . (b c))と書いてる
aとリストのペアなので意味的にも正しいはず
412(1): 2021/07/13(火)08:34:35.37 ID:egse1qJT(1) AAS
named-lambdaならalexandriaにある
419: 2021/07/15(木)04:52:42.37 ID:eqEigNI9(1/2) AAS
逆やね末尾再帰でloopを代替できるからイキって仕様からloopを消したったのがｓchemeやからユーザーもイキるやで
428(1): 2021/07/15(木)21:29:35.37 ID:hFBqwrB0(1) AAS
named let 嫌いだわ、構文として紛らわしいだけ
あれはgotoとでも名乗るべき
545: 2022/11/07(月)12:52:44.37 ID:D9DaYQB4(2/3) AAS
木曽路的な
558: 2023/01/10(火)03:18:54.37 ID:/i8qCr3o(2/2) AAS
>>550
等価と思って良いよ
伝統的なlisp(とcl)のように(let ((x '())) ...)を(let (x) ...)と略記できない、だとか細かい差異はあるけど
百聞は一見にしかずなので、構文の対応を見るのが手っ取り早い
あとeclのname collisionの件、consの例(>>553)はさすがにcontrived-exampleだと思うので、ついでにeclで破綻するように
letrec/nlet/labels で定義するラベルとして、所謂accumulatorイディオムにloop(他にはlp, iterとか)を使うのが慣例だけど、eclではcl:loopと読まれるのでは？と予想
;;; cl -- ok: cmucl, sbcl, clisp, gcl err:ecl (的中)
(defun fact (n)
(labels ((loop (k acc)
(if (= k 0)
acc
(loop (1- k) (* k acc)))))
(loop n 1)))
;;; scheme -- ok: guile
(define (fact n)
(letrec ((loop (lambda (k acc)
(if (= k 0)
acc
(loop (1- k) (* k acc))))))
(loop n 1)))
pcでテストはしたけど、スマホから手打ちなので変だったらごめん
639: 2024/04/08(月)00:43:02.37 ID:skM/lEty(2/2) AAS
面白かったのでｗ
657: 2024/04/13(土)22:51:10.37 ID:Vi4F3OXr(1) AAS
昔MSの偉い人がGNUはガンだとか言ってたな
ついに自覚させたか
676(1): 2024/04/15(月)11:39:03.37 ID:L/ePcET8(1/2) AAS
中間言語が同じならコーディングの瑕疵は人間工学的な問題
Cは宣言が貧弱でin/out、純粋関数、エイリアスの有無は推論頼りだから失敗すれば死ぬ
ただ最近はrestrict宣言付けて回るなら重なるか推論不能な配列のエイリアス有無も指定可、難解だけど
一方で参照渡しのFortranはtaraiベンチで推論失敗すればデリファレンス地獄で死ぬわけだけど、これ解消する宣言あったっけ？
むしろ宣言無しのナイーブなコーディングなら数倍どころでは済まんよ
ランタイムの重いclは比類なき宣言の豊富さで静的言語にまで迫ろうと頑張ってるわけで
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.045s