摘要:方法的产生式如下由得这个函数,包含了除布尔值的表达式之外的,各个表示数据得表达式的解析部分。这里我的链接直接指向了上关于线性渐变的形式语法部分,可以看到这部分对线性渐变语法的描述,和我上面解析的时候所用的产生式如出一辙。
博客源地址:https://github.com/LeuisKen/l...方法说明
相关评论还请到 issue 下。
san.parseExpr是San中主模块下的一个方法。用于将源字符串解析成表达式对象。该方法和san.evalExpr是一对,后者接收一个表达式对象和一个san.Data对象作为参数,用于对表达式进行求值。如下例:
/** * 解析表达式 * * @param {string} source 源码 * @return {Object} 表达式对象 */ function parseExpr(source) {} /** * 计算表达式的值 * * @param {Object} expr 表达式对象 * @param {Data} data 数据容器对象 * @param {Component=} owner 所属组件环境,供 filter 使用 * @return {*} */ function evalExpr(expr, data, owner) {} san.evalExpr(san.parseExpr("1+1"), new san.Data()); // 2 san.evalExpr(san.parseExpr("1+num"), new san.Data({ num: 3 })); // 4
多带带拿出parseExpr来分析,其根据源字符串生成表达式对象,从San的表达式对象文档中,可以看到San支持的表达式类型以及这些表达式对象的结构。我们在这里简单记录一下,parseExpr需要解析的表达式都有哪些:
TertiaryExpr:三元表达式
LogicalORExpr:逻辑或
LogicalANDExpr:逻辑与
EqualityExpr:判等
RelationalExpr:关系(大于、小于等)
AdditiveExpr:加减法
MultiplicativeExpr:乘除法、取余运算
UnaryExpr:一元表达式
ParenthesizedExpr:括号表达式
除了上述表示运算关系的表达式外,还有表示数据的表达式,如下:
String:字符串
Number:数组
Boolean:布尔值
ArrayLiteral:数组字面量
ObjectLiteral:对象字面量
Accessor:访问器表达式
由于Accessor存在意义,是为了在evalExpr阶段从Data对象中获取数据,所以这里我将Accessor归类为表示数据的表达式。
现在我们知道了所有的表达式类型,那么,parseExpr是如何从字符串中,解析出表达式对象的呢?
如何读取字符串parseExpr方法定义在src/parser/parse-expr.js中。我们可以看到其依赖了一个Walker类,注释中的说明是字符串源码读取类。
Walker类包含以下内容:
属性:this.source:保存要读取的源字符串
this.len:保存源字符串长度
this.index:保存当前对象读取字符的位置
方法:currentCode方法:返回当前读取字符的 charCode
charCode方法:返回指定位置字符的 charCode
cut方法:根据指定起始和结束位置返回字符串片段
go方法:将this.index增加给定数值
nextCode方法:读取下一个字符并返回它的 charCode
goUntil 方法/** * 向前读取字符,直到遇到指定字符再停止 * 未指定字符时,当遇到第一个非空格、制表符的字符停止 * * @param {number=} charCode 指定字符的code * @return {boolean} 当指定字符时,返回是否碰到指定的字符 */ Walker.prototype.goUntil = function (charCode) { var code; while (this.index < this.len && (code = this.currentCode())) { switch (code) { // 空格 space case 32: // 制表符 tab case 9: this.index++; break; default: if (code === charCode) { // 找到了 this.index++; return 1; } // 没找到 return; } } };match 方法
/** * 向前读取符合规则的字符片段,并返回规则匹配结果 * * @param {RegExp} reg 字符片段的正则表达式 * @param {boolean} isMatchStart 是否必须匹配当前位置 * @return {Array?} */ Walker.prototype.match = function (reg, isMatchStart) { reg.lastIndex = this.index; var match = reg.exec(this.source); /** * 这里是源码的实现,简洁但是有点晦涩,后面我把逻辑运算符拆成了 if else,希望能好理解一些 if (match && (!isMatchStart || this.index === match.index)) { this.index = reg.lastIndex; return match; } */ if (match) { // 如果是必须匹配当前位置 // 这个标记是 3.5.11 的时候加上的,changelog 表述为: // 【优化】- 在 dev 模式下,增加一些表达式解析错误的提示 if (isMatchStart) { // 判断当前读取字符的 index,是否和匹配结果第一个字符的 index 相等 if (this.index === match.index) { this.index = reg.lastIndex; return match; } } // 不必须匹配当前位置 else { this.index = reg.lastIndex; return match; } } };如何处理运算符的优先级
在初看parseExpr实现的时候,这就是一个困扰我的难题。学习过程中,我看到San最先是将表达式丢给一个读取三元表达式的方法,这个方法里面去调用读取逻辑或表达式的方法,逻辑或里面调用逻辑与,逻辑与里面调用判等,判等里面调用关系⋯⋯看得我可以说是云里雾里。虽然大致能明白这是在处理运算优先级,但是我觉得肯定有一个更上层的指导思想来让San选择这一方案。
为了寻找这个“指导思想”,我转头去看了一段时间的编译原理,大致上理清了这部分思路。考虑到有些同学应该也和我一样没有系统地学习过这门课程,因此我在下面取《编译原理》中的例子来予以说明(下文内容包含了很多定义性的内容,且为了保证严谨,很多定义都是直接照搬书上的,所以如果你对这部分足够熟悉,跳过即可。)
上下文无关文法及其构成假设我们现在要解析的expr是一个十以内的四则运算算式(编译原理将其视为一种语言),其包括加减乘除( +、-、*、/ )四则运算。我们可以使用一种叫做产生式的方式,来表示表达式的解析规则。有了产生式,我们可以将一个算式的解析规则表达成如下形式(这一解析过程被称为词法分析):
expr ---> digit // 这里的 digit 指 0,1,2,3...9 这十个数字 | expr + expr // 竖线(|)表示或,这一行定义了加法 | expr - expr // 减法 | expr * expr // 乘法 | expr / expr // 除法 | (expr) // 加括号
这里介绍几个概念,这里的digit和+ - * / ()等符号,被称为终结符号,表示语言中不可再分的基本符号;而像expr这样能够用于表示终结符号序列的变量,被称为非终结符号。
我们都知道,十以内的四则运算算式的解析是与上下文无关的。在编译原理中,将描述语言构造的层次化语法结构称为“文法”(grammar),我们的十以内的四则运算算式就是一个“上下文无关文法”(context-free grammar)。编译原理中定义了上下文无关文法由四个元素构成:
终结符号集合
非终结符号集合
产生式集合
一个指定的非终结符号作为开始符号(上面的expr)
语法分析树语法分析树是一种图形表示,他展现了从文法的开始符号推导出相应语言中的终结符号串的过程。例如一个给定一个算式:9 - 5 + 2,可以表示成如下的语法分析树:
expr expr + expr expr - expr digit digit digit 2 9 5二义性及其消除
单纯从 9 - 5 + 2 出发去画语法分析树,还能得到另一种结果,如下:
expr expr - expr digit expr + expr 9 digit digit 5 2
如果我们从下往上对语法分析树进行计算,前一棵树先计算 9 - 5 得 4,然后 4 + 2 得 6,但后一棵树的结果则是 5 + 2 得 7,9 - 7 得 2。这就是文法得二义性,其定义为:对于同一个给定的终结符号串,有两棵及以上的语法分析树。由于多棵树意味着多个含义,我们需要设计没有二义性的文法,或给二义性文法添加附加规则来对齐进行消除。
在本例中,我们采用设计文法的方式来消除二义性。由于四则运算中,加减位于一个优先级层次,乘除位于另一个,我们创建两个非终结符号expr和term分别对应这两个层次,并使用另一个非终结符号factor来生成表达式中的基本单元,可得到如下的产生式:
factor ---> digit | (expr) // 考虑乘法和加法的左结合性 term ---> term * factor | term / factor | factor expr ---> expr + term | expr - term | term
有了新的文法之后,我们再看 9 - 5 + 2,其仅能生成如下的唯一语法分析树:
expr expr + term expr - term factor term factor digit factor digit 2 digit 5 9parseExpr 的实现
现在我们回到San中的表达式,有了前面的基础,相信大家都已经清楚了parseExpr解析表达式源字符串方法的缘由。接下来,我们只要合理的定义出来“San中的表达式”这一语言的产生式,函数实现就水到渠成了。
表达式解析入口parseExpr:
/** * 解析表达式 * * @param {string} source 源码 * @return {Object} */ function parseExpr(source) { if (typeof source === "object" && source.type) { return source; } var expr = readTertiaryExpr(new Walker(source)); expr.raw = source; return expr; }
其对应的产生式就是:
Expr ---> TertiaryExpr
readTertiaryExpr:
/** * 读取三元表达式 * * @param {Walker} walker 源码读取对象 * @return {Object} */ function readTertiaryExpr(walker) { var conditional = readLogicalORExpr(walker); walker.goUntil(); if (walker.currentCode() === 63) { // ? walker.go(1); var yesExpr = readTertiaryExpr(walker); walker.goUntil(); if (walker.currentCode() === 58) { // : walker.go(1); return { type: ExprType.TERTIARY, segs: [ conditional, yesExpr, readTertiaryExpr(walker) ] }; } } return conditional; }
可以看到,判断条件部分conditional是readLogicalORExpr的结果。如果存在?、:两个和三元表达式相关的终结符号,就返回一个三元表达式类型的表达式对象;否则直接返回conditional。可知产生式:
TertiaryExpr ---> LogicalORExpr ? TertiaryExpr : TertiaryExpr | LogicalORExpr
由readLogicalORExpr可得产生式:
LogicalORExpr ---> LogicalORExpr || LogicalANDExpr | LogicalANDExpr
由readLogicalANDExpr得:
LogicalANDExpr ---> LogicalANDExpr && EqualityExpr | EqualityExpr
由readEqualityExpr得:
EqualityExpr ---> RelationalExpr == RelationalExpr | RelationalExpr != RelationalExpr | RelationalExpr === RelationalExpr | RelationalExpr !== RelationalExpr | RelationalExpr
由readRelationalExpr得:
RelationalExpr ---> AdditiveExpr > AdditiveExpr | AdditiveExpr < AdditiveExpr | AdditiveExpr >= AdditiveExpr | AdditiveExpr <= AdditiveExpr | AdditiveExpr
readAdditiveExpr:
/** * 读取加法表达式 * * @param {Walker} walker 源码读取对象 * @return {Object} */ function readAdditiveExpr(walker) { var expr = readMultiplicativeExpr(walker); while (1) { walker.goUntil(); var code = walker.currentCode(); switch (code) { case 43: // + case 45: // - walker.go(1); // 这里创建了一个新对象,包住了原来的 expr,返回了一个新的 expr expr = { type: ExprType.BINARY, operator: code, segs: [expr, readMultiplicativeExpr(walker)] }; // 注意到这里是 continue,之前的函数都是 return continue; } break; } return expr; }
读加法的这个函数有些特殊,其在第一步先调用了读乘法的方法,得到了变量expr,然后不断地更新expr对象包住原来的对象,以保证结合性的正确。
方法的产生式如下:
AdditiveExpr ---> AdditiveExpr + MultiplicativeExpr | AdditiveExpr - MultiplicativeExpr | MultiplicativeExpr
由readMultiplicativeExpr得:
MultiplicativeExpr ---> MultiplicativeExpr * UnaryExpr | MultiplicativeExpr / UnaryExpr | MultiplicativeExpr % UnaryExpr | UnaryExpr
readUnaryExpr这个函数,包含了除布尔值的表达式之外的,各个表示数据得表达式的解析部分。因此对应的产生式也相对复杂,为了便于说明,我自行引入了一些非终结符号:
UnaryExpr ---> !UnaryExpr | "String" | "String" | Number | ArrayLiteral | ObjectLiteral | ParenthesizedExpr | Accessor ArrayLiteral ---> [] | [ElementList] // 这里引入一个新的非终结符号 ElementList 来辅助说明 ElementList ---> Element | ElementList, Element Element ---> TertiaryExpr | ...TertiaryExpr ObjectLiteral ---> {} | {FieldList} // 类似上面的 ElementList FieldList ---> Field | FieldList, Field Field ---> ...TertiaryExpr | SimpleExpr | SimpleExpr: TertiaryExpr SimpleExpr ---> true | false | "String" | "String" | Number
由readParenthesizedExpr得:
ParenthesizedExpr ---> (TertiaryExpr)
由readAccessor得:
Accessor ---> true | false | Identifier MemberOperator* // 此处 * 表示 0个或多个的意思 MemberOperator ---> .Identifier | [TertiaryExpr]
至此,我们终于把所有的产生式都梳理清楚了。
和 JavaScript 文法的对比在这里我附上一份JavaScript 1.4 Grammar供参考。通过对比两种文法产生式的不同,能找到很多两者之间解析结果得差异。下面是一个例子:
1 > 2 < 3 // 返回 true,相当于 1 > 2 返回 false,false < 3 返回 true san.evalExpr(san.parseExpr("1 > 2 < 3"), new san.Data()); // 返回 false
注意到 San 中关于RelationalExpression的产生式是:
RelationalExpr ---> AdditiveExpr > AdditiveExpr | AdditiveExpr < AdditiveExpr | AdditiveExpr >= AdditiveExpr | AdditiveExpr <= AdditiveExpr | AdditiveExpr
也就是说,对于1 > 2 < 3,其匹配了RelationalExpr ---> AdditiveExpr > AdditiveExpr。其中1传入了AdditiveExpr解析成Number的1;2 < 3则被视为另一个AdditiveExpr进行解析,由于后面已经没有能够处理<的逻辑了,所以会被解析成Number的2。所以,输入的1 > 2 < 3,真正解析出来的就只有1 > 2了,所以上面的代码会返回 false 。
个人认为 San 在这里应该是刻意为之的。因为对于1 > 2 < 3这种表达式,真的没必要保证它按照JavaScript的文法来解析——这种代码写出来肯定是要改的,没有顾及它的意义。
拓展了解了 parseExpr 是如何从源字符串得到表达式对象之后,也就发现其实很多地方都用了类似的方法来描述语法。比如CSS 线性渐变。这里我的链接直接指向了MDN上关于线性渐变的形式语法(Formal syntax)部分,可以看到这部分对线性渐变语法的描述,和我上面解析 parseExpr 的时候所用的产生式如出一辙。
linear-gradient( [| to ,]? [, ]+ ) ---------------------------------/ ----------------------------/ Definition of the gradient line List of color stops where = [left | right] || [top | bottom] and = [ | ]?
这种语法形式是MDN定义的CSS属性值定义语法。
参照我们前面所写的产生式与上面的CSS属性值定义语法,我写出了如下的产生式:
expr ---> gradientLine , colorStopList | colorStopList gradientLine ---> angle | to sideOrCorner sideOrCorner ---> horizon | vertical | horizon vertical | vertical horizon horizon ---> left | right vertical ---> top | bottom colorStopList ---> colorStopList, color distance | color distance color ---> hexColor | rgbColor | rgbaColor | literalColor | hslColor // 相信大家都懂,我就不做进一步展开了 distance ---> percentage | length // 同上,不做进一步展开结语
这一趟下来可以说是补了不少课,也揭示了 San 中内部原理的一角,后面计划把 evalExpr、Data、parseTemplate等方法也学习一遍,进一步了解 San 的全貌。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/95530.html
摘要:此文用于汇总跟随陈雷老师及团队的视频,学习源码过程中的思考整理与心得体会,此文会不断更新视频传送门每日学习记录使用录像设备记录每天的学习源码学习源码学习内存管理笔记源码学习内存管理笔记源码学习内存管理笔记源码学习基本变量笔记 此文用于汇总跟随陈雷老师及团队的视频,学习源码过程中的思考、整理与心得体会,此文会不断更新 视频传送门:【每日学习记录】使用录像设备记录每天的学习 PHP7...
摘要:有如下模块源码解析源码解析源码解析源码解析源码解析源码解析源码解析源码解析源码解析使用和监控和博客从到学习介绍从到学习上搭建环境并构建运行简单程序入门从到学习配置文件详解从到学习介绍从到学习如何自 Flink Metrics 有如下模块: Flink Metrics 源码解析 —— Flink-metrics-core Flink Metrics 源码解析 —— Flink-metr...
摘要:模块中的类结构如下博客从到学习介绍从到学习上搭建环境并构建运行简单程序入门从到学习配置文件详解从到学习介绍从到学习如何自定义从到学习介绍从到学习如何自定义从到学习转换从到学习介绍中的从到学习中的几种详解从到学习读取数据写入到从到学 Flink-Client 模块中的类结构如下: https://t.zsxq.com/IMzNZjY showImg(https://segmentfau...
阅读 3188·2023-04-26 03:06
阅读 3687·2021-11-22 09:34
阅读 1132·2021-10-08 10:05
阅读 3022·2021-09-22 15:53
阅读 3528·2021-09-14 18:05
阅读 1384·2021-08-05 09:56
阅读 1877·2019-08-30 15:56
阅读 2123·2019-08-29 11:02