正誤表.案

訳者・編集者の確認を受けていない提案

訳が気になるところが後半に多くありました. 中でも, 内容の理解に影響しそうなものをピックアップします. もしこちらの勘違いだったらごめんなさい. -- ひ

• ありがとうございます。正誤表 に反映したものは 旧・正誤表.案 に移動します。

p.114 脚注3

数の長さ → 数の大きさ(size) / 多い → 大きい. あと up to and beyond 2^262144 の訳は OK?

p.119, 10.5 の直前

ある状態を試して → 何らかの条件を{検査して|テストして} (test some condition)

p.122, 2 行目

それぞれの部分文字列を厳密に比較できる
↓
片方ないし両方の文字列の比較(範囲/対象)を部分文字列に制限することができる (restrict the comparison to a substring)

p.122, 最後の段落

…や、文字の両端 → …、文字列の片端や両端

p.184 後半, 「Lisp以外のほとんどの…」

原文ではこの段落でmessage-passingという用語を定義している. その一文をカットして, 以後のmessage-passingをのきなみ 「JavaやC++のシステム」等と言いかえているのはなぜでしょう?

• 原文におけるmessage-passingの定義がビミョーだからです。文字通り訳すと「メソッドが特定のオブジェクトに対して呼び出され、そのオブジェクトのクラスによって実行されるコードが決定される」ことが「message-passingと呼ばれる」となるのですが、これはSmallTalkにおけるmessage-passingの意味とは異なります。しかも、SmallTalkにおけるmessage-passingをCLOSと対比させると話がおかしくなります。本文の趣旨では、対比の対象は「Java/C++風のオブジェクト指向におけるメソッド呼び出し」です。それを原文では「message-passing」と「名づけている」という解釈も可能ですが、message-passingという用語本来のSmallTalkにおける意味との誤解を避けるために「メッセージパッシング」という訳語は当てていません。 --編集部

p.185 中ほど

