op 想做的，侧重于 DSL 还是解析呢？算是两个不同的方向了。前者是 Model Driven Engineering ，后者就是典型的造语言（即使是 DSL 原理也一致）。

前者的话更多关注于怎么样把具体的应用场景里面的 model 和 domain map 到语言上，关注于，如何去做 meta modeling ，如何提供语义清晰的 api ，如何做 text 、model 、运行时之间的转换，主要还是合理使用第三方工具而不是自己造轮子。当然基本的一些概念，比如不同的 eval 语义，还是需要了解的。

后者重点在造语言，比如说词法分析语法分析、类型检查和推导、代码生成甚至后期优化。这个也是不限于 DSL 的，或者说 DSL 其实一般不需要这个 approach 。

Model Design 这方面我不了解，感觉 op 可以找找看有没有一些学校的公开课件看一下，不过感觉这个领域也是那种比较老式的软科，可能有许多模糊的概念或者过时的工具，需要仔细甄别。

我的建议是 op 可以先考虑一下这个 DSL 是否一定要用造语言来实现，会不会有一些语言内置的语法已经可以表达出来。当然造语言最大的好处大概是可以灵活应对多变的具体场景了。

如果想好了要造 DSL ，可以优先考虑 antlr ，这是一个常用的 parser generator ，可以根据用户提供的文法来生成词法和语法分析器的骨骼，然后让用户自行填入编译器的具体实现。有几本书也是讨论这个的，然后 idea 里面有专门的语法树可视化的插件也很方便。不过我觉得首要的还是得理解一些关于 parser 和编程语言的基本概念了，比如 parser 的分类和不同类型的 parser 有哪些限制。

在这个基础上，op 可以进一步去考虑到底选哪个方向。

yaml 行不行？

最近在写动态表单，关于灵活的表单配置写到最后还是逃不过，不得不实现一套 DSL 解析器的道路。

===
这个我做过 2 次, 不知道你们是否愿意使用第三方的. 专业做问卷 DSL, 细节我不多说, 毕竟还想着靠这个吃饭.


先说我是怎么学的, 毕业进入一家公司, 上来就是修 DSL 的 bug, 解析各种问题. 慢慢的了解了 ast 这些.


第二次我自己重新搞了个 DSL, 都是做表单的.

关键是你把语法定好. 后面解析啥的真没有什么难度, 不要去搞编译原理这些, DSL 的书籍也没多大必要. 我后来学过这些.
因为你的 DSL 特别简单 根据需要不断改就是了. 解析看看(pyparsing,lark)这些, 手写难度也不大.

想看书的话 自制编译器 这种比较贴切一点.

可以在 yaml 的基础上去改造, 个人经验 yaml 是不够的.

我上个帖子说过，与其想着怎么创造新语言，不如想一下如何改进现在的语言。

毕竟不是 10 年前，现在编译技术已经非常完善了，从头造一个 DSL ，最后大概率是玩具级别的，没办法商用。

你只需要想一下，如何最大限度改进现有的语言语法，就已经成功一大半了。

@netabare 更偏向于业务领域专用的 DSL ，大佬的回答很有启发性，感谢感谢

@levelworm yaml/json 也都可以难在怎么解析

@wuhaoecho 非常赞同，我感觉专业问卷的 DSL 核心在于语言模型，语法表达丰富程度，语法丰富控件可配置能力就很高，还有一方面是解析效率，感谢大佬的宝贵经验

@tool2d 感谢大佬回答，毕竟自己没做过这些，卡了很久，想试一试先做一个玩具出来，把这个坎越过去，哪怕是越半步，也能找回一点信心。非常感谢

感谢大佬们的回答，我来说一下目前的思路

- 1.先了解但不深入 编译原理，包括词法解析，语法解析，抽象语法树的知识，这部分可看看公开课并结合语言看看代码，看看别人如何把文本解析成 树形数据结构
- 2.在 github 找一找简单的 DSL ，理解每部分的含义后，照葫芦画瓢写一个试试
- 3.思考如何给 DSL 添加语句并实现
- 4.结合业务写一个简单的 DSL