Unison是否具备或可实现homoiconicity（同像性）特性？

乍看之下，Unison似乎具备*homoiconic（同像性）*属性，表面符合“代码即数据”的特征——Unison的代码确实是以密码学哈希形式做持久化存储的。但直接操作这些密码学哈希的实用性极低，实际操作价值并不比直接改动JVM编译后的字节码高多少。要准确判断它的同像性属性，可以拆成两个核心问题逐一分析：

• Unison当前版本是否具备homoiconicity特性？
• 若补充代码生成、AST操作相关功能，Unison是否可实现homoiconicity？

当前版本的同像性判定 #

当前正式发布的Unison版本不具备真正意义上的同像性。
同像性的核心判定标准从来不是“代码以某种结构化形式存储”，而是语言本身可以将自身代码作为原生数据结构直接读写、操作，整个过程不需要借助外部工具、不需要做跨表示层的格式转换，操作得到的代码结构可以直接被语言求值运行。
Unison目前虽然将代码存储在内容寻址的哈希体系中，但用户在语言层面无法获取可直接操作的代码AST结构，日常能接触到的只有代码对应的哈希引用，修改、生成代码只能走官方编辑器交互、u命令行工具的标准流程，本质上和“Java字节码存在磁盘上，但无法在Java语言内直接拼接字节码作为普通数据运行”的逻辑一致，达不到同像性的判定标准。

补充相关能力后的可行性 #

如果后续官方在语言核心层开放原生AST数据类型，内置代码生成、AST变换、AST直接求值的能力，Unison完全可以实现同像性。
它本身基于内容寻址存储的架构对实现同像性甚至有独特优势：所有代码块都有唯一的哈希标识，做AST变换、元编程时不需要处理复杂的作用域重名问题，生成的新代码只要存入内容存储就能直接被其他代码引用，在代码一致性管理上比不少现有同像性语言（比如传统Lisp分支）的宏系统更有优势。只是目前这层能力完全没有暴露给终端用户，因此谈不上具备同像性。

内容的提问来源于stack exchange，提问作者bbarker