意味がない → 意味をなさない (don't make sense; 「意味がない」という訳だと「無価値・不要」のニュアンスを感じてしまう).

p.186 後半

「1つの…しか持たず」と書きながら直後に「すべて」と 言われてとまどう. メソッドを複数想定していることを伝えるために, 「特定子がすべて」 → 「どのメソッドでも特定子が」と補ってはいかが?

p.190 脚注 9

…あまり多くない
↓
高速なCommon Lisp処理系の開発に際して、 これを効率化するために多くの(quite a bit)努力がなされた

p.190 脚注 10

実際に → 実は? (英語はわかりませんが話の流れから)

p.192, 中ほど

特殊関数の実装 → 総称関数(generic function)の実装

p.194 冒頭

「むしろ」は文脈に合わないのでは(原文 instead)

p.202 後半

コードの外側から → 外側のコードから ?

p.207 末尾

スロットオプションが異なれば別のものと見なす
↓
スロットオプションごとに異なった扱いがなされる ? (:initform オプションはあんな扱い, :initarg オプションはこんな扱い)

p.209 前半

特定化という概念 → 特定度(specificity)という概念

p.226 前半

共通のフローに → 共通の欠陥(flaw)に

p.227 前半

スロットも…特定化される → スロットも…指定される(specified)

p.228 後半

(condition-type ([var]) code) はイタリック

p.229 前半

error-clauseはNILを返す → エラー節(error clause)はNILを返す (この改変はわざと?)

p.230, 19.4 の第2文

place … into restarts は, 「エラーから再起動へと復帰する」ではなく 「エラーから復帰するコードを『再起動』(restarts)に置く」では?

p.230, 後半 (2 箇所?)

skip-log-entryの再起動 → skip-log-entry(という名の)再起動 (skip-log-entryを再起動するわけではない)

p.231, 図の直前

トップレベル関数から…を経て…に至るまで、実際にエラーが通知されるパスは
↓
トップレベル関数である…から、実際にエラーが通知される…に至るまでのパスは

p.232, 下から 3 行目

ときに → 場合 (または, せめて「ときは」)

p.233, 冒頭

…のなかには…スキップしなくていいものもある
↓
必ずしもすべての…が…スキップしたいとは限らない (「別のことをしたいアプリもある」という話だから「しなくていい」は変)

p.233, 第一段落末尾

分かればいい → ほしい

p.233, 下から 3 行目

skip-log-entry を削除 → skip-log-entry 再起動を削除

p.234 後半

「…エントリを含んだログ解析アプリケーション」とは何? 「ログ解析アプリケーションにおいて、…だったとしよう」では?

p.234 後半, 「もっと大きなアプリケーションであれば…」

文頭の「そうしておくと」を訳し落とさないでほしい. parse-log-entry をさらに書きかえたりしなくても, そのままで 「もっと大きなアプリケーション」の要請にも応えられる, というのが肝心な点. 接続詞を落としたせいでこの点が不明瞭になってしまった.

p.235 コラム

一目を置く人物 → 一目置かれる人物 ?

p.249 脚注 13

LOADが戻った後にIN-PACKAGEフォームでファイルをロードしても*PACKAGE*の値には
↓
IN-PACKAGEフォームを含むファイルをロードしても、 LOADから戻った後の*PACKAGE*の値には

p.249 脚注 13

「LOADの残りのコード」とは何? ロードされるコードのこと?

p.264 下から 2 行目

「*PACKAGE*に」はおかしい. 「*PACKAGE* の値が以前とは異なるものになっている状況で」の意味のはず.

p.277 前半

実際にループの一部になるコード → 実際は(実質的には?)ループの一部であるコード ?

• 修正するとしたら「実際に→実質的には」

p.278

「デフォルト値を提供する。」に続く二文が矛盾して聞こえる. せめて, 「デフォルト以外の値を返すこと『も』できる」にしては?

• 「も」のほうが日本語としてはベターかな。間違いではないので「正誤」にはせず。

p.287 下から5行目

よく見たら, 訳文の「ある特徴が…ではなく」は原文にない? この独自挿入はしない方がよいのでは? 「○○でなく××」と言いながら, ○○と××の違いがはっきりしない.

• あるほうが分かりやすいと考えます。

p.289

likelihood は「尤度」では (統計用語だとしたら)

• 「……」内全体が、いわゆる尤度に相当では？なので、ここは「可能性」のほうが適切かと。

p.300 後半

取り出して設定 → 取り出したり設定したり

• 修正するかどうか？

その次の文

特定的な → 特定の／ なったら → なったので

• 前者は誤訳なので修正。後者は間違いではない？

p.352, 4 行目

最上位に…をロード → 最上位にある…をロード (?)

• 「最上位で (load "INSTALL.lisp") する」としてしまうほうが分かりやすい？

p.355, 脚注 9

読みやすいものになるのは大きい → いくらか読みやすいものになる (?)

• 修正するかどうか？

p.374, 中ほど

トラック番号がASCIIで表現されるタグIDもあれば…タグもある。
↓
ID3タグ中のトラック番号は、 番号のASCII表現で格納されている場合もあるし、…の場合もある。

• これは正しい訳では？

p.396, 中ほど

…という制約をアプリケーションに課すことになる
↓
アプリケーションに実際に課される制約は…だけだ

p.399, 前半

インデックスが範囲に入る → インデックス 0 が(有効?)範囲に入る

次の文

再生した後で…になった場合は、曲の追加で
↓
再生し終えて…になった場合も、(その後また)曲を追加したら

p.399

列の名前と値のリスト → 「列の名前」と「値のリスト」

同文後半

そのリストの値を持つ指定した列の曲が…されてしまう
↓
指定した列の値がそのリストに属しているような曲を…する(ことが要請される?)

p.404, 前半

1行のテーブルを持つ → テーブルの1行に対応する

p.406, 本文最終行

「:song列」 → 「:songの行」

p.411, 後半

MP3クライアントは以下のURLになる。
↓
MP3クライアント{に対して|で}は以下のURLを指定(設定)する。 (?)

同, 「スタートページのブラウザを指すURLは…」

ブラウザにこの URL を入力しろということでは.

p.415, 末尾

リストのシンボルの → リスト中のシンボルの

p.421, 末尾

意図的に組み込まれたLispコードを評価する
↓
埋め込まれたLispコードを有意義に評価する／ 埋め込まれたLispコードに対して意味ある評価を行う ??

p.429, 後半

FOOフォームのリストを…インスタンスで…コンパイルする
↓
html-compilerのインスタンスとともに各フォームに対してprocessを 呼び出すことにより、FOOフォームのリストをコンパイルする

p.430, 前半, 「process-sexp-htmlへ渡されない…になる」

「process-sexp-htmlへ渡されないフォームは、FOOコンスフォームの文法に マッチしないリスト、および、キーワードでないシンボルだけだ。 自己評価型でないアトムは後者だけだ。」みたいな感じ?

p.431, 前半

遭遇したときも → 遭遇したら (文意を追うためにはクリティカルと思う)

p.432, 冒頭

総称関数…完了だ
↓
すべての仕事は、総称関数op->codeの引数opを…特定化したメソッドによってなされる

次の文

計算済みの → (その場で?)計算された (let であらかじめ計算しておいてから変数を埋め込むんじゃなく, 式をその場に埋め込めるのがここのミソ)

p.435, 第 2 段落

さいごの方に一文訳し抜け? (This allows … to emit-html.)

p.436, 第 2 段落

特殊オペレータの名前を表す…への追加
↓
特殊オペレータ名(のシンボル)の属性リストにhtml-special-operatorの エントリー(登録?)を追加すること (短く「…名にhtml-special-operator属性を追加すること」と改竄したい気も)

p.436, 後半, 「define-html-special-operatorを使って定義しただけの」

この just は「だけ」じゃなく「まさにその, たったいま定義した」では?

p.439

attribute list と property list が訳文で区別できない. (場所によっては前者を HTML 属性と呼んでいる?)

p.439

マクロにおける2つの特色…使い分ける → (いま述べた)2種類のマクロ…区別する ?

p.440, 後半

1つのフォームかHTMLのマクロかのいずれか
↓
ある(片方の)フォームのHTML(の)マクロか、 別の(他方の)フォームのHTML(の)マクロか ??

p.440, 中ほど, 「どちらの展開形でも…」

マクロ名の(シンボルの)属性リストには、 html-macro属性の値としてマクロ関数を、 html-macro-wants-attributes属性の値として…真偽値を

p.442 のマクロ in-html-style の定義

展開すると何も残らないマクロ(展開時の副作用だけを目的としたマクロ)という 認識でよい? 訳注があるとうれしい.

p.443, 後半

Common Lispでマクロが → Common Lispのマクロで? (原文要確認)

p.451, code bumming

(1) 訳注は正しいですか? (2) p.451 の中ほど過ぎでは, 「コードバミング」は避けるべき悲劇のような 書きっぷり. でも次の段落ではそのコードバミングをうきうきと説明しはじめる. 何か変では. こうかな? 「…したら、(話は/問題は/我々のすべきことは) 『必要な仕事以外は(or 余計なことを)一切しないようコードを局所的に 最適化する』というコードバミングに行きつく」

p.452, 前半

aとbの値がどの型に保持されて → どんな種類の値がaとbに保持されて (ついでに, 「宣言されており → 宣言されているので」 「正しく認識することができる → 正確に知っている」)