让纯函数式语言去驾驭底层的图形界面，向来是软件工程里最具诱惑力、也最容易碰壁的尝试。Floréal Technologies 最近发布了一篇针对中级开发者的教程，演示如何用 Haskell、GTK 4 和 libadwaita 构建一个现代 GNOME Todo 应用，并借用前端经典的 Elm 架构来管理状态。教程给出的代码短小精炼，窗口只有 480x640 规格，看起来纯粹而优雅。
然而这种轻巧只停留在代码表层。真实世界的图形界面充满可变状态，当纯粹的数学函数遇上操作系统深处的 C 语言对象，开发者往往需要支付远超想象的工程代价。
极简代码下的构建重负
教程配套的开源工程托管在 GitHub 上的 Floreal-Technologies/adwaita-todo 仓库，采用清晰的职责分层，将代码划分为 Model.hs、Runtime.hs 与 View.hs，并通过 adwaita-todo.cabal、cabal.project.freeze 与 justfile 管理构建。表面上看，这只是个普通的 Todo 范例，但翻开依赖锁就会发现，它对编译环境的要求极其严苛。
该项目明确锁定了 GHC 9.14.1 编译器，核心依赖版本被精准钉死在特定的时间切片上：gi-adwaita 1.0.8、gi-gtk4 4.0.12、gi-gio 2.0.38、gi-glib 2.0.30、haskell-gi-base 0.26.9 以及 haskell-gi 0.26.17，依赖快照索引日期停留在 2026年9月26日。只要编译器稍有偏差，或者底层 C 库版本未对齐，构建就会直接中断。
除了 Haskell 自身的包管理，系统环境还强依赖 libgtk-4-dev、libadwaita-1-dev、libgirepository1.0-dev 以及 gobject-introspection 等原生 C 头文件与 pkg-config 元数据。不仅如此，教程正文甚至留下一处笔误：文章里的模块导入写成了 import GI.Awd，而仓库源码中必须写为正确的 import GI.Adw 才能通过编译。
目前在 Stackage 生态中，gi-gtk 已经被维护为纯粹重新导出 gi-gtk4 的向后兼容层，官方明确建议新项目直接引用 gi-gtk4。这种库命名迁移与底层元数据的层层嵌套，直接抬高了项目的初始搭建门槛。
纯函数状态遇上命令式控件
教程引入 Elm 架构的核心目的，是用纯数据结构来驯服图形界面的多变状态。应用的状态、用户触发的消息以及状态转移函数全部保持为纯函数，连数据持久化都被抽象成 Effect 列表。在 GHCi 交互环境里测试这种模型确实赏心悦目，状态变更清晰可控，毫无副作用污染。
披着强类型外衣的命令式 C 接口，无法自动变成现代声明式组件树。
但问题在于界面的另一端是 GTK 4。GTK 的底层核心是高度命令式、基于 C 语言的可变 GObject 体系。通过 haskell-gi 自动生成的绑定代码里，依然充斥着 IO、new、on 和 OverloadedLabels 属性赋值。
Web 端的 Elm 或 React 可以依赖虚拟 DOM 做全量比较与局部重绘，但桌面端的原生控件是重量级系统资源。如果状态每发生一次微小变更，就把整个控件树全量销毁重建，必然带来严重的内存分配压力、界面闪烁与信号泄漏隐患。教程里的 Runtime.hs 必须手工调用 GLib 的 idleAdd 将消息派发塞回主事件循环，再手动把新内容挂回窗口。这种自制的轻量胶水方案，刻意回避了工业级应用必须面对的增量渲染难题。
桌面开发的现实红线
跳出单篇教程的代码细节，横向审视整个 GNOME 生态，不同技术栈的分工早已十分明确。
在需要兼顾原生性能与 Elm 架构的场景中，Rust 生态（gtk4-rs 与 Relm4 组合）已经成为当前事实上的首选方案。Relm4 拥有完善的官方文档和专有教材，能借助静态宏完成高效的增量界面更新。如果要追求极快的原型验证，Python 依靠 PyGObject 提供了最低的上手门槛。
反观 Haskell 端，早年面向 GTK 3 的声明式框架 gi-gtk-declarative 已经长期停滞。虽然社区后来派生出 gi-gtk4-declarative，并将其应用在 ghcup-gtk 的 v0.1.0.0 版本中，但至今未能形成公认、成熟的通用 UI 规范。开发者只要稍微深入复杂的交互场景，就必须自己充当编译器，手写状态同步代码。
- 风险.将 haskell-gi 与 libadwaita 作为通用跨平台 UI 选型不仅迁移成本极高，还会面临文档断层与胶水代码维护陷阱。
古人讲求规矩方圆，器利而后工精。用纯函数状态机管理业务模型本身具备很高的形式美感，但当它深入到底层可变系统时，缺乏高层框架支持的开发者只能处处自行修补防线。对技术探索者而言，这是一个优秀的架构实验样本；但对实际的软件交付来说，生态成熟度与工具链完备性，永远是难以绕过的硬指标。