# 参赛方向与实现路线

## 项目定位

面向 MoonBit 的纯语言 Arrow IPC 交换层，使 MoonBit 的数据处理、数据库结果
和浏览器/Wasm 程序能够交换标准列式数据。与单个数据库的 Arrow 导出绑定相比，
这里交付可独立使用的编码、解码和批次访问能力。

这是生态基础设施方向。贡献应由外部兼容性、可复用 API、下游实际使用和可靠性
证明，而不是由代码行数或“完整实现 Arrow”的口号证明。获奖结果不可保证。

## 当前 0.1.0 已落地

- 七种基础类型、空值与 schema/field 元数据。
- Stream/file 双向 IPC，内存中逐批读取与文件批次索引。
- 四后端测试、独立 PyArrow 输入与双向兼容验证。
- 范围检查、可配置解析预算、畸形输入语料。
- API 文档、示例、格式契约和 CI 配置。

## 下一阶段：扩大真实数据覆盖

1. 增加 Int8/Int16、无符号整数、Float32、Date/Timestamp；明确时区与单位语义。
2. 支持 List 与 Struct 的递归 field/node/buffer 布局，并限制递归深度。
3. 支持 dictionary batch、字典引用和字典更新，补充跨批次测试。
4. 评估 LZ4/Zstd 的 MoonBit 依赖，按实际实现情况支持压缩 IPC/Feather V2。

每项完成都要求 PyArrow 生成输入、MoonBit 重写、PyArrow 校验，补全错误用例。
应先按下游需求排序，避免一次承诺全部 Arrow 类型。

## 参赛展示前的交付

1. 完成一个真实下游示例：Python 生成表 → MoonBit 读取与变换 → Python 读取结果。
   测试驱动已验证协议，但还不能代替面向用户的大文件 I/O 示例。
2. 增加 Native/JS 的可复现吞吐量与峰值内存基准，记录硬件、工具链、数据规模。
   当前没有性能测量，不宣称零拷贝或高于其他实现。
3. 吸收至少一个下游使用反馈，稳定公开 API。
4. 复核模块所有权、仓库与 Mooncakes 元数据，发布版本并准备参赛说明。
   远端仓库为 buildliming/MoonArrow，Mooncakes 模块为 shunge/arrow；比赛尚未提交。

## 并行计算的衔接

后续可以把 RecordBatch 作为任务分块，让 Worker/多进程分别处理批次，再用 IPC
交换结果。当前项目不实现线程池、调度器或共享内存并行计算；先建立可互操作的
数据层，再依据 MoonBit 运行时和下游需求评估并行执行层。