HeurAMS-Core/README.md

HeurAMS-Core

自包含、可移植、可扩展、高性能的间隔重复调度程序内核, 使用受限制的 TypeScript 实现, 用于取代旧版 Python 内核并直接用于多前端平台.

项目写的是哪种 TypeScript?

具体地说, 是 ArkTS 风格约束的 TypeScript 严格子集方言, 具体地说, 它:

• 兼容, 但不是标准 TypeScript: 它禁用了 any、eval、Proxy、动态属性等高级动态特性, 以便解释器进行充分性能优化
• 兼容, 但不是 HarmonyOS ArkTS, Node.JS 或任何一种运行时方言: 它不依赖平台专有的接口, 亦不依赖任何外部包管理器

它是 TypeScript 的一个严格且可静态分析的子集, 目标是:

• 高性能: 对象形状固定, 类型稳定, 利于 JIT/AOT 优化
• 类型安全: 禁用所有绕过类型系统的逃逸舱口
• 运行时安全: 禁用所有运行时代码解释注入与执行操作, 如 eval
• 零依赖移植: 通过依赖注入抽象平台 API, 并内置 (vendor) 或实现所有所需第三方库
• 多平台支持: 拥有编译后在 Flutter, ArkTS, Qt, Python (micro-javascript) 及任何支持 ECMAScript 2020+ 的环境中嵌入并运行的能力

为什么使用 lisp 扩展?

这个想法来源于 emacs 的设计: 数据驱动扩展核心功能

不同于传统的插件系统或 "猴子补丁" 式脚本绑定, 我们采用 lisp 方言及 S-表达式作为克制且优雅的算法调度器扩展接口, 它带来了如下好处:

• 声明式配置: 所有扩展规则与策略均以数据形式表达, 而非命令式代码, 天然适合描述调度策略
• 安全隔离: lisp 调用内核 API 以描述调度策略与算法, 不包含可执行代码, 可防止代码注入攻击
• 轻量一致: lisp 解释器易于实现且开销轻量, 避免了复杂的 API 绑定和类型转换开销, 可在所有平台保持行为一致性
• 用户友好: lisp 语法极其简单, 用户无需构造内核内部数据结构便可使用数学语言便捷地描述任意算法

为什么重写内核

在过去一年, Python 版本的 HeurAMS 应用凭借 Textual 框架已经能稳定地在终端完成间隔重复记忆调度的功能, 但我们发现这个技术原型已经不能继续远行:

• Python 运行时巨大, 跨平台性能差: 我们不愿意把跨平台的能力寄托到 PyQt 等 UI 绑定与自带 Python 运行时上, 我们希望每个客户端都是原生且开销尽量小的
• 安全性差: 配置能自我描述, 但必须通过 exec 等危险函数, 我们不愿意把平台与应用安全交由多样社区或使用复杂的 "安全补丁", 我们希望安全性由架构设计自然保护
• 类型不安全: Python 代码缺乏约束, 丰富的动态特性有助于开发, 却让大型算法逻辑难以维护, 我们不愿意使用啰嗦臃肿的代码描述策略和内核
• 依赖难以管理: 尽管有了 uv 等现代化解决方案, Python 的依赖树依然庞大, 我们不希望对每个平台编译 C 扩展, 只为了那几个可有可无的依赖
• 算法模块不可移植: 我们发现, 现有的算法扩展机制完全依赖 Python 内部行为, 这意味着算法功能扩展需继承特定的类原型, 我们不愿把数学语言的寄托绑定在多变而不稳定的专有原型平台上

我们不愿看到, 一个崭新的软件与框架逐渐变成其诞生时立志取代且不愿成为的样子, 我们不愿看到, 它在功能上越走越远, 却逐渐走向开放的反面.

我们决定做正确却艰难的事: 重构一切, 自断手脚, 使用受限制的 TS 与 lisp 语法重构内核, 用可控的代码为间隔记忆领域软件换来开放、安全、自由且高性能的未来

项目会取代 Python 版本吗?

会取代的部分:

• 在内核上, TypeScript 版本会完全取代 Python 版本
• 未来, 以及当下的客户端实现 (基本用户界面, KiriMemo, ArkMemo, HeurStudio, 以及可能的 Web 端等) 都将基于 HeurAMS-Core, 而不是 Python 版本内核
• eval 字符串 API 规范将变成更安全的格式实现, 而 Python 版内核将被完全弃用

不会取代的部分:

• Python 的 Textual TUI 前端不会被 TypeScript 重写: Textual 是优秀的 TUI 框架, 届时 Python 版本将变成一个 Textual 前端, 并兼容此前的 HeurAMS TUI 版本