# wind-java **Repository Path**: cossbow/wind-java ## Basic Information - **Project Name**: wind-java - **Description**: java开发的wind解释器 - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-10-12 - **Last Updated**: 2026-11-11 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # Wind 一种完美解决了异步编程的函数式语言—— ## 设计动机 现代编程语言提供了多种异步编程机制,例如 `async/await`、Future、Promise、回调函数以及各种锁和同步原语。 这些机制解决了不同的问题,但也使程序员需要同时处理业务逻辑、执行顺序、任务生命周期和共享状态、数据竞争等问题。 而这些问题的复杂本身是源自于 异步↔同步 来回切换,就是当程序员开启一个异步任务时,需要考虑: - 是否要关心结果? - 如何获得结果? - 同步获取结果? - 还是在回调里处理后续事情? - 回调太深怎么办? - 要不还是同步? - 多个任务的结果如何合并? - …… 如果两个任务互不依赖,它们就可以并行执行;如果一个任务需要另一个任务的结果,依赖关系就会自然地限制执行顺序。 使用wind编程,你只需写过程和过程之间的依赖关系,调度交给编译器即可。 ## 核心设计 ### 1. 纯函数与副作用隔离 Wind 以纯函数作为内部业务逻辑的基础。 纯函数的结果只取决于输入,不依赖隐式的外部状态,也不会直接产生外部副作用。这使得函数更容易理解、测试、组合和复用。 I/O、时钟、随机数以及其他需要访问外部状态的操作,则通过外部接口提供。Wind 将纯计算与外部操作区分开来,使副作用及其带来的协调需求集中在明确的边界上。 这种设计并不要求所有现实操作都变成纯函数,而是让纯计算尽可能不必承担外部状态管理的复杂性。 ### 2. 基于数据依赖的任务 DAG Wind 使用数据依赖关系表达任务之间的先后关系。 ```wind let user = fetchUser(orderId) let orders = fetchOrders(orderId) let result = { user = user, orders = orders } ``` 这里,`fetchUser` 和 `fetchOrders` 相互独立,因此可以并行执行。构造 `result` 时,需要相应结果的依赖满足后才能完成。 开发者不必显式创建线程、等待两个任务或手动执行任务汇合。程序中的依赖关系为运行时提供了调度依据。 任务 DAG 也让并发结构能够从程序的数据依赖中推导出来,而不是依赖程序员手工维护一套独立的执行控制流程。 ### 3. 基于数据流的任务组合 Wind 使用管道运算符 `|>` 将计算步骤组合成连续的数据流。 ```wind let processAndShip = orderId -> { fetchUser(orderId) |> user -> calculateTotal(user) |> saveToDb |> _saved -> sendNotification("Shipped") } ``` 这段代码描述了一个完整的业务流程:获取用户信息、计算金额、保存数据,然后发送通知。 每个步骤通过数据依赖与其他步骤关联。相互独立的任务可以并行执行,具有依赖关系的任务则按照依赖关系衔接。开发者不必显式编写回调、等待操作或任务汇合逻辑。 管道不仅用于组织代码,也用于表达计算流程。随着流程复杂度增加,任务之间的依赖关系仍然是程序并发结构的基础。 ### 4. 依赖驱动的异步编程 Wind 不采用传统的 `async/await` 编程模型,也不要求开发者显式管理异步任务的等待与恢复。 在传统异步程序中,开发者往往需要通过 `await`、回调或 Future/Promise 组合表达后续操作。Wind 则通过任务调用和数据依赖描述计算流程,由运行时负责任务调度。 - 不需要显式的 `async/await` 语法。 - 不需要通过回调组织异步调用链。 - 不需要手动等待多个独立任务完成。 - 不需要在业务流程中显式编排任务的暂停与恢复。 - 独立计算可以并行执行,依赖关系决定后续计算何时具备执行条件。 Wind 的目标不是提供另一套异步控制语法,而是让并发程序直接以计算依赖的形式表达。 ### 5. 将状态协调收敛到外部资源边界 任务依赖解决的是计算之间的协调问题,但外部可变资源仍然可能需要互斥、顺序保证和一致性控制。 Wind 倾向于将这些协调机制封装在资源接口内部。业务代码通过任务接口提交操作,由资源自身负责必要的排队、串行化、批处理或事务处理。 由此形成三个相对独立的层次: - **计算层**:通过纯函数实现业务逻辑。 - **编排层**:通过数据依赖描述任务之间的关系。 - **资源层**:封装外部状态及其必要的协调机制。 这种分层使业务代码不必依赖语言级锁或显式等待来组织整个并发流程。底层仍可根据具体资源的语义选择合适的同步实现。 ## 设计原则 Wind 围绕以下原则组织语言与运行时: | 原则 | 含义 | |-------|------------------------| | 纯函数优先 | 业务逻辑尽可能由无副作用的函数构成 | | 副作用隔离 | 外部操作通过明确的接口进入计算流程 | | 依赖驱动 | 任务之间的关系由数据依赖表达 | | 隐式异步 | Future 的传播和异步衔接由语言机制处理 | | 自动调度 | 运行时依据任务依赖安排执行 | | 状态封装 | 外部可变资源自行负责必要的协调 | | 组合式编程 | 使用函数组合和管道组织复杂业务流程 | ## 与传统异步编程的区别 Wind 与传统异步模型的主要区别,在于并发程序的组织方式。 | 维度 | 传统异步模型 | Wind | |------|--------------------------|-----------------| | 异步表达 | `async/await`、Future 或回调 | 任务调用与数据依赖 | | 结果衔接 | 显式等待或异步组合 | 隐式 Future 与管道组合 | | 任务汇合 | 显式等待多个任务或使用组合 API | 由结果依赖表达 | | 并发结构 | 可能分散在控制流与异步 API 中 | 从依赖关系中形成 DAG | | 调度 | 依赖语言、框架与运行时的组合 | 由运行时根据依赖调度 | | 共享状态 | 常通过锁、同步原语或资源协议协调 | 倾向于将协调封装在资源边界 | 这并不意味着传统语言中的所有同步机制都没有必要。互斥锁、事务和原子操作仍然可能是底层资源实现所必需的。Wind 关注的是:**业务程序是否必须直接依赖这些机制来组织并发计算。 ** ## 类型系统与语言特性 Wind 采用函数式语言的设计思路,并提供以下语言特性: - **类型推导**:尽可能从表达式和函数的使用方式推导类型。 - **代数数据类型**:通过记录类型和联合类型组织数据。 - **模式匹配**:根据数据结构进行分支处理。 - **显式错误结果**:通过 `Result` 一类结果类型表达可预期的失败。 - **函数组合**:使用统一的函数模型与管道运算符组织计算。 - **任务与纯函数的区分**:让外部操作与纯计算在语言语义上保持边界。 这些特性共同服务于一个目标:让程序的计算逻辑、数据结构和副作用边界更容易理解与分析。 ## 适用场景 Wind 尤其适合具有大量独立操作和明确依赖关系的应用: - 并发服务端程序。 - 多个外部接口的并行调用与结果组合。 - 数据处理和转换流水线。 - 工作流与任务编排。 - 数据库、网络及存储操作的组合。 - 具有明确资源边界的异步业务系统。 对于高度依赖共享可变状态、复杂交互式控制流或必须直接操纵底层同步原语的场景,需要根据具体需求设计相应的资源接口与运行时机制。 ## 文档 - [语言参考手册(Reference Manual)](https://gitee.com/cossbow/wind/blob/master/reference.md) - [项目仓库](https://gitee.com/cossbow/wind) ## 项目状态 Wind 目前处于早期设计阶段。语言语义、类型系统、任务模型和运行时机制仍可能持续演进。 本文档介绍的是 Wind 的设计理念与目标,不代表所有特性都已完整实现。 ## 总结 Wind 希望将异步编程从显式的执行控制,转变为基于依赖关系的计算描述。 程序员定义纯函数,声明外部任务,并通过数据流将它们组合起来。编译器和运行时负责处理异步衔接与任务调度,而外部资源在自己的边界内管理必要的状态协调。 **Wind 不只是让异步代码更容易编写,而是尝试让并发本身成为程序结构的一部分。**