Luna Flow
日本語

コントリビューションガイドライン

このガイドは luna-complex を変更する際のルールをまとめたものです。プルリクエストを作成する前に ./ready_to_pr.sh を実行してください。

コードスタイル

  • すべてのコードを moon fmt で整形すること。
  • 完全修飾名での呼び出しを繰り返すより、src/alias.mbt と src/float_backend/alias.mbt にある共有の using インポートを使ってください。
  • コメントは短く技術的に保ってください。コメントでは数値安定性のための選択、分枝の選択、自明でない契約を説明し、コードの内容を繰り返さないでください。
  • トレイトメソッドは src/extends.mbt で明示的に昇格させてください。非推奨のメソッド形式は #deprecated と #doc(hidden) を付けてそこに残します。

命名

  • 束縛と関数: pow_real のように、小文字とアンダースコア。
  • 型とトレイト: Complex や FloatingBackendScalar のように、PascalCase。
  • ファイル: 小文字とアンダースコアで、そのファイルが担う振る舞いにちなんだ名前を付けます。utils.mbt のような何でも入れるファイルは避けてください。

パッケージの境界

  • ルートパッケージはジェネリックな Complex[T] を担います。構築、変更、代数演算、luna-generic インスタンスです。浮動小数点のセマンティクスは含みません。
  • src/float_backend は浮動小数点の能力トレイトと解析関数を担います。現在の MoonBit のルールでは、パッケージは他のパッケージの型にメソッドやトレイトインスタンスを追加できないため、これらは自由関数になっています。
  • Complex[T] にインスタンスを追加するのは、明記された制約のもとでその構成が法則を満たす場合に限ります。core の設計 を参照してください。
  • 公開 API の変更は慎重に行ってください。内部ヘルパーは非公開のままにします。

数値計算の変更

  • 式と、スケーリングし直しや特殊ケースを設ける理由は float_backend の設計 に、観測可能な分枝と特殊値の振る舞いは float_backend API に記載してください。
  • 変更したすべての数値的な振る舞いについて回帰テストを追加してください。exp(log z) = z のような恒等式、分岐切断上およびその近傍の値、非常に大きい入力と非常に小さい入力、特殊値などです。

テスト

  • ブラックボックステストはコードの隣の *_test.mbt に置き、@luna-complex.Complex::new のような修飾名を使います。
  • 振る舞いを変更したすべてのターゲットで moon test を実行し、提出前に moon test --enable-coverage を実行してください。
  • 公開 API が変わったときは必ず moon info で pkg.generated.mbti を再生成し、その差分を確認してください。

ドキュメント

  • マニュアルは doc/manual にあります。英語のページを変更したら、lunadoc update を実行し、doc/locale にある中国語と日本語のカタログを更新してください。
  • マニュアル内のコード例は、現在のコードに対してコンパイルできなければなりません。

コミットとリリース

  • fix(float_backend): use pi on the negative real axis のような、英語の Conventional Commits を使ってください。
  • 1 つのコミットは 1 つの論理変更に集中させること。
  • 公開する前に、moon.mod のバージョンを更新し、README.md と CHANGELOG.md を更新し、moon check と moon test --enable-coverage を実行してから、moon.mod と正確に同じバージョンで公開ワークフローを起動してください。
  • メンテナでない場合は、moon.mod の依存関係やバージョンの宣言を変更する前に確認してください。