两周自制脚本语言——2.3 含糊不得的语言

如果代码中能够随处省略分号，并可以任意换行，似乎可读性就会提升。但要是一种程序设计语言的各种语法元素都能省略，语句中任何地方都能换行，它就可能会变得模棱两可，引起误解。 如果语言的含义不清，程序员就无法判断程序的实际执行方式，这会造成很大的麻烦。事实上，如何为这种语言设计语言处理器也很让人头疼。在设计一种语言时，设计者必须多加注意，确保语言中不出现模棱两可的歧义语法。 A 刚刚讨论的句尾分号的省略问题，不会有什么歧义吧？ H 如果一个分号不能省略，又没有明确的不可省略的理由，会让人感到很困惑呢。 C 我在设计时已经尽力避免出现这种情况了。不过刚才的说明确实不够明了，不太容易理解。 F 我倒是觉得多写几个分号不是什么问题，不过似乎大家都不喜欢写分号嘛。 C 就是呀，如果语句必须由分号结束，就不会有那么多问题了。 S 嗯，不过从使用者的角度来看，能不用的东西肯定是不用比较好。 C 顺便一提，基于类似的理由，Stone语言也不会支持Ruby语言的正则表达式字面量。 A 正则表达式字面量？ C 如果只要把两个/内的内容视作正则表达式字面量自然没什么问题，不过/本身还是除号不是吗？比如说，x / ruby / 3该怎样理解呢？ S 嗯，/的含义可以通过上下文来判断。 C 话虽如此，不过通过上下文判断并不容易，实现起来也较为复杂，因此Stone语言就不支持这种语法了。 例如，Stone语言中while语句体必须由大括号{}包围。if语句也是如此。条件表达式不一定非要用括号括起，但这两个语句体两侧必须使用括号。 如果像Java语言那样，语句体内仅含一条语句时可以不使用括号，就会出现下面这样的歧义。 if 0 < x - y - z 这句if语句能有两种解读方式。 if 0 < x - y { -z } if 0 < x { -y - z } 前者的条件表达式是0 < x - y，如果为真则结果为-z，后者的条件表达式为0 < x，如果为真则结果为-y - z。如果这种语言的语法明确规定了如何解释这种情况，语言处理器也做了相应的实现，自然没有问题，否则这种语法就是模棱两可的。要明确规定如何判断并不是一件容易的事，因此Stone语言的语句体必须使用{}括起来，避免出现这个问题。 F 只要在可能产生歧义时使用括号不就可以了吗？ H 这可不行，万一在应该使用的地方没有使用括号，就出问题了。 F 忘记使用括号而导致了二义性时，把它判定为语法错误不就行了？ C 要设计出能够发现这类语法错误的语言处理器可是一件大工程了。 if语句的dangling-else问题是一个著名的二义语法。例如，Java语言允许下面这样的if语句。由于语句体中只有一条语句，因此无需使用大括号。 if (x > 0) if (y > 0) return x + y; else return -x; 这段代码的问题在于判断else应当对应哪一个if。如果语法没有对此做出明确规定，两个if都没问题。Java语言当然做了规定，在这种情况下，else与最近的一个if对应，因此不存在歧义（因此，上面代码中的缩进是不恰当的）。如果在设计语言时欠考虑，就很容易出现这类dangling-else问题，使语言变得模棱两可。为此，设计者必须万分小心。 A Stone语言会怎样处理dangling-else问题呢？ C 因为语句体必须被大括号包围，所以不存在这个问题。 H A君，在Stone语言里，如果像下面这么写。 if x > 0 { if y > 0 { x + y }} else { -x } 显然else对应的是第一个if。 如果写成这样 if x > 0 { if y > 0 { x + y } else { -x }} 就明显是与第2个对应。由于语句体外必须写有{}，因此不会产生歧义。 F 老师，我刚发现Stone语言里是不能使用else if的呢。 if x > 0 { y = 1 } else { if x == 0 { y = 0 } else { y = -1 }} 因为一定要使用括号括起来，所以第3行的else与if之间不得不插入一个{。 C 是呢，Stone语言的语法中的确有很多地方能挑出毛病。添加else if语法的事就当作读者的课后习题好了。 F 呃，这样也行吗？！