Destructuring bindings の適切な翻訳

[scova0731]

Destructuring bindings の適切な訳が見いだせていません。構造化代入、分配束縛などが見つかりますが、この文脈で何が適切かがわかりません。短い部分ですが、ご知見をいただけると嬉しいです。

オリジナル:

[original page](http://twitter.github.com/effectivescala/#Object oriented programming-Structural typing)

Destructuring bindings

Destructuring value bindings are related to pattern matching; they use the same mechanism but are applicable when there is exactly one option (lest you accept the possibility of an exception). Destructuring binds are particularly useful for tuples and case classes.

val tuple = ('a', 1) 
val (char, digit) = tuple

val tweet = Tweet("just tweeting", Time.now)
val Tweet(text, timestamp) = tweet

日本語訳:

translated page

Destructuring bindings

Destructuring bind(訳注:構造化代入、分配束縛などの訳がある)による値代入は、パターンマッチに関連している。 それらは同じメカニズムを利用しているが、(例外の可能性を許容しないために)正確にひとつの選択肢があるときだけ適用できる。 Destructuring bindは特にタプルやケースクラスで有用である。

val tuple = ('a', 1)
val (char, digit) = tuple

val tweet = Tweet("just tweeting", Time.now)
val Tweet(text, timestamp) = tweet

[kmizu]

GaucheのKawai Shiroさんは、「分配束縛」という訳語を使っていたなあと(プログラミングClojureが確かそうだった)ふと思い出しました。
これが定訳かどうかは知らないのですけど、ぐぐっても定訳も見つからないし、定訳を聞いたことも無いので、「分配束縛」あたりで
良いかなーと思いますです。

[eed3si9n]

Lisp 系の言語だとある値に変数名をつける事を binding (束縛) と言いますが、Scala の用語だと値に名前を付けることは definition (定義) と呼ばれています。

Scala における binding (束縛) は、ある参照 x.y を import などをたどりながらもとのエンティティ (型、値、メソッド、そしてクラス) に結びつけることか、もしくは e @ pattern としてパターンに名前を付けることを指すと思うので、原文の "Destructuring value bindings" からしてちょっと変かなと思います。

代入は、Scala の用語だと variable に値を入れなおすことなので、これも駄目だと思います。

言語仕様だと value definition の左辺値にパターンが来ても ok ですよと書かれているだけで、この概念にしっかりとは名前が与えれれていませんが、仕様の例には "pattern definition" (パターン定義) と書かれたコメントがあります。コップ本では "Patterns in variable definitions" (変数定義におけるパターン) なので、ちょっとくどいですが、多分それがベストだと思います。

[kmizu]

ちょっと議論のコンテキストを踏まえて修正。

まず、Scalaにおける変数定義などに関して、「束縛」という訳語を当てるのが適切かどうかについて。

eed3si9n のコメント

Lisp 系の言語だとある値に変数名をつける事を binding (束縛) と言いますが

からは、binding(束縛)というのを、Lisp系言語ローカルな用語だと理解されているように見受けられますが、これは誤解かと。束縛という用語は、Lisp系かどうかに関係なく、もっと一般的な(少なくとも関数型言語コミュニティ一般で通用する程度には)技術用語です。Scalaであえて、束縛という用語を使う事は多く無いかもしれないので、その点で自分のコメントはちょっといい加減でしたが。

「束縛」という技術用語には、指示対象が明確でなかった変数(名前)を、特定の値(対象)に「束縛する」(束縛されるのは値ではなく、変数である事がポイントです)というニュアンスがあり、SMLでもOCamlでもHaskellでも、少なくとも関数型言語コミュニティなら、「変数束縛」と言えば、何を指しているのか大体通じるというのが自分の実感です。

また、

Scala における binding (束縛) は、ある参照 x.y を import などをたどりながらもとのエンティティ (型、値、メソッド、そしてクラス) に結> びつけることか、もしくは e @ pattern としてパターンに名前を付けることを指すと思うので、原文の "Destructuring value bindings"
からしてちょっと変かなと思います。

これは、束縛という技術用語の一例であって、原文が変なわけじゃないかと。Scala言語仕様としては、名前 => (Scalaにおける)各種エンティティの結びつきの導入を「束縛」と呼んでいますが(Scala Language Specification Chapter2 Identifiers, Names and Scopes)、これも、元々の概念としての「束縛」を、必要のためにScala言語仕様内で定義し直した(Scalaにおける束縛の隠蔽ルールなどの説明が必要ですし)だけなんじゃないかと。

というわけで、自分の意見としては、「束縛」という訳語を当てる事自体はそれほど不適切だとは思わないです。

[kmizu]

次に、じゃあ、「Destructuring value bindings」に対して、実際問題、どういう訳を当てるのが適切か、といいう点について。

この点については、言語仕様に明確な記述が無いか気になったので、Scala Language Specification のパターンの辺りをあらためて読み直してみました。すると、

8.1.1 Variable Patterns

に、

A variable pattern x is a simple identifier which starts with a lower case letter. It matches any value, and binds the variable name to that value.

という記述があります。これは、Variable Pattern(変数パターン)にマッチすることによって、Variable Patternにおけるvariable name(変数名)がvalue(値)に束縛される、という事を言っています(他に、Constructor Pattern, Tuple Patternに関する記述がありますが、これの解説はおいときます)。

さて、「Destructuring value bindings」について。まず、実行時に起きる事象としては、(val/var)による変数定義において、Variable Patternと(Tuple Pattern | Constructor Pattern)の組み合わせにマッチしたときに、タプル要素(ケースクラスのパラメータ)が分解されて、変数パターンにおける変数名がそれぞれの要素に「束縛される」事になります。一方、原文を読むと、「Destrucruing value bindings」を言語機能(の一種)として扱っています。原文の意図としては、「Destructuring value bindings」は事象の説明というより、言語機能の説明にあるようなので、その点で、原文はちと妙な気がします。

その用語としての妙さにはとりあえず目をつぶって、訳語を当てる事を考えます。上で書いたように、Scalaにおける変数定義を「binding」(束縛)とするのは特に不適切ではない、というのが自分の意見なので、さしあたって(既に訳語としての事例もある)「分配束縛」と訳して、訳注で、補足を入れるのが良いかな、と考えています。

eed3si9n案の

"Patterns in variable definitions" (変数定義におけるパターン)

は、「言語機能の説明として」妥当かと思うのですが、原文からかなり離れてしまっている点が翻訳としてはどうだろうか、というのが自分の印象です。

//あと、「Destructuring variable bindings」ならともかく、「Destructuring value bindings」はちと用語として変ですね
// 「変数束縛」という用語は、日本でも外国でも、しばしば、「何が」「何に」束縛されるかで、→の向きを間違えている人はよく
// 居るので(「変数(名前)が値に束縛される、のが正しい」、ひょっとしたらそういう事だったりするかもしれません。

[eed3si9n]

@kmizu wrote:

Lisp 系の言語だと

Lisp系言語ローカルな用語だと誤解されている

binding という概念そのものは普遍的なものですが、言語によってはより限定的な意味を持つので、安易に Gauche や Clojure の訳を導入するべきではないという意味でした。束縛は Lisp 用語ということではありません。逆に、Scala では積極的に binding という概念は使われていますが、mutable な変数を持っている言語なので、より限定的な意味になっていますよ、ということです。

8.1.1 Variable Patterns

これは、パターン内にあらわれる

case x => x + 1

の x を指している概念なので関係ないです。「パターンに名前を付けることを指す」ことにも Scala では使っていると僕が書いたこととは矛盾してませんが。言語仕様で関わってくるのは、4.1 Value Declarations and Definitions だと思います:

Value definitions can alternatively have a pattern (§8.1) as left-hand side.
...
Example4.1.1 The following are examples of value definitions

val pi = 3.1415
val pi: Double = 3.1415 // equivalent to first definition 
val Some(x) = f()       // a pattern definition 
val x :: xs = mylist    // an infix pattern definition

[kmizu]

@eed3si9n wrote

binding という概念そのものは普遍的なものですが、言語によってはより限定的な意味を持つので、安易に Gauche や Clojure の訳を> 導入するべきではないという意味でした。束縛は Lisp 用語ということではありません。逆に、Scala では積極的に binding という概念は 使われていますが、mutable な変数を持っている言語なので、より限定的な意味になっていますよ、ということです。

なるほど。その点、こちらが誤解していました。すいません。Scalaではより限定的な意味になっているか、という点は異論がありますが(一般的に、言語仕様や、形式的な文脈では、あいまい性を発生させないために、用語はより限定的に定義されます)。

これは、パターン内にあらわれる

case x => x + 1
の x を指している概念なので関係ないです。

おおいに関係はあるんじゃないでしょうか。たとえば、

val Some(x) = f(x)

と書いたときの、xは、まさに8.1.1 Variable Patternsで定義されているパターンそのものですし(↑のような、変数定義におけるパターンマッチングであっても、Variable Patternにマッチして「xが束縛される」という意味で)、

val (x, y) = ...

におけるx, yも同様にVariable Patternですから。

「パターンに名前を付けることを指す」ことにも Scala では使っていると僕が書いたこととは矛盾してませんが。

はい。ここは矛盾はしていないと思います。

[eed3si9n]

@kmizu wrote:

これは、パターン内にあらわれる (中略) x を指している概念なので関係ないです。
おおいに関係はあるんじゃないでしょうか。

関係無いは言い過ぎですが、Scala には現行で variable pattern, typed pattern など 12通りのパターンがあるわけでその一つの variable pattern を取り出して引用するのは、variable pattern があたかも patterns in variable definitions と等価であるような印象を与えるので本筋から外れるということです。

Patterns definition (パターン定義) は

val パターン = 右辺値

という形をとる変数の定義方法です。
Some(x) や (x, y) は constructor pattern であって、その内部の x や y の部分だけが variable pattern です。
で、右辺値から抽出された部分が x や y に束縛されるというのは確かに正しいと思いますが、
その文移行で x と y がちゃんと変数として機能するのはそれが definition (定義) だというのが大切なんじゃないかと思います。

[kmizu]

@eed3si9n wrote

関係無いは言い過ぎですが、Scala には現行で variable pattern, typed pattern など 12通りのパターンがあるわけでその一つの >variable pattern を取り出して引用するのは、variable pattern があたかも patterns in variable definitions と等価であるような印象を与
えるので本筋から外れるということです。

そういう印象を与える事については考慮していませんでした。variable patternだけを引用する、というより、最終的にパターンマッチングで変数束縛が起きるとき、複合的なパターンであろうと何であろうと、パターンの「底」にはvariable pattern(or typed pattern)がある(はず)ので、その事を強調したかったのでした。ともあれ、誤解させる記述になっていたのは、すいません。

Patterns definition (パターン定義) は

val パターン = 右辺値
という形をとる変数の定義方法です。

はい。理解しています。

Some(x) や (x, y) は constructor pattern であって、その内部の x や y の部分だけが variable pattern です。

はい。この点も自分の認識と一致しています。上でパターンの「底」にvariable patternがある、と書いたのはその事を意図しています。

で、右辺値から抽出された部分が x や y に束縛されるというのは確かに正しいと思いますが、
その文移行で x と y がちゃんと変数として機能するのはそれが definition (定義) だというのが大切なんじゃないかと思います。

これは、4.1の

1. If the pattern p has bound variables x1, ..., xn, where n È 1:
   val $x = e match {case p => (x1, ..., xn)}
   val x1 = $x._1
   ...
   val xn = $x._n .

の事(パターン定義がmatch式+変数定義に展開される)を指しておられるのでしょうか。だとすると、確かにそれはもっともかもしれません。

[okapies]

ご教示ありがとうございます。
文中で、このissueの議論へリンクを張らせていただきました。