duangsuse::Echo
716 subscribers
4.25K photos
130 videos
583 files
6.47K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
Lexical Scoping 我不用说吧,递归下降解析了解到 (lambda (a b) (+ a b)) 的 formals 里的 "a" "b" 与 body 里 (+ a b) 存在的1:1对应关系,就可以很自然地把他们联系起来了,之后怎么处理都好,例如像 Lua 一样把它们翻译为函数局部寄存器的编号,然后每次调用的时候给它们分配一对一的存储空间,caller调用侧和callee被调用侧都知道那个"a" "b"是指代哪片分配就好。
duangsuse::Echo
既然都这么弄了,还不如直接把优化写成代码算了……
虽然那个栈的中缀链貌似很高级,而且貌似递归下降的在很极端的情况下输出和 JS 不同,但我还是觉得应该选它,至少它看起来很简单,只 (base, op_left) 两个递归参数就够了,最重要的是它使用的栈是在语言层面受到支持的,而且这个支持本身实现的也很优雅很妥帖(要不然那语言还有用么……)。
好了,我整理完了,包含两部分:代码和定义
待会我还要把 ParserKt JSON (jison) 的解析器定义代码也打印了
cat /usr/share/katepart/syntax/logohighlightstyle.en_GB.xml

这好像有分词高亮的,我考虑一下是不是可以……

绝句有些软关键字(就是仍然可以直接作为名字的,一般它们都跟在其他关键字后面)
不过没关系,可以全都视作关键字看待
https://kate-editor.org/syntax/data/syntax/kotlin.xml

牛批啊,这么说我就照着Kotlin的样子不需要几秒钟能定义 syntax highlight? 🤪??
package import sealed data class enum interface companion object private public protected internal open final get set fun var val constructor inline reified crossinline tailrec in out is as by where vararg get set return throw typealias typeof override infix operator if else when for while do try catch finally continue break yield this super null true false Unit Nothing String Char Int Long Byte Short Float Double Boolean

包 为 其中 引 引全 成 除
定记法 引记法 属别名 类 物 例 况物 储物 例物 记物 内物 内联物 伴生例
私下 族内 公开 内部
开放 终定 覆写
抽象 实现
待例 实际
内联 晚成
算符 尾递归
许多 跨嵌 不嵌
记法
若 否则
判 判断 于
对 解对 里的
重复若 重复 若
尝试 接迎 成 终焉
真 入 出
属 不属 作 试作 存于 不存于
回 抛下 停下 略过 断续
造于 我 亲
空 真 假
效果 断止 文 字
真假 字节 短数 数 长数 短实数 实数
取者 置者 代者
事 量 解量 常 变 常参 变参
哈,还好我肯定是理解状态机的,可是,绝句的 """ 为 是代不可枚举上下文的,没办法支持啊……
🤔突然发现那不是人手工维护的事,应该由某些工具自动生成。
https://kate-editor.org/2005/03/24/writing-a-syntax-highlighting-file/

我真是服了,这么多明显是机器做的东西他们搞个什么 detect2Chars, detectWord, detect... 还甚至lineEndContext, lineBeginContext,写Haskell规则的那位那么Haskell都没见能支持Indented Heredoc(当然词法阶段和目的也没法怎么样)
我开始考虑那种Heredoc虽然看起不错,是不是对许多语言工具都会产生大问题,还是去掉,和Kotlin一样trimIndent、trimPrefix好了……

dynamic if true, the context remembers strings/placeholders saved by dynamic rules. This is needed for HERE documents for example. Default: false.

好利害的样子啊…… 居然能够支持 heredoc…… 而且死板一点的 layout 布局文法也可以支持吧,不过那就是文法阶段的事情了。
9012 年了还用XML且不提供其他的翻译方案,真不知道那语言支持规则该如何维护是好。
想要弄回来还得『反编译』,也真是佩服工程师们的精力和耐力。
来给整理一下,这Kotlin词法(包括TODO,『待写』):
\b[_\w][_\w\d]*(\.[_\w][_\w\d]*)*(\.\*)? 据说这是全称名(qualified-name)的regex,绝句里叫『无的复名』,因为能带「的」的全称更常见

Symbol 符号
Comment 注释
“(Comment|.)*?”
"String Char" Unicode转义
\\u[0-9a-fA-F]{4}
String 常文

Char 常字
'(Unicode转义|.)'
Decimal 常数
"Data Type" 物类
Annotation 记物修饰
Import 书引入
包 (无的复名) 为
引 (复名) [成 名]
引全 (复名) [除 joinBy(同行空格(、),名)]
定记法 「.+」
引记法 无的复名 [除] 「.+」
Variable 变量
Function 事定义
ControlFlow 控制流构词
Keyword 普通构词
"Normal Text" 代码文本

很绝望,我估计如果加了基于布局的"Heredoc",不能支持的编辑器会多10k倍…… 🤪
有学有样了……
绝句词法.txt
2.3 KB
虽然最后(而且现在太晚了……)没有完成对 「的」「去」的高亮分词兼容,但是我总结出了这个,很方便继续修改。