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

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

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

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

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

個人的に戻り値に変化を加えることが目的の場合、 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)

別に mapcar が非推奨なんてことはない。
>>202 の警告は、 mapcar の返り値を使ってる様子がないから、代わりに dolist や mapc を推奨してるだけ。

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

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

[参考になる+7]

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
あとこれに引数がマクロ展開できる式なら展開するものを組込めば一応使えるものになるだろうと思う
そんなものどこで使うのとか以外の突っ込み希望んう

ム板のelispスレでやれ

loopマクロ凄いな

ansi-termで日本語manが化ける
何とかならんか

Haskell Emacs って可能性ないのかな。

>>212
つwoman

俺、EmacsでOS作るよ。

頑張って!

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

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

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

byte-ope.el楽しす

どんなに楽しいのかと思って捜してみるとだな
http://www.google.com/search?num=50&hl=ja&q=byte-ope.el&btnG=%E6%A4%9C%E7%B4%A2&lr=lang_ja
気になる…。

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

(not (equal "" s))

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

>>222
if, unless を使い分けるとか出来るだけ not を使わない。

変数sを自分のプログラムで定義してるなら、使い方にもよるが
空文字列をnilとして扱うようにする。ぐらいしかない。

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

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

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

s が文字列という前提なら
(< 0 (length s))
とか？

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

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

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

unless あるじゃん。

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

(if [cond] [cond] [else]) == (or [cond] [else])
じゃないっけ

え？

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

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

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

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

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

(or (zerop (length str)) ...)
とか使う。

システム標準 (conventionでもいい) で "" を表す定数 (NUL とか？) があれ
ば、そっちを使いたい。

>>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あたまいいな。

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

それ let じゃダメじゃね?

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

let* だな。しかも start-process の引数間違ってるし。

釣ってこよう。

orってnon-nilだったformの値返すのか。
すっかりnil/tなもんだとばっかり思ってた。

あった、コードの読者が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使うのよりも速い
実際は殆ど違いは無いけど

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

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

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

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

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

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

嘘情報すんませんでした

そんなに落ち込むな。

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

[感動した+3]

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

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

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