元スレEmacs part 26

emacs覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

201 = :

うへそれは気付かなかった
にわか丸出しだなお恥しい

202 = :

Warning: `mapcar' called for effect; use `mapc' or `dolist' instead

このwarningが非常にうざいんだけど、どうにかならないだろうか？
そもそも、どうして mapcar は推奨されていないんだろう？

mapcar と mapc は動作も違うし、混乱の元になるような気がしないでもない。

203 = :

戻す値の分メモリが確保されてそれが無駄になるからとか？

204 = :

個人的に戻り値に変化を加えることが目的の場合、 mapc は適切じゃないから、
そういったケースに対してまで mapc を推奨するのは完全に場違いだと思う。
簡単な例だとこれ：

(mapcar (lambda (e) (1+ e)) '(1 2 3 4 5))
=> (2 3 4 5 6)

(mapc (lambda (e) (1+ e)) '(1 2 3 4 5))
=> (1 2 3 4 5)

206 = :

マップクって響きがかっこわるいから使いたくない。

207 = :

>>202
・mapcarは新しいリストを生成するので、副作用のために適用する場合、戻り値を作るのがムダ
・その理由から、変換の場合はmapcar、副作用のために適用するにはmapcという慣習ができている。これに従うことで書く側の意図を示唆できるし、また読む側もそれを期待するので慣習を無視した利用は混乱の元。

209 = :

R5RS schemeのcutもどき
(defmacro foo:cut (&rest args)
(loop with arity = (count '<> args)
with ret-args = (loop for x from 0 below arity
collect (intern (concat "foo:cut-arg" (number-to-string x))))
with ret = (list 'lambda ret-args)
with form
for x in args
if (eq '<> x)
collect (pop ret-args) into form
else
collect (cond
((and (consp x) (eq 'quote (car x)) (functionp (cadr x))) (cadr x))
(t x)) into form
finally (return (append ret (list form)))))
(apply (foo:cut '+ 1 <> <>) '(1 2)) ; => 4
あとこれに引数がマクロ展開できる式なら展開するものを組込めば一応使えるものになるだろうと思う
そんなものどこで使うのとか以外の突っ込み希望んう

211 = :

loopマクロ凄いな

215 = :

俺、EmacsでOS作るよ。

216 = :

頑張って!

217 = :

末尾再帰をループに展開してくれるプリプロセッサが欲しい
というか新しいEmacsの実装の方が欲しい
shared object使用可、lexical scope、準拠度が高いcommon lispほげほげ

218 = :

素晴らしいね! 頑張って!!

219 = :

俺が死ぬまでには完成させるよ多分

222 = :

変数sが「空文字列じゃない」か判定する時に、

(not (equal "" s))

って書くのがダサい気がするんだけど、もっと綺麗な書き方ない？

224 = :

(defsubst empty-string-p (str)
(not (equal "" str)))
って定義しchinaよ

225 = :

それぐらい標準でありそうなのにね。

自分のElispならマナー的に関数名の頭にElisp名つけるから、長さは変わらなそうだ。
初見分かりにくいし。

227 = :

やっぱそういう関数はビルトインではないのね。
>>224 みたく自分で定義するしかないっぽい。ところで、
(not (equal "" s))
と
(< 0 (length s))
はやっぱり、前者の方が処理速度は早いよね？

228 = :

(if [condition] [then] [else]...)

で condition と then の文が同じ時って多くない？
バッファ・ウィンドウ・プロセスとか作ろうとする時って
既に存在してたらその型の値を返し、無かったらnilみたいな関数が多いから。
let とかでまとめてやろうとすると
[condition] と [then] の二重表記もモヤっとするよな。
ラップ関数作るのは簡単だけど、unless, when プラス through ぐらいは欲しかった。

229 = :

unless あるじゃん。

>>228
> で condition と then の文が同じ時って多くない？
具体的にどういうコード?

231 = :

え？

232 = :

そもそもなんで
(if [cond] [cond] [else])
なんて書くのかわからん。

233 = :

同じっていうより
conditionを評価して得られたものをthenで使う場合は割とあるかも

(when (get-foo)
(process-foo (get-foo)))

こういうの
onlispで_をconditionを評価して得られたものに束縛するみたいなマクロがあったから
あれを使えばいいんだろうか
programming gaucheで紹介されてた例のようにkeyword使って
(if-bound [cond] [then] &optional [else] :bound _temp)
みたいに束縛されるシンボルも指定できるようにするとか

こういう場合は関数よりマクロですよ

235 = :

>>229, >>232

(let ((process-name "a-process")
(process (if (get-process process-name)
(get-process process-name)
(start-process process-name "*TEST BUFFER*"))))
みたいな感じ。
でも or を使うというのは盲点だった。

(let ((process-name "a-process")
(process (or (get-process process-name)
(start-process process-name "*TEST BUFFER*"))))

でいいのか。230あたまいいな。

236 = :

インデントくずれたけどきにしないでくれ

237 = :

それ let じゃダメじゃね?

or 使う例はよくある。
たまには人のも読んでみ。

240 = :

あった、コードの読者がOnLispを読んだことがあるという前提ならlet使うより見やすいかも
もちろん適当なプレフィックスを付けた方がいいけど
(defmacro aif (test-form then-form &optional else-form)
`(let ((it ,test-form))
(if it ,then-form ,else-form)))
;; 例
(aif (current-buffer) (buffer-name it))

あと""の検出なら(zerop (string-bytes s))というのもある
equal使うよりは速いはず(equalはstringを比較する場合string-bytesのルーチンを使ってる)
リストを辿らんから多分length使うのよりも速い
実際は殆ど違いは無いけど

241 = :

>>240
これもおいしいな。

242 = :

>>240
> リストを辿らんから多分length使うのよりも速い
> 実際は殆ど違いは無いけど
どう見ても length の方が速そうだが？

243 = :

>>242
ソースは軽くしか見てないけど(Cよくわかりません><)、それぞれの実装が
string-bytesは実質Lisp_String構造体のポインタ経由で長さを保持する組み込み型メンバを返してるだけ
lengthはループ回してて、ループ毎にポインタを参照してる
それなら前者の方が速くなるのは予想できない？
間違ってたら指摘頼む

244 = :

>>243
俺の見ているソースとは全然違うようだ

245 = :

ごめんなさい俺の方が間違いでした

見直したらlengthの方が速いようでした
どちらもSBYTESマクロを使っているんですが
型を確認するときにstring-bytesはCHECK_STRINGを使って(これは内部でstringpの呼び出しがある)のに対し
lengthはSTRINGPマクロ(キャストしたものにビットマスクかけてで型情報を取得し定数と比較するだけ)
を使っているという違いがありますね

嘘情報すんませんでした

246 = :

そんなに落ち込むな。

それでも僕らはEmacsを使いつづける。違うかね？

248 = :

>>245
もっとよく見た方がいいぞ

249 = :

defsubst の適切な使い場所って、C++ の inline 関数で定義すべきところ？
具体形に defun ではできて defsubst では定義できない関数ってある？

250 = :

バイトコードから直接呼び出される関数(length)か、
Ffuncall経由で呼び出される関数(string-bytes)かの違いの方がよっぽど効いてくると思うが。