最も近いマイルストーン: 0.1.5 Alpha 1
リスト上の次のものは機能ではない。その目標はゼロ・サイレンスとして述べられて いる: 言語が主張するあらゆる美点が、判定か、走らせられる判据のどちらかを受け取る —— だから何ものも、その記述を反証しうるものなしに記述されはしない。
入力は、他の言語がうまくやっていることの調査である —— C、Rust、Java、Python から取られる —— そして目標は、そのすべての行が最終的に決着されることである。許される 判定は三つ: 仕組みを写す; 意図を写すが形は写さない; あるいはきっぱり拒否し、 どの衝突に当たったのか、どちらの側を選んだのかを述べる。三つの言い回しは失敗状態 として扱われる:「未定」「要検討」「状況次第」—— そのいずれかで終わる行は、決着 されておらず、先延ばしにされている。そして規則は、先延ばしは失敗と数える、というもので ある。
調査の中の美点のいくつかは共存できない。そしてこの営みの役に立つ部分は、どれが 放棄され、なぜなのかを言わされることにある。その衝突のうち三つは名指しに値する —— この言語が実際にその上に座っているものだからである:
抽象機械はどれだけ厚いか
C は未定義の振る舞いを許すほど薄く、その薄さが速度と移植性を買っている —— 言語は何も 前提にしない。Rust は借用をコンパイル時に決定できるほど厚く、その厚さがその証明を 買っている —— 言語は多くを前提にする。両方を最大化することはできない。
知性はどこに住むか
Java はそれを runtime に置き、それによってピーク時のスループットとより単純な運用を 買っている。Loment が存在する理由は、runtime を持たないプログラムと予測可能な 振る舞いである。コレクタを核に置くことは、この言語が何のためのものかを放棄する ことである —— だから回収は方針ではなく、段階的な選択なのである。
名前はいつ解決されるか
Python は実行時に解決する: 儀式がなく、素早く書ける。Java はコンパイル時に解決する: 信頼できるツールとリファクタリング。同じ import が、コンパイル時に検査されながら検査 されない、ということはできない。
その三つのどれも、賢い中間を見つけることで解決されはしない。それぞれは、一方の側を選び、 もう一方の側が何を要したかを書き留めることで解決される。
その後に来るもの
0.1.5 —— 回収が、当てにできるものになる
回収のはしごこそが 0.1.5 の目的である: それが設計であることをやめ、プログラムが当てに できる性質になる、その時点。はしごの大半はすでに建てられている —— 四つの段すべてに実装と判据があり、適応的コレクタと世代別の半分はどちらもすでに着地して おり、言語の二つの実装がそれらについてバイト単位で一致している。0.1.5 が加えるのは、 機能ではない部分である: それを落ち着かせ、何を保証し何を保証しないかを言えるようにする こと。はしごそのものは それ自身のページで述べられており、そこは 自分の状態行を保っている。
0.1.5.x —— runtime が完成する
runtime の設定はすでに、既定付きで存在しており、それは勧告ではなく
強制される: コレクタを要する回収の段を求めつつ、runtime がないと宣言するのは
コンパイルエラーである —— その二つは定義上、互いに矛盾するからだ。今日 runtime が
保持しているのは、まさにその段が必要とする部分である。この行はその残りを加える。
0.1.6 —— インタプリタがパッケージに入る
プログラムを走らせる第二の方法であり、そのはしごの最下段に当たる。段はすでに
作られている —— T0 から T3 がリポジトリにあり、それぞれに判定基準がある ——
しかしそのどれもまだ配布物には入っておらず、choose vm は今もコンパイラが
出すものを変えない。0.1.6 はその隙間を閉じる: インタプリタが出荷され、
そのページは自前の状態行を持つ。
0.1.7 —— オブジェクトシステムが埋められる
今日、言語には struct、単一のペイロードを運ぶ変種をもつ enum、静的にディスパッチされる trait、そしてコンパイル時に解決されるジェネリクスがある。この行が扱うのは、誰も求めて いない機能を加えることではなく、欠けているものである。
0.1.8 —— メモリ管理システムが埋められる
これは上の段とはしごに載っている: 回収が、仕組みの寄せ集めではなく、ひとつのシステムに なる。
0.1.8 より先の項目はまだ計画中であり、このページはそれらを作り出しはしない。この一覧の外に ある一つのことは別に告知されている: パッケージマネージャ自身の次のバージョンで、それは それ自身のリポジトリで告知される。
これがどれか起きたかどうかを、どうやって見分けるか
ロードマップは、後から確かめる方法があってはじめて読む価値がある。だから正直なやり方は、 その確かめがどこで起きるかを述べることである。プロジェクトは計画を公開のイシュー トラッカーには置かない。それをリポジトリ内の番号付きの設計記録として書き留めて おり、そしてそれらの記録は中国語で書かれている —— 探しに行く前に知っておく価値がある。 このロードマップは、あなたが期待するであろう場所にはないからである。
そうすれば、各バージョンの到来は告知ではなく記録の問題になる: リリース履歴が、実際に何が いつ出荷されたかを述べ、下の各ページは、自分を完成したと述べるのではなく、自分の状態行を 携えている。