- Flixは関数型プログラミングとエフェクト指向モデルを組み合わせた革新的な言語
- 論理規則とデータ依存性のモデリングが容易で、宣言的な知識表現に強みがある
- 複雑な依存関係やプロセスの流れを簡潔にコードで記述できる
- このようなアプローチはアルゴリズム設計と推論の作業に効率性をもたらす
- クエリ機能により知識ベースのデータを容易に探索できる
Flix言語の概要
- Flixはエフェクト指向プログラミングパラダイムを導入した新しい関数型言語
- プログラマーは手続き型コードではなく、論理的な関係と規則を中心にシステムを記述できる
- 論理規則（
#{}内で宣言）により、構成要素、依存関係、組立時間、納期など複雑な製造シナリオを簡潔に表現できる
宣言的規則とデータモデリング
- 例示コードではPartDepends、AssemblyTime、DeliveryDate、ReadyDateのような事実と規則が使われる
PartDepends("Car", "Chassis") のように製品間の依存関係を定義するAssemblyTime("Engine", 2) のように部品ごとの組立時間を設定するDeliveryDate("Piston"; 1) のように部品の納期も明示する
- ReadyDateという論理規則によって、納期が定義された部品または組立部品の最終準備日を算出できる
- つまり、個々の部品の供給および組立サイクルをシンプルに推論できる
エフェクト指向の推論とクエリ
- Flixの論理規則エンジンはエフェクト指向と参照透過性を組み合わせ、直感的でありながらエラーの少ないプログラム設計を促す
- クエリ構文を使って、ReadyDateに対応するすべての部品ごとの準備日を容易に導き出せる
- この方式は製造、サプライチェーン管理、推論ベースの自動化などさまざまな分野に応用できる
総合と利点
- Flixはエフェクト（Effects）と論理規則ベースの推論を組み合わせ、複雑なシステムの構成要素とプロセス間の関係を簡潔にモデリングする
- 既存言語と比べて、論理的な明快さとコードの簡潔さの面で差別化された利点がある
- ナレッジグラフ、ワークフローエンジン、データ推論など、現代のさまざまなソフトウェア課題に適したソリューションを提供できる
1件のコメント
Hacker News の意見
この言語の深さと広さには強く感銘を受けた
代数的データ型、ロジックプログラミング、ミュータビリティなど、必須機能がすべて最初の段階から含まれている
比較表を見て最も気に入った点は、単一の実行ファイルがパッケージマネージャー、LSP、コンパイラの役割まで全部担っていることだ
Haskell の場合、LSP は ghc と cabal ファイルの間で多くの処理を再実装しなければならず、stack も使われるなど、パッケージマネージャーの公式性がやや曖昧だった
Haskell を批判したいわけではなく、本当に素晴らしい言語だ
ただ、最高の機能が少し隠れているように感じて残念だ
Flix が JVM 上で Java などとどれほど快適に統合できるのか気になる
JVM コンパイラは型情報をほとんど消してしまうので、Flix の
regionsという概念が命令的な相互作用を第一級市民として支援しているのは前向きに評価できるJVM を使えば、数十億ドル規模の価値がある高品質な標準ライブラリを簡単に使えるので、非常に大きな利点だ
だから JVM や .net core がプロジェクトの 90% 以上で最も合理的な選択だと思う
F# だけが唯一の比較対象言語に見える
Flix と JVM の相互運用性における限界点を整理した文書があれば本当にありがたい
ちなみに、関連情報は ここ にある
基本的に Flix/Java の値は boxing/unboxing の過程を経る
それと、Record は第一級市民だ
パッケージマネージャー、LSP、コンパイラがすべて 1 つの実行ファイルだという点が好きなら、Unison もきっとかなり気に入ると思う
ロジックプログラミングと datalog の部分は少し付け足し感がある
他の機能は確かにコードベースの型安全性を高めているのが分かるが、ロジックプログラミングはかなりマニア向けの機能なので、むしろ言語とは別に存在したほうがよいのではないかと思う
JVM コンパイラが型情報をすべて消すというのは完全には正しくない（匿名クラスの場合は型パラメータを保持する）
いろいろな回避策もある
そして実際のところ、コンパイラにとっては大きな問題ではない
型コンストラクタを適用したクラス名をランダム化して普通のクラスのようにレンダリングすればよい
F# は（まだ）型クラスをサポートしていないので、monad ベースのプログラミングには制約が多い
もし F# が Haskell スタイルの monad を省略して、直接代数的効果（algebraic effects）へ飛ぶなら、そのほうが F# の哲学には合っていると思う
"StringBuilder"の部分は少し残念だこの点では Java 側に少し寄っているように見えて確信が持てない
他の部分はぱっと見ではよさそうだ
言語意味論の観点から見ると、多相レコードの拡張/制限の意味論は Leijen の scoped label 方式（論文リンク）に従っているようだ
例えば
r1 = { color = "yellow" }というレコードがあるとすると、r2 = { +color = "red" | r1 }のように拡張できるr2#colorは"red"になり、再び"color"フィールドを取り除くとr3 = { -color | r2 }となるr3#colorは元の値である"yellow"になるこうするのは、以前のスタイル（同じ label フィールドを二度追加できないようにするため、極度に複雑な型システムを使う方向）よりずっと合理的だと思う
Aarhus（特に大学/テックハブ）がプログラミング言語研究で強い影響力を持つ理由が気になる
C++、C#/Typescript、Dart などはいずれもこのデンマークの小さな地域に強いルーツを持っている
Delft や INRIA のような、典型的な Ivy League や Oxbridge の名門校というわけでもない
何がそんなに特別なのだろう？ 水のせいなのか、それとも別の理由があるのかという素朴な疑問だ
ひとつ指摘しておくと、C# は Anders Hejlsberg が作り、彼は DTU（コペンハーゲン）で学んだ
Turbo Pascal も彼が作ったし、Borland もデンマーク人が創業した会社だ
全体としてデンマークはプログラミング言語理論に強い
例えば、静的プログラム解析分野の標準的な大学院教科書（著者 Nielson & Nielson）もデンマーク出身だ
Mads Tofte は Standard ML に大きく貢献した
Aarhus は Ivy League や Oxbridge 級ではないにせよ優れた大学だ
ヨーロッパにはこのように、知名度は低くても教育と研究の質が非常に高い大学が何十校もある
Aarhus は論理、型理論、関数型/オブジェクト指向言語の分野で伝統的に強い
この分野で影響力を持った多くの研究者が Aarhus 出身だ
また、プログラミング言語研究は世界的に見てアメリカ偏重がかなり強く働いているように感じる
Aarhus のような機関はマーケティングや自己 PR が著しく控えめで、良い研究に集中する傾向がある
特別に優れているとか劣っているとかいう話ではなく、世界的な注目を集めにくい面がある
Flix は ML 系言語の中でも最も丁寧に設計された言語のひとつという印象を与え続けている
関数型・命令型・論理型パラダイムの組み合わせと、多相型＆エフェクトシステム、Datalog 制約まで第一級市民として支援している点が本当にユニークだ
型レベルで純粋/非純粋コードを厳密に区別する点は、Monad の代わりに効果を推論しやすくする新鮮な代替案だ
"一つの言語、フラグ不要"という哲学と、コンパイル時エラーだけを追求する点も、シンプルで予測可能なのが良いJVM 自体が末尾再帰最適化をネイティブにサポートしていないのに、Flix が完全な末尾呼び出し最適化を実装したのは注目に値する技術的成果だ
実際に本番環境や研究で Flix を使っている人たちの経験が気になる
特にロジックプログラミングや並行性の分野で使う中で、
closed-world assumptionや例外非対応でどんな苦労があったのか、また Prolog など他の論理言語との Datalog 統合の違いについて聞いてみたい以前 Flix を見たとき、本当に面白くて
"Java プログラマのための Flix"というタイトルで記事まで書いた今では少し古くなっていて更新が必要ではあるけれど……
興味があれば ここ で読める
ブログ記事は本当に素晴らしい
許可さえもらえれば、Flix 公式ブログ一覧（リンク）に追加するとよさそうだ
その記事以降、Flix 言語は大きく進化した
特にエフェクトシステムが大幅に拡張され、Java 相互運用性の改善や構文の更新があった
ブログが本当に宝の山のようだ
長い間自分を悩ませてきた考えを、より洗練された形で整理してくれている感じがする
全部読むのが楽しみだ
HKT もサポートしていて素晴らしい
ただ、typeclass についての説明が見当たらないので気になる
typeclass と Scala スタイルのマクロさえサポートしてくれれば、自分のライブラリ（distage、izumi-reflect、BIO）も Flix に移してみたいし、Scala から Flix への移行も真剣に考えると思う
後になって、typeclass を traits と呼んでいることに気づいた
マクロはどうなのだろう
また、Flix が明示的な名前ベースの継承（nominal inheritance）もサポートしていないのは残念だ
Scala の trait の中でも最も無害な形すら許されないのだから
typeclass は interface の代わりにはならないし、その抽象化がないと多くの有用な機能がそもそも実装できなかったり、コードが見苦しくなったりする気がした
trait は関数のデフォルト実装も提供するが、インスタンス側でオーバーライドできる
Flix には継承（inheritance）はまったくない
trait はコンパイル時にしか使われず、monomorphization によって処理されるのでランタイムオーバーヘッドがない
Flix のインライナーは trait の内部も最適化し、closure まで積極的に除去する
例えば高階関数やパイプラインはバイトコードレベルでは普通のループに変換され、closure の割り当てや間接参照が完全になくなる
Flix はまだマクロをサポートしていない
他言語での（乱用の）経験のためか、導入を恐れているようだ
新しいライブラリ作者を募集しているので、もし興味があれば Gitter チャンネルに来てほしい
Flix 公式ドキュメントの
Flix でサポートしない機能セクションについてNo Code Before Mainという項目があるが実際の説明は
Flix では main より前にいかなるコードも実行されず、静的イニシャライザのようなものも一切ないとなっている機能名は
Code Before Mainに変えたほうがより正確だと思うFlix で関数が純粋であることを必ず明示的に示させる理由が気になる
ほとんどすべての場合、静的解析で十分に推論できそうなのに、なぜそうしているのか知りたい
私の理解では、関数に純粋性を示せば、コンパイラがそれを保証してくれる
"Flix はプログラム内のすべての式の純粋性を正確に追跡する"という文と、純粋/非純粋の表記がない関数定義の例を見ると大半の場合はコンパイラが純粋性を自動推論できるように見えるので
純粋/非純粋の表記はオプションなのではないかという印象を受ける
Flix FAQ（リンク）は普通に始まるのに、だんだん面白くなっていく
いくつか笑った例:
このサイトは JavaScript が必要<br> A: JavaScript の使用を批判した人たち: [1],[2],[3],[4],[5]、実際に HTML へのリファクタリングを手伝うと申し出た人: 0 人この言語と互換性のあるコードエージェントがちゃんと動くのか、それとも自分で頭を使わないといけないのか気になる
冗談半分ではあるけれど、実際この言語は格好よく見えるので悲しい
LLM がむしろ新しい言語の採用を妨げることになるだろうし、この問題をどう解くのか気になる
私はむしろ、LLM は新しい言語の採用障壁を下げる役割を果たすのではないかという直感がある
標準ライブラリのコードは LLM が新しい構文を学ぶのに十分だし、そうでなくてもエージェントがコンパイラ出力を見ながら学ぶことは可能だ
コード移植作業そのものは高度な創造性をあまり必要としない、定義の明確な仕事なので、LLM による自動化の第一の対象になるはずだ
これからは、なぜそれをやるのか、そして世界にどんな影響を与えるのかを、私たちが自分の頭で真剣に考えるべきだと思う
プロンプトで Idris のインデックス型/依存型を必ず使うよう指示しておくと、かなりよい結果が得られる
（こういう指示がないと GADT あたりが限界）