n*****t
发帖数: 22014 | 1 是用 yacc/lex 写的，还有人记得这对活宝么？ |
L*****e
发帖数: 8347 | 2 不明觉厉。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 n*****t 的大作中提到】
: 是用 yacc/lex 写的，还有人记得这对活宝么？
|
e***e
发帖数: 3872 | 3 葵花宝典上这类问题都用yacc/lex做：命令行解释器，customized的语言什么的，自己
写parser才活宝吧
【在 n*****t 的大作中提到】
: 是用 yacc/lex 写的，还有人记得这对活宝么？
|
n*****t
发帖数: 22014 | 4 不是吧，这玩意很好玩的，早年用这玩意读 config file，很爽很爽很爽
【在 L*****e 的大作中提到】
: 不明觉厉。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
S*A
发帖数: 7142 | 5 Lex 还行，但是Lex 很简单，自己手写也没有多少。
YACC 做编译器有很多限制，最大的问题是出错的恢复。
例如编程少打个‘；’， 然后编译器就彻底晕菜了。
很不容易跳过这个缺少的‘；’从下一句开始继续编译。
关键在于那个状态转换图是机器自动生成的，里面的过程
人是不参与的，恢复到上个可以继续的状态必须要手工
干预。这个状态图没有直观理解。这就是为什么老的 gcc
有时给出特别莫名其妙的错误信息。
LLVM 就完全没有用 YACC， gcc 以前用 YACC， 后来
也改用手动写了。
Perl 是用 YACC 的，当年我还仔细看过，得出的结论是
那个 YACC 完全是摆设。Perl 的隐含规则特别多，在不同
的 scope 里面可以干不同的事情。Perl 的YACC 里面最关键
的部分是对这些编译状态的维护，这些完全是在 YACC 以外
的。等到喂给 YACC 的时候已经完全确定下面可以发生什么。
YACC 就是走个过场而已，让你觉得 Perl 还有个语法树，其
实是没有的。这也是为什么只有 Perl 可以完全解释 Perl 的
语法。
YACC 基本上除了玩具编译项目不太值得严肃使用，认真用
精力浪费在和条条框框做斗争上，要比 YACC 带来的便利多。 |
t****t
发帖数: 6806 | 6 我还用yacc和lex呢.
【在 n*****t 的大作中提到】
: 是用 yacc/lex 写的，还有人记得这对活宝么？
|
x****u
发帖数: 44466 | 7 你的项目如果远比YACC复杂，那当然可以考虑自己做一个语法解析。
【在 S*A 的大作中提到】
: Lex 还行，但是Lex 很简单，自己手写也没有多少。
: YACC 做编译器有很多限制，最大的问题是出错的恢复。
: 例如编程少打个‘；’， 然后编译器就彻底晕菜了。
: 很不容易跳过这个缺少的‘；’从下一句开始继续编译。
: 关键在于那个状态转换图是机器自动生成的，里面的过程
: 人是不参与的，恢复到上个可以继续的状态必须要手工
: 干预。这个状态图没有直观理解。这就是为什么老的 gcc
: 有时给出特别莫名其妙的错误信息。
: LLVM 就完全没有用 YACC， gcc 以前用 YACC， 后来
: 也改用手动写了。
|
s*****r
发帖数: 43070 | 8 atoi就是parser，用这个不算离谱
【在 n*****t 的大作中提到】
: 是用 yacc/lex 写的，还有人记得这对活宝么？
|
l*********s
发帖数: 5409 | 9 不明觉历
【在 S*A 的大作中提到】
: Lex 还行，但是Lex 很简单，自己手写也没有多少。
: YACC 做编译器有很多限制，最大的问题是出错的恢复。
: 例如编程少打个‘；’， 然后编译器就彻底晕菜了。
: 很不容易跳过这个缺少的‘；’从下一句开始继续编译。
: 关键在于那个状态转换图是机器自动生成的，里面的过程
: 人是不参与的，恢复到上个可以继续的状态必须要手工
: 干预。这个状态图没有直观理解。这就是为什么老的 gcc
: 有时给出特别莫名其妙的错误信息。
: LLVM 就完全没有用 YACC， gcc 以前用 YACC， 后来
: 也改用手动写了。
|
n*****t
发帖数: 22014 | 10 热泪盈眶，忍不住跑到车库里翻出那本发黄的小册子，发现首版居然是 1992 年 |
|
|
g*****n
发帖数: 420 | 11 写parser,还是antlr好用啊,Hibernate的HQL就是用的Antlr |
d***a
发帖数: 13752 | 12 我觉得yacc还行。很早以前我用yacc写过SQL的parser。
yacc是LALR类型的parser生成器，生成的语法树不太直观，
但运行效率比较好，用于SQL解析还是不错的。
【在 S*A 的大作中提到】
: Lex 还行，但是Lex 很简单，自己手写也没有多少。
: YACC 做编译器有很多限制，最大的问题是出错的恢复。
: 例如编程少打个‘；’， 然后编译器就彻底晕菜了。
: 很不容易跳过这个缺少的‘；’从下一句开始继续编译。
: 关键在于那个状态转换图是机器自动生成的，里面的过程
: 人是不参与的，恢复到上个可以继续的状态必须要手工
: 干预。这个状态图没有直观理解。这就是为什么老的 gcc
: 有时给出特别莫名其妙的错误信息。
: LLVM 就完全没有用 YACC， gcc 以前用 YACC， 后来
: 也改用手动写了。
|
c*******9
发帖数: 9032 | 13 Haskell的parserc好用的多。
【在 d***a 的大作中提到】
: 我觉得yacc还行。很早以前我用yacc写过SQL的parser。
: yacc是LALR类型的parser生成器，生成的语法树不太直观，
: 但运行效率比较好，用于SQL解析还是不错的。
|
S*A
发帖数: 7142 | 14 用在 SQL 大概比 C 要好些，因为一般 SQL 要比 C
短很多然后语法也简单很多。这样大概报错的时候不
是特别精确问题也并不大。但是如果一旦你要对报错
有一定要求，YACC 就会很不爽。
运行效率上用 C 手写的更高些。编译 C 程序的话，
在 Lex 部分的花的 CPU 要比语法分析的多，因为那里
是循环最密集的地方。语法部分的程序的密集程度没有
Lex 部分高。
【在 d***a 的大作中提到】
: 我觉得yacc还行。很早以前我用yacc写过SQL的parser。
: yacc是LALR类型的parser生成器，生成的语法树不太直观，
: 但运行效率比较好，用于SQL解析还是不错的。
|
d***a
发帖数: 13752 | 15 SQL解析对报错的要求不高，适合用yacc来写。报错性不好，LR型parser都有这个问题。
yacc/lex后来被bison/flex取代了。Bison生成的代码，效率是不错的。flex部分，可
以手写来提高效率。
【在 S*A 的大作中提到】
: 用在 SQL 大概比 C 要好些，因为一般 SQL 要比 C
: 短很多然后语法也简单很多。这样大概报错的时候不
: 是特别精确问题也并不大。但是如果一旦你要对报错
: 有一定要求，YACC 就会很不爽。
: 运行效率上用 C 手写的更高些。编译 C 程序的话，
: 在 Lex 部分的花的 CPU 要比语法分析的多，因为那里
: 是循环最密集的地方。语法部分的程序的密集程度没有
: Lex 部分高。
|
d***a
发帖数: 13752 | 16 嗯...我写那个的时候，Haskell还没有成型。:)
【在 c*******9 的大作中提到】
: Haskell的parserc好用的多。
|
n*****t
发帖数: 22014 | 17 一般用这些写的，对效率要求不高，对灵活性和扩展性要求很高。大多是用来实现自定
义的 config 或者 script，比如定义一些变量，能生成一些诸如 php.ini 之类的东西。
【在 S*A 的大作中提到】
: 用在 SQL 大概比 C 要好些，因为一般 SQL 要比 C
: 短很多然后语法也简单很多。这样大概报错的时候不
: 是特别精确问题也并不大。但是如果一旦你要对报错
: 有一定要求，YACC 就会很不爽。
: 运行效率上用 C 手写的更高些。编译 C 程序的话，
: 在 Lex 部分的花的 CPU 要比语法分析的多，因为那里
: 是循环最密集的地方。语法部分的程序的密集程度没有
: Lex 部分高。
|
S*A
发帖数: 7142 | 18 对灵活性和扩展性要求高才不能用 YACC 呢。
你实验一下用 C 直接嵌套一段汇编的语法，不是把
汇编放在字符串里面就知道了。
那种简单的变量赋值用直接 C 写也很方便。
西。
【在 n*****t 的大作中提到】
: 一般用这些写的，对效率要求不高，对灵活性和扩展性要求很高。大多是用来实现自定
: 义的 config 或者 script，比如定义一些变量，能生成一些诸如 php.ini 之类的东西。
|
d***a
发帖数: 13752 | 19 Yacc是早期最有名的LALR解析器生成工具。LALR是LR(k)的一种。LR(k)的语言
覆盖面比LL(k)型要大。LL(k)解析器，特别是LL(1)解析器，有一个问题，
就是会有不少语言要修改后才能被LL(1)接受。从这个角度来说，用Yacc确
实有利于语言的灵活性和扩展性。
手工写解析器，并不会比自动生成的解析器更优化吧。语言稍复杂一点，
手工方式的各种计算十分繁琐，容易出错。如果语言有一点改变，还得
重头来过。
【在 S*A 的大作中提到】
: 对灵活性和扩展性要求高才不能用 YACC 呢。
: 你实验一下用 C 直接嵌套一段汇编的语法，不是把
: 汇编放在字符串里面就知道了。
: 那种简单的变量赋值用直接 C 写也很方便。
:
: 西。
|
S*A
发帖数: 7142 | 20
问题是现实中很多语言不是严格 LR(k) 的。如果有不是 LR（K）的扩展就
郁闷了
这个不一定，自动生成的都是间接跳转，这个在 Intel 体系上面会 flush
instruction pipeline。直接写的多数是直接调用，不会 flush instruction
pipeline。 YACC 真的是那末好用 gcc 和 LLVM 的人都是傻子不用？
特别是 gcc 还要放弃 YACC 从新写。人家是非常不情愿但是又是在没办法
了。
【在 d***a 的大作中提到】
: Yacc是早期最有名的LALR解析器生成工具。LALR是LR(k)的一种。LR(k)的语言
: 覆盖面比LL(k)型要大。LL(k)解析器，特别是LL(1)解析器，有一个问题，
: 就是会有不少语言要修改后才能被LL(1)接受。从这个角度来说，用Yacc确
: 实有利于语言的灵活性和扩展性。
: 手工写解析器，并不会比自动生成的解析器更优化吧。语言稍复杂一点，
: 手工方式的各种计算十分繁琐，容易出错。如果语言有一点改变，还得
: 重头来过。
|
|
|
g*****n
发帖数: 420 | 21 新的JavaFX的编译器是用Antlr, 新的Antlr3是LL(*)的,生成的代码类似于手写的,比较
容易理解. |
d***a
发帖数: 13752 | 22 以前gcc不就是用yacc的吗? 为什么以前不手写呢？
手写有一定的好处，比如说报错的方式可以更加人性化。但手写很容易出错，这是手写
不好的地方。如果有一个大的团队，手写是可行的。
性能不是问题。Intel处理器上现在有indirect branch的predictor。另外我记得以前
yacc生成的代码，用的是goto语句。
【在 S*A 的大作中提到】
:
: 问题是现实中很多语言不是严格 LR(k) 的。如果有不是 LR（K）的扩展就
: 郁闷了
: 这个不一定，自动生成的都是间接跳转，这个在 Intel 体系上面会 flush
: instruction pipeline。直接写的多数是直接调用，不会 flush instruction
: pipeline。 YACC 真的是那末好用 gcc 和 LLVM 的人都是傻子不用？
: 特别是 gcc 还要放弃 YACC 从新写。人家是非常不情愿但是又是在没办法
: 了。
|
d***a
发帖数: 13752 | 23 是这样。Yacc是LR型的，用bottom-up方式来解析，生成的代码不好理解。
【在 g*****n 的大作中提到】
: 新的JavaFX的编译器是用Antlr, 新的Antlr3是LL(*)的,生成的代码类似于手写的,比较
: 容易理解.
|
S*A
发帖数: 7142 | 24 手写其实更容易维护。看看 gcc 转换的时候是如何说的，
YACC 把代码切成一小段一小段的，中间还有个
黑盒子的状态树，其实维护更加困难。C 其实不是
严格 LLK 语法的。
BTW 注意到手写后速度还轻微提高了没有？
http://gcc.gnu.org/wiki/New_C_Parser
Benefits:
Although timings showed a 1.5% speedup, the main benefits are
facilitating of future enhancements including: OpenMP pragma support; lexing
up front for C so reducing the number of different code paths; diagnostic
location improvements (and potentially other diagnostic improvements);
merging cc1/cc1obj into a single executable with runtime conditionals (which
has been of interest to some Apple people in the past). Many defects and
oddities in the existing parser which would not have been readily fixable
there have been identified, recorded with ??? comments in the new parser and
reproduced bug-compatibly and the new parser will facilitate their fixing.
【在 d***a 的大作中提到】
: 以前gcc不就是用yacc的吗? 为什么以前不手写呢？
: 手写有一定的好处，比如说报错的方式可以更加人性化。但手写很容易出错，这是手写
: 不好的地方。如果有一个大的团队，手写是可行的。
: 性能不是问题。Intel处理器上现在有indirect branch的predictor。另外我记得以前
: yacc生成的代码，用的是goto语句。
|
