Elixir は Erlang VM 上で動作し、高い並行性と耐障害性を持つ関数型言語です。特に Web フレームワーク Phoenix によってサーバサイドでの利用が広まっています。
本セッションでは、Elixir (Erlang) の並行性と耐障害性を支える仕組み(OTP)を紹介し、それが IoT の分野でも有効であることを説明します。
そして、サーバサイドの Elixir 開発をシームレスに IoT 開発へ適用できるオープンソースのプラットフォーム Nerves を紹介します。
Nerves は Raspberry Pi や BeagleBone などの安価なシングルボードコンピュータを公式にサポートしており、ホビー開発からプロトタイプ開発まで気軽に始めることができます。
サーバサイド Elixir の開発体験をそのまま IoT に活かせる Nerves の魅力を伝えられたらと思います。
ソフトウェア開発において、複雑なビジネスドメインを正確に捉えることは極めて重要です。しかし、その過程でしばしば直面するのが、余計な詳細や偶有的複雑さ(accidental complexity)です。これらはシステムを理解しにくくし、保守コストを高める原因となります。
そこで鍵となるのが「抽象」の役割です。本発表ではドメインモデリングにおける抽象の役割を取り上げ、問題空間と解決空間の橋渡しや、ドメインの核となるモデルを的確に表現する土台を作り上げることの重要性について述べます。そして、これらを実現するためのアプローチとして、tagless-finalによる型安全なDSL構築手法について取り扱います。さらに、DSL自体を、型安全に最適化あるいは拡張していくための方法について扱います。また、ソフトウェア開発において、DSLをいつ作るべきか、どのように活用するか、についても触れます。
キーワード:
講演者は Haskeller ですが、最近は業務では Rust を書いています。その過程でどうしても do 式が使いたくなり、Rust で do 式を使うための qualified_do
を開発しました。
まずは、この qualified_do
によるプログラムの例を紹介し、かなり便利なものであるというお話をします。
特に、do式によって Rust の ?
構文糖衣に対する代替的な記法が実現できることや、イテレータの合成や proptest によるランダムデータ生成を見通しよく書けることなどを見ます。
do式を使うには、Monad や Applicative といった構造に類似の演算を備えている必要があります。「Haskellのひとたちが使っている難しそうな……」と身構えるかもしれませんが、do式のうちどういう構文がつかえるかという基準を念頭におくと、こうした階層を自然に理解できることを紹介します。また、Rust でモナド等を抽象化するために Generic Associated Types を使うトリックについても欠点と利点を解説します。
Rust や Linear Haskell のようなリソース管理にうるさい言語では、資源管理にどこまで敏感かによって、Monadの階層は複数に分裂します。本講演では、最後に発展的話題としてこうしたフレーバーの異なる複数の Monad 階層の関係について触れ、また Rust と Linear Haskell の型システムの違いにより、Rust では資源に敏感な do 式をより広い型に適用できるという事を説明します。
Rust、線型型、所有権、do式、プログラミング言語意味論、モナド、Functor、Applicative、Haskell、Linear Haskell
Hasktorchは、Haskellでディープラーニングを行うためのライブラリであり、関数型プログラミングの強みである型安全性を活かしながら、PyTorchの強力な計算エンジンを利用できます。本セッションでは、Hasktorchの基本的な使い方に加えて、セットアップ方法やJupyter Notebookを活用したインタラクティブな開発フローについても解説します。
特に、次のようなトピックをカバーします:
このセッションでは、コードデモを交えながら、Hasktorchを実際に動かしながら学べる内容を提供します。関数型プログラミングを活かしたディープラーニングに興味のある方はぜひご参加ください!
Siiibo証券株式会社は2019年に創業して以来、バックエンドにElixir,フロントエンドにElmと関数型言語をフルスタックに採用して、社債専門の証券システムを作り上げてきました。
このセッションでは実際に関数型言語を業務で(特にスタートアップ企業などの少人数開発組織で)採用し、維持し、継続するにあたって重視している価値観、手続き、手法などをざっくばらんに紹介してみようと思います。
計算機プログラムは現実のフォン・ノイマン型計算機上での計算が前提ですから、命令を記述する部分が必ずあります。
I/Oがその典型です。このセッションでは、そのI/O部分をできるだけ、小さく一箇所に隔離する方法を対話的ソート問題を例に紹介します。
interact :: (String -> String) -> IO ()
の紹介2025年、CursorやCline、DevinなどのAIエージェントを活用した開発が主流となりつつあります。しかし、大規模な開発においては、AIが実装しやすい「枠組みの提供」と「コンテキストの最小化」が重要となります。本セッションでは、形式手法や関数型プログラミングの手法がこれらの課題にどのように寄与するかを探ります。具体的な事例を通じて、これらのアプローチがAIエージェントを活用した開発の生産性と品質向上への貢献度合いを検証していきます。
カバーするトピック
F#は.NETプラットフォーム上で実装された実用的な関数型言語です。本セッションでは、F#の言語設計における特徴的な選択と制約について解説します。
まず、非純粋関数型言語としてのF#の特徴を説明します。副作用の扱い方、関数型の機構とオブジェクト指向プログラミングの共存、そして実用性を重視した設計判断について概観します。
次に、F#独自の機能であるコンピュテーション式と非同期処理を取り上げます。HaskellのMonadやScalaのfor式との比較を交えながら、DSLとしての表現力や、非同期プログラミングモデルの特徴を示します。
最後に、.NETプラットフォームがF#の型システムに与える影響と制約について説明します。メソッドオーバーロードと型推論の相互作用、高カインド型の欠如、そしてそれらの制約に対する解決策としてのSRTPなど、実践的な観点から解説します。
※競技プログラミングの知識については必要ありません
(理論に近いかな?)
多くのアルゴリズムやデータ構造は、命令型プログラミングを前提に解説されていることが多いです。
アルゴリズム内部で使われるデータ構造は破壊的な変更が可能なことが前提であるため、短命データ構造が前提になります。また、プログラミング言語の抽象化能力には焦点を当てていないものが殆どで、Haskell のように、永続データ構造が備わっていて抽象化能力の高い言語でそのアルゴリズムを実装する場合、どのような抽象に至るのか解説されていることは希です。
私は競技プログラミングを Haskell で嗜んでおり、そのため様々なアルゴリズムを Haskell で実装しています。 Haskell でアルゴリズムを実装すると、その他の言語で実装したときには得られなかった様々なメンタルモデルでアルゴリズムを見ることができるようになり、結果、よりよい抽象に辿り着くことができることが多くあります。また、それをそのメンタルモデルそのままに実装することができるのも、関数型言語ならではと思っています。
例えば動的計画法を、代数的構造で抽象化することができます。 セグメント木はモノイドによって抽象化できることが知られていますが、Haskell ならそれをより自然な形で実装することができます。深さ優先探索や幅優先探索は、状態空間を宣言し、状態を遷移させる高階関数 f を渡すだけで様々な問題を解くことができるよう、実装することができます。よりよい抽象に至ると、より幅広い問題を一つの実装で解くことができます。
本セッションでは、幾つかのアルゴリズムの実装とその抽象を紹介し、命令型プログラミングと関数型プログラミングでの計算に対するメンタルモデルの違いを浮き彫りにすることを目標にします。
SML#は、Standard MLを包摂する、純国産のフルスケール関数型言語です。本セッションでは、SML#のコア開発者のひとりが、関数型言語とそのコンパイラを開発する者の視点で、関数型言語を作る上での苦悩と工夫をお話しします。
いくら理論が美しかろうと、言語が高機能だろうと、現実に使えなければ絵に描いた餅です。現実に使えるかどうかの判断基準のひとつは、CPUやメモリなどの計算資源の利用効率の高さ、有体に言えば「速さ」でしょう。ラムダ計算に端を発する関数型言語は、今日主流の命令的な計算機アーキテクチャとは計算モデルから異なるため、現実の計算機を効率よく駆動するネイティブコードを出力する関数型言語コンパイラを開発するのは自明なことではありません。その困難を、ときには新たな理論を開発して、ときには力技で乗り越え、今日の関数型言語コンパイラが成立しています。
コンパイル結果のコード(ひいてはコンパイラそのもの)を速くするには、「CPUコアを増やす」「速いCPUを使う」「コードの無駄を省く」の3つのアプローチが考えられます。最新のSML#コンパイラは、これらのアプローチそれぞれについて、「タスク並列を実現するためのガベージコレクション」「ARM対応のための末尾呼び出しコンパイル」「自然意味論に基づく部分評価器」を装備しています。本セッションでは、SML#コンパイラ全体のアーキテクチャを俯瞰しつつ,これらコンパイラの機能の開発経緯とその理論・技術に焦点を当てます。
本セッションに参加することで、「SML#の使い方」だけでなく「SML#の作られ方」もなんとなくわかった気になる、また関数型言語の裏にあるバイナリな部分にも目が向くようになる、そんな発表を目指します。
マイクロサービス内で動いているAPIをF#で書いて運用を2年ほど続けて得られた知見をお話します。
Domain Modeling Made Functionalが翻訳されたのをきっかけにF#という言語に興味をもたれた方も多いと思いますが、実業務でF#を採用しているという話は珍しいと思うので以下の観点についてお話できたらと考えています。
単一のプロセスで並行処理を行う方法として、OSカーネル上でスレッドを大量に作成する代わりに、細切れにした「タスク」をユーザーランドで処理し続ける、いわゆる非同期ランタイムが使われることが増えてきています(例: goroutine、tokio-rs、Cats Effect、Project Loom)。アプリケーション内部に用意したスケジューラを用いて実行するタスクを切り替えていくこれらの機構は、使い方こそスレッドベースの非同期プログラミングと大差ない(場合によっては、同期プログラミングとも大差ない)ものの、そのランタイム実装まで追ったことのある方は多くないのではないでしょうか。
この講演の前半部分では、ラムダ計算から出発して、ラムダ計算のシンプルな「インタプリタ」であるCEK 機械の仕組みと動作について詳しく解説します。そして後半部分では、CEK 機械の仕組みを通して、非同期ランタイムの実装(の一パターン、特に Cats Effect 3 の実装)を理解できるのだと道案内することを目標とします。