最近在写动态表单,关于灵活的表单配置写到最后还是逃不过,不得不实现一套 DSL 解析器的道路。
当然,不单单是动态表单,涉及到灵活配置的大多最后都会实现一套 DSL ,在 Web 端用图形界面生成 DSL 的语句,然后代码解析(或是后端的运行时解析器,在后端运行语句),最后渲染(后端对应的是返回结果)。
DSL 解析器 是目前来说对我最大的障碍 /瓶颈,非常打击自信心。
今年想下定决心把这个心结解决掉。
1
netabare 2023-02-27 03:06:05 +08:00 via Android 2
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 可以进一步去考虑到底选哪个方向。 |
2
levelworm 2023-02-27 04:37:49 +08:00 via Android 1
yaml 行不行?
|
3
echoless 2023-02-27 09:17:57 +08:00 1
最近在写动态表单,关于灵活的表单配置写到最后还是逃不过,不得不实现一套 DSL 解析器的道路。
=== 这个我做过 2 次, 不知道你们是否愿意使用第三方的. 专业做问卷 DSL, 细节我不多说, 毕竟还想着靠这个吃饭. 先说我是怎么学的, 毕业进入一家公司, 上来就是修 DSL 的 bug, 解析各种问题. 慢慢的了解了 ast 这些. 第二次我自己重新搞了个 DSL, 都是做表单的. 关键是你把语法定好. 后面解析啥的真没有什么难度, 不要去搞编译原理这些, DSL 的书籍也没多大必要. 我后来学过这些. 因为你的 DSL 特别简单 根据需要不断改就是了. 解析看看(pyparsing,lark)这些, 手写难度也不大. 想看书的话 自制编译器 这种比较贴切一点. 可以在 yaml 的基础上去改造, 个人经验 yaml 是不够的. |
4
tool2d 2023-02-27 10:06:39 +08:00 1
我上个帖子说过,与其想着怎么创造新语言,不如想一下如何改进现在的语言。
毕竟不是 10 年前,现在编译技术已经非常完善了,从头造一个 DSL ,最后大概率是玩具级别的,没办法商用。 你只需要想一下,如何最大限度改进现有的语言语法,就已经成功一大半了。 |
5
anonymous2351d00 OP |
6
anonymous2351d00 OP 感谢大佬们的回答,我来说一下目前的思路
- 1.先了解但不深入 编译原理,包括词法解析,语法解析,抽象语法树的知识,这部分可看看公开课并结合语言看看代码,看看别人如何把文本解析成 树形数据结构 - 2.在 github 找一找简单的 DSL ,理解每部分的含义后,照葫芦画瓢写一个试试 - 3.思考如何给 DSL 添加语句并实现 - 4.结合业务写一个简单的 DSL |