OnLispJa
『On Lisp』
野田さんのサポートページが本格稼働するまで、こちらにも仮に情報を載せておきます(hmorita)。
On Lisp邦訳サポートページ
http://www.asahi-net.or.jp/~kc7k-nd/
第3刷は9月半ば出荷予定です。反映したご指摘はコメントアウトしました (hmorita, 2007-08-31)。
おかげさまで第3刷が内定しました。8/20..21くらいには要修正点を確定させて、可能な範囲で対処したいと思います。何かお気づきの方はお早めにお知らせください (hmorita, 2007-08-16)。
増刷の手配をしました(2007-04-04)（第1版第2刷。4月末か5月頭には流通に載るかと思います）。緊急だったので確認・反映できたのは一部でしたが、お気づきの点は引き続き共有していただけるとありがたいです(hmorita, 2007-04-08)。
みなさんありがとうございます。今日いっぱいくらいで修正箇所をまとめて、野田さんと相談のうえ印刷所に渡します(hmorita, 2007-04-03)。
なんだか増刷しそうな気配なので、誤記その他を見つけた方は至急お知らせください。直せるものはできるだけ直します(hmorita, 2007-03-29)。
目次
書誌情報
![[image]](http://ssl.ohmsha.co.jp/cover/978-4-274-06637-5.gif)
Paul Graham 著 野田開 訳
オーム社より2007年3月23日刊行、定価：3990円(本体3800円＋税)
Amazon
正誤表
第1版第1刷
- p.11 l.1 (Mさんによる指摘)
LispはLispプログラムを作り上げるブロックであり，
関数はLispプログラムを作り上げるブロックであり，
- p.210 図15.3 (編集部内での指摘)
図15.3 Common Lispの関数をon-cdrを使って定義した例
図15.3 Common Lispの関数をon-cdrsを使って定義した例
- p.59 l.16
ソースコードでは, そういったシンボルは縦棒の間にあるか, "￥"が文字の前に付いていなければいけない：
ソースコードでは, そういったシンボルは縦棒の間にあるか, "＼"が文字の前に付いていなければいけない：
- p.54 ll.12-14 (leque, 2007/04/02 10:51:47 PDT)
リスト内の要素に完全な順位を定義する述語を提供するかどうかは呼び出し側次
第だ．そうでなければ要素の並び順は結果に影響し，most と同様，等しい点が出た
ときには最初の要素が返される．
リスト内の要素に全順序*1を定める述語を提供するかどうかは呼び出し側次第
だ．そうでなければ要素の並び順は結果に影響し，most と同様，タイが生じたとき
には最初の要素が返される．
*1 訳注：数学用語で，ここでは「異なる2 要素には必ず大小いずれかの関係があり，タイが生じない」
ことを指す．
第1版第2刷
- p.19 l.12 (leque)
捉えづらいバグ
見つけにくいバグ
- p.19 l.15 (leque)
Common Lispがレキシカルスコープを持つせいで
Common Lispがレキシカルスコープを持つ持つために
- p.22 l.15 (leque)
λ式で関数を定義したとき，
λ式で関数を定義すると，
- p.25 脚注2 (leque)
後者ではしないことがわかっている．
後者ではこれをしない．
- p.54 l.20 (leque)
第3引数で与えられた関数で終わって，
第3引数で与えられた関数で終端が定められ，
- p.64 l.5 (crane)
complementは述語p@をとり
complimentは述語pをとり
- p.75 l.6 (leque)
#'addp
#'oddp
- p.76 l.17
以上よりrfind-ifはoddpによって以下のように表現できる：
以上より，例えばoddpを渡したrfind-if は以下のように表現できる：
- p.77 l.13 (leque)
マクロの導入後，第15章で、～もっと豪華な器で扱う．
マクロ導入後の第15章で，～もっと豪華な器と共に扱う．
- p.86 ll.28-29 (leque)
ちょうどロシア人形の中に別の人形が入っているようなものだ．
ちょうど中に別の人形が入れ子になっているロシア人形のようなものだ．
- p.91 ll.28-29 (leque)
ここではマクロとして復活させる
さて方法とは：
ここではマクロとして生まれ変わらせる
その方法は：
- p.93 ll.18-20~ (leque)%
複数の式を本体として持つ～複数の引数が本体にまとめられ，本体が展開形の中に～
複数の式を本体(body)として持つ～複数の引数がbodyにまとめられ，bodyが展開形の中に～
- p.112 l.5 (leque)
驚いたことに第5番目と第6番目の用法は，意図せずに使われたときは，変数捕捉の問題を引き起こす．
問題なのは第5番目と第6番目の用法で，これらが意図せずに行われると変数捕捉と
なる．
- p.135 l.22 (leque)
プログラムに生成されたコード
プログラムによって生成されたコード
- p.148 l.16-17 (leque)
when-bindはパラメータリストの分配の例として既に7.5節で扱ったのでp.97で説明されている．
when-bindは7.5節でパラメータリストの分配の例として扱ったもので，p.97で既に説明した．
- p.163 l.8 (H.MIZUNO?)
(list wxyz))
(list w x y z))
- p.175 l.2 (leque)
効率的なプログラミングを励行
効率的なプログラミングを奨励
- p.176 l.6 (leque)
それぞれ代入すべき値のリストだ．
それぞれ束縛すべき値のリストだ．
- p.176 ll.11-12 (leque)
一般の場合では，代入すべき値の3番目に2番目への参照が含まれる...などということがあるので，束縛にはlet*を使うべきだ．
一般の場合では，束縛すべき値の中でそれより前に束縛された変数を参照してよいので，束縛にはlet*を使う．
- p.185 l.5 (leque)
済ませることができた．
済ませることができる．
- p.190 l.5 (leque)
0から1までのn個の値を
0以上1以下のn個の値を
- p.208 l.11
lrecを使えば，次の関数our-everyを，
lrecを使うと，次の関数our-everyに，
- p.208 l.17 (leque)
例えばoddpに適用して呼び出すのは，
oddpを渡して呼び出す例は，
- p.212 ll.25-31
また次のrfind-ifの，～例えばoddpへの適用は，こうして表現できる．
また次のrfind-ifに，～oddpを渡して呼び出す例は，こう表現できる．
- p.221 図16.2 (y.takenaka)
defmacro
(defmacro
- p.274 l.1 (leque)
トップレベルでは*cont*の値はidentityだ．
トップレベルでは*cont*の値はvalues であり，
- p.274 ll.5-6
=values式は等価な次の式に展開される．
=values式は次と等価なコードに展開される．
- p.336 l.13 (leque)
関数repが呼ばれて
関数rep_が呼ばれて
- p.341 ll.28-29 (leque)
その実装では必ず終了することが保証されていない．
その実装では終了することが常に保証されているわけではない．
- p.346 ll.23-24 (leque)
最も基本的なカットはgreen cutだった
minimumで使われていたカットはgreen cutだった
第1版第3刷
- p.23 l.17 (山本さんによる指摘)
nameは次のような関数と等価な関数を参照する：
<名前>は次のような関数と等価な関数を参照する：
Q and A
- (2007/03/29 18:10:51 PDT): 誤植情報じゃないんですが，ページに端にあらわれる†(dagger)は何をあらわしているのでしょう．(どこかに凡例があるのかな．．．)
- 小口側余白のダガーは，巻末の後注から参照されている箇所に付いています．
（迷ったのですが，原書に凡例がないのは意図的だと考えて，日本語訳でも凡例は追加しませんでした．）
(hmorita, 2007-03-30)
- koguro(2007/03/30 05:12:34 PDT): 細かいことですけど、索引をみると"do"は100ページとありますが、doについての話題は99ページから始まっているように見えます。
- 原書索引でdo*がp.97でdoがp.98なのを見て，疑問に思いつつも文脈上それに合う位置を探して指定した覚えがあります．(hmorita, 2007-04-01)
- crane:索引：人生の意味 201 とありますが 200 の誤り？
- p. v l.21（原著の段階からなので誤りとは言えないかも）
X Windows と
X Window System と
- X Windows (X Window System)とUnix (UNIX)とLisp (LISP)は検討の末「正しくない」原書の表記のままにしています．
- p.12 l.6-7 (leque, 2007/04/02 10:51:47 PDT)
「しかし Lisp はあるデータ型を提供するが、これは最初は衝撃的かもしれない： 関数だ」
（原文： 「But Lisp supports one data type which may at first seem surprising: the function.」）
の which は限定用法なので、
「しかし Lisp は初学者には衝撃的とさえ思えるようなデータ型を提供する： 関数だ。」では？
- これはママとさせてください（ご指摘の意図はよく分かります）．
- leque(2007/04/14 21:40:45 PDT): うーん、それはそれとしても、これだとコロンの用法上、「衝撃的かもしれない」と「関数だ」が同格のような感じに見えてしまいます（もともと日本語文の意味がよくわからなくて英文を参照したのでした）。
- p.4 l.22(leque, 2007/04/04 10:07:24 PDT)
「まぐさ石」というものを寡聞にして知りませんでした。よく知られたものなんでしょうか。
- ここは訳が難しくみなで悩んだ末、原文を生かしてまぐさ石というなじみのない言葉を使う代わりに、意味を類推できるよう説明的な形容詞を補うことにした覚えがあります。
- leque(2007/04/14 21:40:45 PDT): なるほど。個人的には訳注があるとうれしいと思いました。
- p.92 l.24(leque, 2007/04/05 07:50:43 PDT)
「猫の振る舞いを描写した while ループ」
（原文： a while loop describing the behavior of a cat）
「猫の振る舞いを記述した while ループ」
- p.125 l.14(leque, 2007/04/05 07:50:43 PDT)
「(b) マクロに渡された引数が束縛または評価される骨格の一部にそのシンボルが束縛されている。」
（原文： (b) it is bound by a part of the skeleton in which arguments passed to the macro are either bound or evaluated.）
「(b) マクロに渡された引数が束縛または評価されるような骨格の一部でそのシンボルが束縛されている。」
- p.115 の do ループの説明と p.116 の while マクロの説明で、
「. <コード本体>」となっていますが、このピリオドは意図したものでしょうか？crane
- p.176 脚注 (leque, 2007/04/12 11:42:57 PDT)
「汎変数に複数の値を蓄える（これまでのところ実現されていない）可能性を提供するためだ。」
原文： to provide the (so far unconsummated) potential to store multiple values in generalized variables
「（今のところ実現されたことはないが）汎変数に複数の値を蓄えられるようにするためだ。」（ちょっと意味がとりにくい気がしました）
- p.96 ほか (leque, 2007/04/14 21:40:45 PDT)
「destructuring」の訳語を「分配」とすることにすこし違和感があります。destructuring-bind の lambda-list が単純なリストである場合はよいのですが、入れ子のリストになっているような場合も考えると、「分解」「脱構造化」といったような、構造（structure）を意識したような訳語の方がしっくり来る気がします。
- これはGuy Steele本の和訳で採用されていた訳語に統一した結果です．ところでせっかく仔細にコメントをいただいているのに，単純なものしか目を通しておらず，申し訳ありません．いずれじっくり検討させていただきます．（野田）
- (leque, 2007/04/16 20:00:34 PDT): なるほど、そうなんですか。 Steele 本もきちんと確認すべきと思っていたのですが、手許になかったので怠けていました。「On Lisp」の和訳は全体にこなれていて、すごく助かっています。
- p.71 l.20 (yagiey?, 2011/01/15 11:58:32 PST)
「その時点でのリストのcdr部と」は「その時点でのリストのcar部と」ですかね？修正済みでしたら申し訳ありありません。（第1版第1刷）
- p.48 l.12 (marui, 2024/02/22)
「ある関数がリストの一連のcdr部に対して」は「someがリストの一連のcdr部に対して」でしょうか。（第1版第2刷）
Last modified : 2024/02/22 06:03:39 UTC