Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

我感觉这个语言可以再改进一下,把缩进以外的空格全都去掉,这样就完美了。 #115

Closed
vczh opened this issue Apr 19, 2022 · 10 comments

Comments

@vczh
Copy link

vczh commented Apr 19, 2022

可以参考一下我以前的小玩具:https://github.com/vczh/tinymoe

具体的技术细节我已经实践过了,肯定是没问题的。主要想法就是,把输入的脚本的自定义符号先提取出来,然后在内存中当场生成一个GLR parser,再把输入的脚本parse一遍,就得到了一颗AST。处理局部符号的时候,一边parse一边改parser就好了。

🤪

@zhanyong-wan
Copy link
Owner

这个语言里所有字符串之外的空格都是忽略的,包括缩进在内。你发现有什么地方空格是必须的吗?

@nobodxbodon
Copy link

之前提过 为识别带有关键词的标识符,可以尝试按语法分词,不知与 tinymoe 的解析机制是否有相似之处。

@vczh
Copy link
Author

vczh commented Apr 27, 2022

我在sample里面看到很多类似这样的语句

张家庄 都是活雷锋。
张家庄 装「二加三,“大”」。
张家庄 装 路银「二加三,“大”」。
张家庄 来了个 三。

你的意思是写成这样也可以?

张家庄都是活雷锋。
张家庄装「二加三,“大”」。
张家庄装路银「二加三,“大”」。
张家庄来了个三。

@zhanyong-wan
Copy link
Owner

是的。文档里说了: https://github.com/zhanyong-wan/dongbei/blob/master/doc/dongbei-ref.md#%E5%88%86%E8%AF%8D

@vczh
Copy link
Author

vczh commented Apr 27, 2022

@nobodxbodon 看了那个文章,感觉应该是完全不一样的想法。tinymoe同一句话放在不同的上下文里面,parse出来可能是完全不同的AST,这基本取决于你在上下文里面定义了多少不同的“短语”。举个例子,print the number

如果上下文定义了print (x)函数和the number变量,那他就是print (the_number)

你甚至可以,定义一个(x) the number函数,x是一个functor,那他就变成了 __the_number (print)

你也可以定义一个函数,他就叫print the number,那这句话的意思就变成了print_the_number()

这些规则是递归的,也就是有句话过去,有可能是一大堆函数调用嵌套在一起。

@nobodxbodon
Copy link

@vczh 谢谢介绍。之前个人的实现基本是深度优先搜索找出首个符合语法规则的分词方式,虽有缺陷不过应付比较简单且嵌套较少的语法规则似乎还可以。

tinymoe 这样结合上下文语法元素进行分词感觉比较理想,不过会否有语句A分析依赖于语句B分析但B又依赖A的情况?

@vczh
Copy link
Author

vczh commented Apr 29, 2022

@nobodxbodon

不过会否有语句A分析依赖于语句B分析但B又依赖A的情况?

其实是不会的,因为tinymoe的两边分析,第一遍是先把函数头抽出来,第二遍是分析每一个语句。每一个语句的分析都是独立的,只有声明才会创造新的语法,语句不会。

不过常见的问题是优先级和歧义的问题,tinymoe为了贴合英语的表达,对优先级做了一些限制,过滤掉了经常发生的一些歧义。这么说可能不太清楚,我举个例子。现在有两个函数:sum (x)(x) and print,于是下面的代码:

sum [1,2,3] and print

就有两种解释:

  • sum ([1,2,3] and print)
  • (sum [1,2,3]) and print

具体的解决方法是,函数可以是phrase也可以是sentence,sentence只能出现在根节点。如果都是phrase,那tinymoe会试图规定那个看起来更常见,当然也有tinymoe实在判断不了的时候,会报歧义错误。不过由于年代久远,这方面的细节我已经忘记了。

@nobodxbodon
Copy link

@vczh 没理解错的话,声明不会有歧义,语句才会有?

个人感觉,如果是接近自然语言风格的代码,在可读性较好时出现歧义的情况并不太多,歧义处理规则只要能覆盖常用代码,开发者的使用体验就不会太差。在使用中如发现严重歧义的情况,再考虑处理方法不迟。

话说,年前作了点将反馈信息语法和代码语法一致化的设计尝试(流水在此),有空的话烦请批评一下?

@vczh
Copy link
Author

vczh commented May 1, 2022

@nobodxbodon

我还没怎么仔细考虑过你帖子里面的问题,感觉如何表达一个query,需要下很多功夫。特别是编程语言到处都是嵌套的从句,但是中文并不喜欢。

@nobodxbodon
Copy link

@vczh query是指那个sql领域专用语言原型吗?之前暂用了这种语法(详见源码):

获取出生年大于2000的读者的邮箱、昵称,按出生年倒序排列。

不过楼上提到的设计是 另外这个

> 摄氏度是180
摄氏度是180

> 华氏度是摄氏度乘9除以5加32
华氏度是摄氏度乘9除以5加32,华氏度是356

> 摄氏度是200
摄氏度是200,华氏度是392

特色是反馈信息语法和代码语法保持一致。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants