Old/sampou.org/Haskell_Report

Haskell_Report

Haskell:Report


“Haskell 98 language and libraries: the Revised Report” の日本語訳Haskell 98 言語とライブラリ にツッコミをいれるページ。日本語訳に対する意見、感想、それに、誤訳、誤字、脱字、 がありましたら、ここに書き込んでくださいませ。


日本語訳についての意見、感想、誤訳などの指摘


4.5.1 依存性解析

 > 次のどれかの場合、同じ宣 言グループに属する。
 < 次の*どちらか*の場合、同じ宣 言グループに属する。

 > どちらも同じパターン束縛により束縛される。
 < *それらはある同一の*パターン束縛により束縛される。*または、*
 
 この文の意味は (x,y)= ... の x と y のような関係のこと?

 > 必要とされる依存性解析を捕捉する。
 「捕捉」以外のよい言葉がないか?

 > (d2 内の認識子が d1 内で無束縛ではあらわれない場合)
 < (d2 内*で束縛される識別子は* d1 内で無束縛ではあらわれない場合)
 
 variable ではなく identifier なのは意図がある?
 d1,d2 はそれぞれ宣言グループを表している?

4.5.2 一般化

 > 制約のこの集積の中にあらわれる型変数は被制約型変数とよぶ。
 < 制約のこの集積の中にあらわれる型変数は被制約型変数と*よばれる*。

 > それらの型シグネチャの文脈はその型変数の名前の付け替えと同一でなければならない。
 < それらの型シグネチャの文脈は*、型変数の名前の付け替えだけの差異は無視した上で、*同一でなければならない。

 > ある型の文脈は型変数あるいは1つ以上の型への型変数の適用しか制約しない。
 < ある型の文脈は*1つだけの*型変数あるいは1つ以上の型への型変数の適用しか制約しない。
 
 「1つ以上の型への型変数の適用」とは (Eq (f a), Functor f) の (f a) みたいなこと?

 > このリスト型で同等性がとれる場合でさえも
 < *この例のような*リスト型で同等性が*とれられる*場合でさえも

 > リスト上の Eq に対応するインスタンス宣言を用い
 < *リストの Eq に関する*インスタンス宣言を用い

 > C (m t) という形式の制約が必要であることを示す例がある。
 < C (m t) という形式の制約が必要であることを示す例*をあげよう*。

 > どのインスタンスとも同じように、単純なな文脈を持たねばならない。
 < どのインスタンス*もそうであるように*、*単純な*文脈を持たねばならない。

 > すなわち、静的エラーとなる。
 < *したがって*静的エラーとなる。

RHG でのやりとりを受けて、kindの訳語を類から種に変えないの?

kind の訳語について (nobsun–2006/09/21 13:10:37 JST)

原文では,型の型のことを kind と表現している. 拙訳では「類」という訳語をあてたのだが,「この訳語はいかがなものか」と いう議論.

「類」を使ったのは,

  • 数学用語では
    • Stirling number of the first kind: 第1種スターリング数
    • Chebyshev polynomial of the first kind: 第1種チェビチェフ多項式

のように,「型の型」とは直接結びつかないように見える例しか探せなかった.

  • 「種」と書くと,乱数の seed をイメージしてまうような気がした

という,要するに訳者の不勉強による理由. どうやら,型理論の分野では「種」という訳語を使うらしいので,少しだけ調べ てみたら,

では「種」という訳語が使われていた.

では「種類」という訳語が使われていた.やっぱり,「類」じゃあマズいか.


修正済

(2009/03/13 14:58:17 JST 修正)

4.5.5 単相性制限

 > 規則 1. 与えられた宣言が
 < 規則 1. 与えられた宣言グループが

 > (型変数は、いくつかの型クラスに属さなければならない場合、制約をうけることを思いだすこと。
 < (*型変数が被制約とは、ある型クラスに属さなければならないという意味である*ことを思いだすこと。

 > 規則 1 は二つのどちらも非常に重要な理由により必要である。
 < 規則 1 は二つのどちらも非常に*微妙な?油断できない?subtle?*理由により必要である。

 > 規則 1 は不要な再計算を防ぐ。
 < 規則 1 は*予想外の*再計算を防ぐ。

 > len は一度だけ計算されるべきだものと見られるが
 < len は一度だけ計算される*べきもの*と見られるが

 > なぜなら曖昧さを引き継いでいるからである。
 < なぜなら*内在的に?本質的に?inherently?*曖昧だからである。

 > sを使用するのは、どの多重定義の時かを決定することはできず。 
 < sを使用するのは、どの多重定義の時かを決定することはできず*、*
 (この文の意味するところが原文を読んでもわかりません)

 > いかなるインポートされたモジュールによってでは 決定されないと主張するものである。
 < それをインポートした方のモジュールでは 決定されないと主張するものである。

 > ユーザは完全な多重定義を保持するために型シグネチャを付与することを注意深くなければならない。
 < ユーザは完全な多重定義を保持するために型シグネチャを付与すること*に*注意深くなければならない。

 > 標準プレリュードをこのことの例を多く含んでいる。
 < 標準プレリュード*は*このことの例を多く含んでいる。
  • 提案していただいた訳とはすこし違うところもありますが、修正しました。ご指摘ありがとうございます。–nobsun

(2009/03/09 11:55:19 JST 修正)

モナドの伝統的な記法?

意味からすると「3.14 do 式」で伝統的だと説明されている式は逆ではないでしょうか。 つまり “to be written in a more traditional way” がかかるのは前者(>>=の方) ではないかと。

勝手に語を補ったイメージとしては、“It allows (that) an expression (such as A …) (is) as B.” のような解釈かなと思ったのですが…。

 原文) It allows an expression such as A
 to be written in a more traditional way as: B
 
 旧) 次のような式が許されている。
 これは、伝統的な書きかたでは B となる。
 
 修正案) これにより、伝統的には以下のように書かれていた式は、
 以下のようにも表わすことができる。
  • (2008/07/20 17:39:04 JST): conventinal と traditional が対応しているのではないかと 考えてそのように翻訳しました.do式 = traditional という気分なんです. つまり,do式の構文は,伝統的な命令型言語の構文に似ているという気分... いずれにせよもうすこしこなれた日本語の方がよさそうですね.もうすこし 考えてみます.–nobsun

  • (2009/03/09 11:55:19 JST) 日本語をすこし修正しました.


Last modified : 2009/03/13 23:40:02 JST