JSON处理语言，它兼容JSON语法并被设计为同时对人类和机器友好（易于编写和阅读，且能被机器快速解析），可以作为JSON的原地替换，用作配置文件格式或数据传输格式，同时它还具备一些现代编程语言的高级特性以便 Scale 到更大规模的项目中使用
设计这样一门语言最初的动机是
- 我希望能有一门足够轻量级的声明式语言（基本上就是JSON数据+Lambda函数），能便捷地嵌入到任何其他语言当中 -- 就像 Lua 那样（但是声明式的）
- 我希望我们在多语言开发环境中传递计算逻辑可以像传递数据一样轻松 -- 函数应当是 first class 的，不是么？
- 我希望软件在定义配置项目时，可以拥有函数，从而简化配置 （比如 类似 --date-format 这样的选项，总是相当复杂且各有差异且难以记忆，支持类似的选项不仅意味着高昂的软件开发和维护成本，还同时提高了用户使用时的学习成本，并且这个学习结果并不总是能迁移到其他地方，而我们只是需要用户简单地填入一个 Date -> Str 的函数不是么？）
- 在命令行中处理 JSON 时，我希望有一个更符合自己直觉的 jq 的替代品 -- 这个理由可能不是对所有人都有效，但至少我当时是这么想的
这个项目中途被搁置了几年，因为这期间我认识了 Nix 语言，它基本上就是一个 “JSON数据 + Lambda函数” 这样的语言，并且实际用起来体验还不赖，所以这导致我继续开发 JPL 的动力大大降低。
在使用 Nix 若干年后，我逐渐发现了它的一些局限性，这使得我又重新开始设计 JPL，这一次重新设计它的动机是
- Nix 在被用于 NixOS 配置时，其实非常依赖一个类型系统，它就是 NixOS Module System，这基本上是一个在 UTLC 基础上实现的动态校验类型系统，但围绕它实现 LSP 则相当困难
- Nix 的性能和错误信息饱受诟病，当然处理好这些是非常具有挑战性的工作，我也不确定我是否能做得更好，但也许基于一个全新的设计来做这些工作会相对容易一些
- NixOS Module System 的 关于可合并数据类型的设计 相当惊艳，并且在应用于配置文件生成，为传统配置文件赋予抽象能力及模块化能力 这件事上，表现得相当出色，但很少有其他语言吸收这一优点
- Nix 的语法在刨除一些特立独行的设计后，本质上与 JSON 非常相似，但很可惜正是这些特立独行的设计让 Nix 语法与 JSON 不兼容，而让很多潜在用户望而却步，这是非常可惜的。但我认为兼容 JSON 所需做的妥协非常小，是完全可以接受的，并且决定要在一开始就兼容它，甚至直接将 JSON 作为 JPL 语言的 Normal Form，也就是求值的终点
- 语法层面兼容 JSON，是 JSON 的超集，并且求值过程以 JSON 为 Normal Form，简称 JNF
- 在此基础上扩展 UTLC（无类型Lambda演算），但同时支持类型标注语法（这个做法有点像 Python3，它对我而言是一种折衷，为了让实现成本可以接受，同时让 LSP 等效率工具可以正常工作。我希望未来我们有足够的开发人力资源可以利用这些类型信息优化执行效率，当然我也寄希望于 Partial Evaluation 最终能帮助我们免于这项工作并提供足够优秀的性能）
- 它在去糖之后，应该拥有一个相当简单的 Core Language（大概就是UTLC之类的东西，可以暂且称之为 JPLC），以便以非常低的成本嵌入到各种其他语言当中
- 在嵌入到其他语言时，我们总是可以在 Host Language 中实现一些 Primitive 的函数（大概就是一些类型为 JsonObj -> JsonObj 的函数）并注入到 JPL 的解释器当中，这个特性可以用于性能优化，或是提供一些独特的原语（如 nix 的 derivation）
- 最终能支持 Partial Evaluation，这不只是性能优化的需要，它还能帮助我们理解和审计高度抽象的代码（通过将其中的大部分复杂抽象进行消除）
- 支持 Source Map（或类似机制）以便在用户编写的源码和各个阶段生成的代码之间进行双向映射（这可能会涉及到多对多映射），这在排错时将相当有用