Thread by @genkuroki

#Julia言語 リポジトリを覗くと、Juliaのコア開発者の側がabstract typeにフィールドを付けられるようにすることを提案し、議論の結果、そうしない方が良いことを説得されるという胸熱な展開があります↓

github.com/JuliaLang/juli…

Juliaの仕様に関するリポジトリでの議論は非常に面白いです。

https://twitter.com/wananananabe/status/1376019340793815040

#Julia言語 技術的に健全な議論の模範として、過去のJuliaのリポジトリは利用可能。

誰も実現したことがないプログラミング言語の基本仕様を「みんなで話し合って決めて行く」という困難なことに成功している稀有な例。

一人のスーパースターが仕様を決定する方が楽なのに全然そうなっていない。

#Julia言語 abstract typeにfieldsを付けるという提案が覆されたポイントは以下の2つの発言だと思います。

github.com/JuliaLang/juli…

github.com/JuliaLang/juli…
【プロパティはフィールドというよりメソッドに似ています】

#Julia言語 例えば2次元ベクトル空間の点を表す1つの方法は x, y という2つの数値を使うこと。

しかし、仮にその2つのフィールドを持つ型のみが、2次元ベクトル空間の点を表すための型だということにされてしまうと困る。

基底e₁=(1,0)とe₂=(0,1)を指定するには、e_iのiの情報があれば足りる。続く

#Julia言語 基底e₁=(1,0)とe₂=(0,1)を効率よく実装するには、そのどちらであるかを指定する情報のみをフィールドに持つ型で実装したいということがあるかもしれない。

型が持つフィールドはユーザー側には見せる必要がない実装の詳細なので、フィールドが継承されるという仕様は必ずしもよくない。

#Julia言語 の基本戦略は、型の違いでディスパッチすることによって計算を効率化することです。

だから、実装の詳細であるフィールドをabstract typeが保有できるようにし、そのsubtypesへの継承を強制すると、後で効率的な実装をひどく妨げる可能性があります。

私の理解は以上の通り。

#Julia言語 言葉の意味。型のフィールドとは、例えば

struct Foo{A,B}
a::A
b::B
end

におけるa,bのことです。型のフィールドの設定は計算時にメモリをどのようにどれだけ使うかに直結しているので、計算効率に大いに影響します。フィールドを実装の詳細扱いすることは無難。

#Julia言語 私の理解のまとめ

* Juliaにおける型のフィールド達は実装の詳細に関わる部分という扱いになる。型のフィールド達を概念の抽象化のために使うことは意図していない。

* 概念の抽象化はメソッドの側で行うべきである。

* 概念の抽象化と計算の効率化の両方を考慮することが大事。