拡張を提案する

新しい演算、関数、ユーザー定義コードの要望がどう評価されるか、そして各種の要望が現時点ではどこに属するかを説明します。このページはv0.1以降の提案に対するプロジェクトの方針で、文法、プログラムの意味、契約の識別子を変えるものではありません。

ActQLにはユーザー定義関数がありません。提案は、次の2つのどちらかとしてレビューされます。提供元に依存しない演算が欠けているのか、それとも独自のロジックなのか。繰り返し現れる提供元に依存しない演算は、閉じた標準の演算子になることがあります。独自のロジックは、データ、型付きの取得の契約、Run Graphのタスク、またはActQLの外のコードにとどまります。

それぞれの要望はどこに行くかCopy Anchor Link

次のソースの形は受け付けません。

- udf: {language: python, code: "..."}
- compute: {contract: custom-function:v1}
- transform: {wasm: sha256:...}
- fold: {initial: ..., function: ...}

ハッシュ、署名、型の宣言、サンドボックスがあっても、不透明な関数の代数的な法則は見えません。だから、実行前に並べ替え、融合、プッシュダウン、再生、見積もりを安全に行えるようにはなりません。

今後ありうる要望Copy Anchor Link

ActQL 0.1には、正確なdecimalの算術、閉じたobjectとarrayの構築、レコードのアサーション、Unicodeとtimestampのヘルパーが含まれています。次のものは、ありうる不足であって、受け入れられた機能ではありません。

• enum、範囲、文字列長の制約のような、スカラー値の精緻化
• JSONのエントリの展開と集計、標準的なテキストの類似度、あと1つの標準的な集計やウィンドウの演算子
• 登録済みの INFER の契約を超える、追加の型付きの取得の結果

これらの例は、汎用のバリデーター、動的なobjectのキー、再帰的なJSONの変更、あいまい結合やエンティティ解決の演算、任意のリデューサー、try/catch、ドメイン固有のモジュールを認めるものではありません。OCR、文字起こし、ジオコーディング、税務エンジン、祝日カレンダー、経路探索、最適化、XLSX/XML/ZIPの処理、独自のスコアリングは、Relationのデータか型付きのSourceViewの契約として始まります。非同期の形は、CommandとRun Graphを使います。繰り返し現れる、提供元に依存しない数学的な意味は、のちに代数に昇格することがあります。提供元の機能が、単に人気があるという理由で昇格することはありません。

提案に必要なものCopy Anchor Link

1つの新しい演算子を提案する前に、それを必要とする実際のコード片のコーパスを集めてください。各エントリには次を記録します。

source_fragment_cid
input_contract_cid
output_contract_cid
shape: row_local | aggregate | pairwise | artifact | external | process
deterministic_after_capture
external_io
stateful
current_actql_expansion
unexpressible_reason
independent_workload_family

演算子の提案が検討の対象になるのは、次のすべてが成り立つときだけです。

1. 独立した3つ以上の実際のワークロードの系統が、同じ提供元に依存しない意味を必要としている。
2. 既存の合成、データとしてのRelation、型付きの取得、Artifact、Run Graphの境界が、明らかに不自然か不十分である。
3. 入力と出力の型、NULLの振る舞い、順序、失敗、コスト、メモリ、出力の上限を閉じることができる。
4. 移植可能な適合性のベクトルと、独立したオラクルを書くことができる。
5. 新しいルートのCarrier、権限の境界、実行のカテゴリーが不要である。
6. それがないと何があいまいになるか、不健全になるかを、除去による証明で説明できる。

どれか1つでも成り立たなければ、その演算は追加されません。

振り分けの規則Copy Anchor Link

existing composition?
  yes -> add nothing
business rule is data?
  yes -> Relation + join
external / provider / proprietary observation?
  yes -> checked external SourceView join or typed INFER
bytes?
  yes -> Artifact derivation / SERIALIZE / SourceView
time or a prior Effect outcome?
  yes -> Run Graph
general deterministic bounded semantics repeated across real workloads?
  yes -> propose one closed operator in the existing algebra
otherwise -> outside ActQL

すべての拡張の提案は、この規則に従います。

マスターデータCopy Anchor Link

将来のマスターデータのモジュールは、対応を主張する前に、次のワークフローを閉じる必要があります。

versioned persistent graph source
→ typed canonical entity and source binding
→ resolution evidence and merge/split proposal
→ graph delta preview against an exact base version
→ affected binding/relation/source-record counts and conflicts
→ required approval bound to the concrete preview identity
→ compare-and-set apply
→ graph mutation receipt and lineage

エンティティのマージと分割は、グラフの計算ではなくEffectになります。そのプレビューは、移動する束縛、書き換えられるRelation、競合する属性、下流のソースレコード、権限、最大のスコープ、基準となるグラフの識別子、承認の要件を見せるものになります。グラフの和集合をエンティティのマージと読み替えるのではなく、ActQLの承認、権限、プレビューの識別子、冪等性、受領記録の原則をそのまま使います。