F# ドキュメント翻訳向上委員会 †
F# は Microsoft Visual Studio 2010 に新しく搭載されるプログラミング言語です。
F# は正式リリースされて間もない言語であり、MSDN における公式の日本語ドキュメントでさえ、
その翻訳の品質は高いとはいえない状況です。
MSDN Visual F# (ja-jp) / MSDN Visual F# (en-us)
そこで、F# コミュニティの意見を取りまとめて Microsoft 社にフィードバックし、
ドキュメントの品質向上を図ろうという目的のもと、この Wiki は立てられました。
この Wiki は、誰でも編集できます。
F# ドキュメントの翻訳向上にご協力いただける方はぜひご参加ください。
お知らせ †
Gushwell さんのご厚意により、日本マイクロソフト MVP 事務局経由でフィードバックを行いました。
詳しくは、fsug-jp のディスカッションをご覧ください。
提案用語一覧 †
本委員会が提案する用語のリストです。
| 元の英語 | 現行の和訳 | 提案する和訳 | 備考 |
| statically typed language | 静的に型指定された言語 | 静的型付け言語 | 通例的訳語 |
| type safety | タイプセーフ | 型安全性 | |
| type inference | 型の推論 | 型推論 | |
| binding | バインディング | 束縛 | |
| first-class | ファースト クラス | ファースト クラス | |
| first-class status | ファースト クラスのステータス | ファースト クラスの身分 | |
| tail call | tail 呼び出し | 末尾呼び出し | |
| automatic generalization | 自動汎化 | 自動ジェネリック化 | |
| value restriction | 値制限 | 値制限 | 変更なし |
| constructed type | 構築型 | 構築型 | 変更なし。F# だけでなく .NET 全体で使われる用語 |
| offside rule | オフサイド規則 | オフサイド ルール | |
| lightweight syntax | 簡易構文 | 軽量構文 | 議論アリ |
| verbose syntax | 詳細な構文 | 冗語構文 | 議論アリ |
| pattern matching | パターン一致 | パターン マッチ | |
| active pattern | アクティブなパターン | アクティブ パターン | |
| partial active patterns | 部分的なアクティブなパターン | パーシャル アクティブ パターン | |
| tuple | 組 | タプル | |
| reference cell | 参照セル | 参照セル | 変更なし |
| discriminated union | 判別共用体 | 判別共用体 | 変更なし。議論アリ |
| case identifier | ケース識別子 | ケース識別子 | 変更なし。 |
| type abbreviation | 型の省略形 | 型略称 | 議論アリ |
| flexible type | 柔軟な型 | フレキシブル型 | |
| units of measure | 単位，測定単位 | 測定単位 | |
| computation expression | 計算式 | コンピュテーション式 | 議論アリ |
| intrinsic extension | 組み込み拡張 | 固有拡張 | |
| optional extension | オプション拡張 | 任意拡張 | |
| primary constructor | プライマリ コンストラクター | プライマリ コンストラクター | 変更なし |
| code quotation | コード引用符 | コード クォート | |
| splicing | スプライス | スプライス | 変更なし |
| lazy computations | 遅延計算 | 遅延実行 | |
コメント欄
なにかコメントがありましたらこちらへどうぞ！ლ(╹◡╹ლ)
参加者 †
- moonmile
- igeta
- taka-island
- lowlander
- のぶひさ
- arai
- zecl
- Gushwell
- yukitos
- deko_pon
and fsug-jp
作業用ツール †
F# ドキュメント カスタム検索 で「F#」を加えて検索すると、日本語 / 英語 MSDN から検索できます。
個別の用語についての議論 †
用語を提案するにあたり行われた議論のログです。
全般 †
lightweight syntax/verbose syntax †
- verbose syntaxは、通常はあまり推奨されない長ったらしい構文なわけですから、「詳細な構文」より「冗長構文」と訳すほうが意味通りでしょう。 -- lowlander?
- lightweight syntaxを「簡易構文」と訳すのは悪くないと思いますが、そのまま「軽量構文」と直訳してしまってよかったのではないでしょうか。私としては簡易構文と聞くと、一般的な記法を省略した(一般的ではない)簡易的な記法という印象を受けてしまいます。 -- lowlander?
- この 2 つは個人的には非常に難しいところだと思います。どちらを主ととるかですね。現行の F# では light 構文がデフォになりましたが、元をたどれば verbose syntax だったわけで。進化過程をとるか、現状のデフォをとるかで適切な訳への見解が変わりそうです。 -- igeta?
- lightweight syntax に関しては「軽量構文」がよいと思います。 -- igeta?
- たとえばですけど、「ワンライナーを書くには冗長構文を使用します」という文があった場合、なんとなく居心地が悪いんですよねぇ。 -- igeta?
- lightweight syntax は、C# の using statement で既に「簡易構文」の訳が割り当てられています。 -- moonmile?
- verbose syntax のほうは、XMLの構文で「冗長な構文」が割り当てられていますね。でも、確かに「ワンライナーを～」のくだりでまずそう。 -- moonmile?
- 「冗長構文」「軽量構文」を支持します。冗長構文は軽量構文のサブセットだと考えれば良いのではないでしょうか。 -- taka-island?
- C# using の件、おもしろいですね。using は構文糖と捉えられるし簡易構文で OK なのかなと。F# のについては、記述するコード全体に及ぶデフォルトの構文規則を“簡易”と呼ぶのが相応しいかどうかですね。 -- igeta?
- "冗長"ってちょっとネガティブなイメージがしちゃいそうですね。。「軽量化前」「簡易化前」の"もと"と考えて、基本構文とか原形構文とかどうでしょう。 -- のぶひさ?
- 僕もホントは“基本”とかって言いたいとこなんですが、、verbose なんですよねぇ、当てられてる単語が。とすると、超訳しないとすればもう“冗長”か“詳細”かしかないかなあという。なにか直訳と超訳の間くらいのイイ感じの意訳があればいいかなーとか思ったり。 -- igeta?
- verbose syntaxについては「OCaml由来構文」なんて呼んでいたりしましたが、「冗長構文」が的を得ているかなと思います。また、lightweight syntaxについては「簡潔構文」を提案します。冗長の反意語ですし、これなら一般的な記法を省略した(一般的ではない)簡易的な記法という印象も与えないと思います。どうでしょうか？ -- zecl?
- lightweight syntax と verbose syntax は相反するものではないでしょう。反意語であるかどうかはあまり重要でないように思います。 -- igeta?
- この場合における"冗長"と意味が近い言葉を探してみました。「冗語（剰語）」「冗句」などあるみたいです。冗語構文などにするとネガティブイメージは少し薄れるかも・・・？ -- のぶひさ?
- 軽量構文、冗長構文を支持します。事実上 lightweight syntax F#の標準であることを考えると、「冗長」という単語でネガティブなイメージになってもそれほど困らないと思います。 -- Gushwell?
- ネガティブさ以上に、冗長というと僕は Redundancy を思い浮かべるのですが、その点はどうでしょう？ -- igeta?
- 確かに。となると、直訳っぽく「冗語構文」「饒舌構文」とかかな。 -- Gushwell?
type abbreviation †
- 別名としてしまうと alias を思い浮かべてしまうので、「型略称」あたりがよいかと思います。 -- igeta?
- 別名と書いたの、私です。「型略称」の方が良いと思います。 -- taka-island?
- どうもです。とりあえず一覧表に反映しますね。 -- igeta?
- …と思ったらもう反映されてた(^^; -- igeta?
- 僕も「型略称」がいいと思います。 -- Gushwell?
computation expression †
- 「計算式」ではマズいだろうとは思うものの、適切な訳語が思い浮かびません。 -- igeta?
- そもそもはcomputeもcalculateも、どちらも日本語の「計算」という訳語に一緒にされていることが問題なんですよね。「計算」の類義語を手元の角川類語新辞典で調べてみると、
「算出」…計算して値を出すこと
「算用」…数を計算すること
「運算」…数式に従って計算すること
などがありました。自分としては、この辞書の説明を見る限りは、前者の2つは言葉は数値の演算のみを対象としている印象がありますが、最後の運算つは数値以外も扱う印象があります。computation expressionは、数値のみを対象にしているわけではありませんから、運算の説明のほうがしっくりきます。ただ、「運算式」ねぇ…あまり響きがよくないですね。 -- lowlander?
- うお、なんかすごいのキタ。なるほど、運算ですか。響きというか、耳馴染みがない感じですね（それを言うと弁別子も、ですが）。でも意味的にはしっくりくるような気がしますねー。 -- igeta?
- おそらく「Lazy Computations」を「遅延計算」にしているのが間違いで、他の言語と合わせると「遅延実行」あるいは「遅延処理」。それに「computation expression」を合わせると、単純に「式」あるいは「処理の表現方法」ぐらいな形が妥当かと。 -- moonmile?
- MSDNでも「これらの計算式を使用すると、モナドの便利な構文が提供されます」と書いてしまっているので、Computationを捨てて、「モナド式」とか「モナド表現」とか・・・。"モナド"はHaskellのおかげで知名度もありますし。ちょっと飛躍しすぎですかね。苦笑 -- のぶひさ?
- 逆に言うと、モナドを引き合いに出して説明しながらもしかしその機能名としてはモナドを使用しない、というスタンスなわけですから、和訳にモナドを使うのはちょっと適切でないように思えます。 -- igeta?
- 「Expert F#」において、モナドではなくcomputation expression(あるいはworkflow)と名付けられた理由が書かれていたのを思い出しました(P.232)。それによると、モナドという名前を採用しなかったのには以下の3つの理由があるそうです。
(1)以前、F#の言語デザイナたちとHaskellの言語デザイナたちが話をする機会があり、そのときにHaskellの言語デザイナたちは、モナドという言葉はぼんやりしていて人々を怯えさせるので、別の言葉を使うようにしたほうがいいかもしれないと話していた。
(2)imperativeな書き方が許されているため、モナドほど完全に副作用を追跡できない。
(3)computation expressionは、F#のquotationを使って構文木直接いじってをSQL文への変換するなど、Haskellのモナドとは別の使い方をする場合もある。
[2010-05-08追記]
私個人としては、今やモナドは(少なくとも関数型プログラマの間では)広く市民権を得ている概念だと思います。いずれにしても、computation expressionを自分で書く際は結局モナドを理解しなければならないでしょう。逆に背景にモナドという概念があるんだということが分からないと、computation expressionは珍妙で意味不明な構文にしか思えなくて混乱をきたすと思うのですが。 -- lowlander?
- 私の理解ではワークフローの基礎なる Sequential Expression と繋がっていると思います。これをDelay、Let、Bindなどへ展開してから実行される計算式を組み立てられるものを comupation expressionだと理解しています。
個人的には計算可能な式を組み立てるものという理解です。 -- arai?
- やっぱり"モナド"は含めないほうが良さそうですね。 "AsyncBuilder?"みたいな感じで定義しますし、「計算構築式」とか「計算構築表現」程度だとイメージを壊さないでしょうか・・・。build というワードを付加しちゃうのはやりすぎですかね。 -- のぶひさ?
- Sequence ExpressionとComputaion Expressionを別々に解釈するのなら、buildというキーワードを付加しちゃっても良いのではないでしょうかね。Sequence Expressionであれば、範囲オペレータのように宣言して即実行のようなイメージがありますし。これに対して、Delayを呼び出すことで構築された式を実行するものだと思うので。 -- arai?
- 「計算構築式」という訳語はよくイメージを反映していていいですね。 -- lowlander?
- 「計算構築式」、かなり良い訳だと思います。 -- taka-island?
- 個人的には、「コンピュテーション式」あるいは「コンピュート式」とカナ読みしちゃうのもアリかなと思います。 -- igeta?
- 「計算構築式」、絶妙ですね。とてもよいと思います。 -- zecl?
- 構築と言うと construct のイメージが強いように思うのですが、それと混同しないであろうと判断でき、かつ意訳をいとわないのであれば、「計算構築式」は非常によくできた訳語だろうと思います。 -- igeta?
- 「計算式構築」で良いと思います。今 F#2.0の仕様(RC)を読んでいて、computation expressionは式を構築するためにビルダーパターンを採用しているんだということを改めて実感した次第です。sequence expressionは、computaion expressionのようなビルダーではなくジェネレータを使った生成パターン(これはソースコードから読みました)になっていますね。 -- arai?
- えーと。「計算構築式」で決まりそうですが。あえて反対意見も出しておきます。
僕は前述のカナ読みか、あるいは「算計式」を推します。言葉遊び的ですが、それなりに意味も伴っているので。
それで、なぜ反対かというと。「計算構築式」という言葉は、ボトム アップ的というか、どう機能が実現されているか（How）にフォーカスしているように思えるためです。でなくて、それによってなにが実現されるか（What）、という面に重きを置きたいと思うのです。computation expression によって達成されるのは、統一的・一貫的な表記によるさまざまな計算です。どちらかというと、そういった面にフォーカスした訳語にしたいなーという。 -- igeta?
- ルー 大柴な感じもありますが（！）、コンピューテーション式は個人的にありかなと思います。 -- のぶひさ?
- 「計算式」でも「コンピュテーション式」もありかなと思います。その理由ですが、F# 2.0の仕様書では、6-4データ式(Data Expressions)の中で記述されているからです。つまり、データを表現する式の一つとして、Computaion Expressionが定義されているわけです。このことから、計算式というデータを構築するのが目的なので、説明の中で計算式というデータを作るという説明があれば良いのでは思う次第です。 -- arai?
- 「コンピュテーション式」ありだと思います。計算だとどうも数値演算を思い浮かべてしまいます。 -- Gushwell?
discriminated union †
- 代案です。「タグ付き共有体」とかどうでしょう。 -- taka-island?
- 思い切って「代数的データ型」ではどうでしょう。 -- taka-island?
- 「代数的データ型」は思いきりすぎかなぁと(^^; 「弁別子付き共有体」か「タグ付き共有体」どちらかがよいと思います。 -- igeta?
- 「共有体」というのは「共用体」の打ち間違いでしょうか？C言語のJIS規格であるX3010に倣うならば、unionの訳語は「共用体」が適切ではないかと思います(意図して使い分けていたのでしたらすみません)。 -- lowlander?
- ありゃ、打ち間違いです。僕は、「弁別子付き共用体」or「タグ付き共用体」推しです。 -- igeta?
- F#の文法として、「union」と「discriminated union」の区別がなければ、「共用体」あるいは「識別可能な共用体」で良いと思います。「discriminated」自体を形容詞で使っているので、無理に名詞化しなくてもよいかも。「弁別」だと意味が取りづらいので、通常の共用体と区別する場合は「タグ付き共用体」で逃げるとか。 -- moonmile?
- 「共用体」だけだと、C 言語的な共用体との違いが明確でなくなるのであまりよくないと思います。個人的には弁別子あるいは判別などの語を付けたいです。タグ付きでもいいんですが、割と超訳気味かなぁという嫌いも。 -- igeta?
- 英語で検索すると「discriminated union」あるいは「F# union」みたいですね。そうなると、対応としては造語的に「弁明付き共用体」とするか「F#の共用体」とするか。 -- moonmile?
- 私も「共用体」という言葉は単独で使わない方がいいと思います。 初めて聞いた人は一般的なプログラミング言語における共用体と誤解してしまうでしょう。 -- lowlander?
- discriminatedに対応する訳語としては、「弁別」「識別」などが考えられますが、広辞苑では
「識別」…みわけること
「弁別」…わきまえわかつこと
とあります。これのよると、弁別のほうが能動的に分類するというイメージがあるので適切かと思います。また、漢字源で字のなりたちを調べてみても、弁別の「弁」の旧字は「辨」で、刃物でふたつにわかつという会意文字だそうです。 -- lowlander?
- 用語としては、「弁別子付き共用体」とするのが語義に沿っていて適切と思います。「タグ付き共用体」というわかりよい別名を広めるのは、コミュニティの役割かな？ -- igeta?
- もとの英語が discriminated であって tagged ではないので、きちんと訳になっている「弁別子付き共用体」の方が適切だと思います。 -- taka-island?
- 「弁別子付き共用体」はよく意味を反映してはいますが、やはり少々長い感じがします。多少意味が欠落してしまいますが、「弁別共用体」あたりでよいのではないでしょうか？ -- lowlander?
- 簡潔さを求めるのであれば、元の「判別共用体」でもよいような。 -- igeta?
- あと参考として、以前 MSDN Magazine の記事で弁別子付き共用体という語が DU の訳として使用されています。 http://msdn.microsoft.com/ja-jp/magazine/cc164244.aspx -- igeta?
- 確かにMSDNの記事を見ると「弁別子付き共用体」で座りがよさそう。 -- moonmile?
- Algebraic Data Type は他の言語にもありますが（例えばHaskell）、「タグ付き共用体」とか「区別された共用体」と呼ばれているのをたまに見かけます。 -- のぶひさ?
- 「弁別子付き共用体」は既にMSDN Magazineで既出の訳語だったんですね。だとすると、候補としては強いですね。 -- lowlander?
- 現在の議論からすると、discriminated unionはとりあえず「弁別子付き共用体」という訳で提案するということでよさそうですね。 -- lowlander?
- わたしも「弁別子付き共用体」に一票。わたしもMSDN Magazineでこの訳語をみてしっくりきました。すでに勉強会の資料などにこの記述を使っていたりしています＾＾； -- zecl?
- 決まりかけているのに、何なのですが、MSDNを読むと「識別子」という単語が出てきますので、「識別子付き共用体」ではどうでしょう。「弁別」という単語は多くの人になじみが無く、それだけで引いてしまう人もいると思います。まあ、僕がその一人なわけですが... -- Gushwell?
- プログラミングF#では当初「タグ付き共用体」と訳してました。各ケースを「タグ」と呼んだ方が直感的ですし、いずれか1つの値しか取れないという特性から「共用体」で問題ないなと思っていました。というわけで「タグ付き共用体」に1票です。 -- yukitos?
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
