|
锁定老帖子 主题：SQL 与函数式编程
精华帖 (0) :: 良好帖 (8) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-04-22
最后修改：2009-04-22
night_stalker 写道 ruby 本身不提供让你直接看 proc 源代码的功能， ParseTree 的核心是一个用 C 写的扩展，可以在虚拟机中挖出语法树来。
嗯，MRI在解析了Ruby源码之后变成抽象语法树，而下面的解释器就是在这棵树上解释的，所以只要程序还活着就有办法把抽象语法树挖出来。 night_stalker 写道 但是！FX 告诉我：MRI 1.9 只保存序列化的 YARV 字节码，不再保存 ParseTree 了，所以 ParseTree 没戏了……
诶……我们聊的时候我说过这个么 =v= 虽然YARV在执行过程中不再使用抽象语法树是事实没错。 night_stalker 写道 可以想到的一个简单 hack：
先从 Proc#source_location 定位出 proc 的位置。（此方法返回 [文件名，行号]，如： ["topic.rb",31]） 然后读取源文件，从这个地方开始截取这个完整的 proc 字符串作解析…… 此 hack 的缺点是 irb 、打包的 jruby 都不认。而且很土。 （嗯…… 性能不是问题，可以用 "文件名：行号" 索引缓存的 match spec） 完整的Proc字符串不好截。只有行号根本不够用。随便写个： p, q = proc {}, proc {}
这俩的行号就一样了。用def也一样可能遇到在同一行定义的状况。由于Ruby语法允许这点，要做任何“有实用价值”的Ruby解析都不能无视它然后说“多数情况应该行的”。要是YARV能留个更干净的解析器的接口出来就好了…… 如果是把字符串解析成树，还有ruby_parser库，然后JRuby也有JRuby.parse可以用。不过生成的结果跟ParseTree不一样，而且把JRuby内部的优化方式都暴露出来了。 |
| 返回顶楼 | |
|
发表时间：2009-04-22
最后修改：2009-04-22
对同一行或者嵌套的情形，可以这样 XD：
raise "sorry 我认不出 topic.rb:31 哪个 proc 是 match spec，分一下行好吗~~" 另一种思路： ISec#disasm 看 YARV 字节码…… RubyVM::InstructionSequence.disasm obj.method(:mspec) 不过现在只支持 method，不支持 proc 。可能 1.9.2 会支持 proc 吧 o(╯□╰)o |
| 返回顶楼 | |
|
发表时间：2009-04-22
打断一下，根本是两种东西，select(func(row) {row.name like 'J%'}) 只是形式上和 sql 相似，可以理解为集合操作披上了 sql 的外衣。
sql 的基础是关系数学，也就是关系元组交投选并差等等运算，不拘实现，只关心结果，不关心过程，不关心存储位置，不关心是不是并行。 和sql相似的是 prolog，sql 被认为是 datalog 的一种。 |
| 返回顶楼 | |
|
发表时间：2009-04-22
inshua 写道 打断一下，根本是两种东西，select(func(row) {row.name like 'J%'}) 只是形式上和 sql 相似，可以理解为集合操作披上了 sql 的外衣。 sql 的基础是关系数学，也就是关系元组交投选并差等等运算，不拘实现，只关心结果，不关心过程，不关心存储位置，不关心是不是并行。 和sql相似的是 prolog，sql 被认为是 datalog 的一种。 说的就是sql和fp中的行集数据的运算比较。 |
| 返回顶楼 | |
|
发表时间：2009-04-24
kimmking 写道 inshua 写道 打断一下，根本是两种东西，select(func(row) {row.name like 'J%'}) 只是形式上和 sql 相似，可以理解为集合操作披上了 sql 的外衣。
sql 的基础是关系数学，也就是关系元组交投选并差等等运算，不拘实现，只关心结果，不关心过程，不关心存储位置，不关心是不是并行。 和sql相似的是 prolog，sql 被认为是 datalog 的一种。 说的就是sql和fp中的行集数据的运算比较。 实际上，如果了解一些Category的理论,你会发现,如果把关系代数和Lambada算子看成两个Category的话,你会发现很容易通过一个Functor将他们之间影射起来. |
| 返回顶楼 | |
|
发表时间：2009-04-24
SQL不是函数式编程吧？
函数式编程是通用编程，能干任何事。sql是dsl。dsl比较专，比较简洁。 |
| 返回顶楼 | |
|
发表时间：2009-04-24
Trustno1 写道 kimmking 写道 inshua 写道 打断一下，根本是两种东西，select(func(row) {row.name like 'J%'}) 只是形式上和 sql 相似，可以理解为集合操作披上了 sql 的外衣。
sql 的基础是关系数学，也就是关系元组交投选并差等等运算，不拘实现，只关心结果，不关心过程，不关心存储位置，不关心是不是并行。 和sql相似的是 prolog，sql 被认为是 datalog 的一种。 说的就是sql和fp中的行集数据的运算比较。 实际上，如果了解一些Category的理论,你会发现,如果把关系代数和Lambada算子看成两个Category的话,你会发现很容易通过一个Functor将他们之间影射起来. 嗯，确实可以影射，但是世界观有别。从这个角度看世界有一套结构，从那个角度又有另外一套结构，结构之间可以影射。世界的本质是相通的，然而世界观是多元的。说其不同，并不是说它们不能沟通，而是说它们理论出发点不同。 |
| 返回顶楼 | |
|
发表时间：2009-05-06
o(∩_∩)o... 那最后大家都写汇编不是更好!
每个数据库的sql--->解析不同 SQL基本是相同的 |
| 返回顶楼 | |
|
发表时间：2009-05-06
SQL是语用抽象的实现
而s-ep 数据库解析等就是语法级别的 |
| 返回顶楼 | |
|
发表时间：2009-05-06
看完这个贴子,有几个疑问!
1.各位比较强,不知道天天在做什么?研究理论,实践项目 2.理论有没有转化 3.中国需要不需要,能不能这样的理论--->基础工程产品[os,db]的转换 |
| 返回顶楼 | |
