DSL的讨论

没错。这些都是了解不足造成的错误理解。

....

幸亏俺还是清醒的，没犯这样的错误。:D

俺说的，DSL不够用了，就需要增强DSL语法。
不增强语法，用宿主语言补充也行，只是无法发挥原有的DSL的能力。
一个例子是SQL，可以使用宿主语言PL/SQL等，增加SQL Functions/Procedures，同时，也不得不对SQL语法本身进行扩展，支持optimization hint，支持tree query, 支持对象结构，支持nested table，等。

(
注，
host language = 宿主语言
native language = 原生语言
这里应该是同一个意思。
)

DSL不够用了，用宿主语言补充也行。
恰好想起来几个例子。
antlr, javaCC, aspectJ都是 自定义语法(EBNF, Aspect等) + Java语法的混合，然后产生Java代码。

那么你这句话是什么意思呢？

“DSL的创造”本来就是随时进行的。

为什么DSL一定要有BNF/AST？
改变一个Ruby类库需要重新编译吗？

这样讨论下去没完

你们讲的不是一回事吧

明确一下：

内部DSL就是利用host语言本身的能力，通过host语言变形产生的，不需要写编译器或解释器
外部DSL就是独立的一种语言，需要写解释器或编译器

注意这和是否嵌入无关，外部DSL照样可以嵌入到实现它的host语言中，例如一个Ruby程序提供其他一种特定领域的语言供用户二次编程

这正是妖魔化之重点。
DSL的创造，不应该随时进行。而应该慎之又慎。
对一个领域的了解应该深入。
如果一个领域确实需要DSL，那么 90% 可能性已经有了成熟的DSL，可以直接使用。比如，SQL，Math等。
正如gigix的名言，太阳下没有新雪，所谓自己的独立想法，90%可能性，已经被别人想到了。
那么怎么做。当然是学习，研究。为什么要重复发明轮子。:lol:
如果确实没有找到对应的DSL，那么90%的可能性是，这个领域确实不需要一个DSL。
如果确实发现了一个偏门领域，没有DSL，而且确实需要DSL，那么恭喜，你发现了一个很有潜力的商机。这个DSL更不应该随时随意创造了。而应该找该领域的专家共同探讨，创业，找VC，上市，炒作，发大财...

 

提到了其他手段。
Ruby DSL 的手段比较多样，字符串拼接 + eval, reflection, Code Generation, etc。
DSL是一门语言，肯定要有语法，就要有语法定义和语法元素。
语法定义最常用的形式是BNF，语法元素之间的关系通常也是树形结构(AST)。

DSL语法改变，语法定义和语法元素就要改变。DSL Interpreter Engine 同样需要修改。中间还是隔了一步。
一个应用功能的改变超出DSL语法范围，需要修改DSL Interpreter Engine，然后用新语法特性编写DSL程序，来解决新增加的需求。

Ruby的DSL有几种，其中包括
1。某些库已经写成DSL的样子，更加符合某种对象自身的结构和行为，不需要复杂的对象交互，例如html(div(table(.....)))这种样子
2。框架提供程序员使用，作为API的一种形式，让编程更加声明性，Rails是一个很好的例子，其中的migration,routing,activerecord等等都是
3。工具直接供客户使用：Rake供程序员、配置管理人员使用，DVR tester供测试人员使用等等

目前，用 Ruby写DSL的绝大多数指的是内部DSL，而Ruby的openclass、mixin、eval、lambda机制，以及Ruby非常灵活宽松的语法提供了这样的温床。

gigix说的大致是指这个意思

如果要实现外部DSL，那么编译器生成器显然比Ruby好地多。ML作为语言也比Ruby好的多。

Lisp的情况比较特殊，因为S-expression如此简单，所以介于内外部之间。但是编写Macro的实际情况还是和transform AST差不多，因此我自己偏向于把他归为外部DSL。但要看实际而定，例如Common Lisp的循环机制实际上都是用宏实现的，你不能说它是外部的。因为它已经是语言的一部分。

Thanks potian for the Good Summary.

这些部分都已经形成了一定的convention和共识，成为了DSL。

我对这些了解不多。
我了解的DSL主要是Query。Query DSL非常盛行。
SQL, OQL, HQL, EQL, LinkQ, JQuery (query java class info), and many others ....
Lucene也定义了一套 Query，用来表示复杂的搜索条件组合。
Google的Advanced Search也是。

很多人喜欢在查询输入框里面定义简单的 or, and, from to, between, like, greater, less, 等。
更进一步，有些人干脆定义一个 Simple DSL，定义BNF编译一个Interpreter出来。
这一步骤是得不偿失的。
这不应该属于语法范围，而应该属于协议范围。
Grammer vs Protocal的区别主要在于，Grammer有语义，可以执行，有动作，是主动的。Portocal只是结构描述，是被动的。Grammer通常比Protocal强大复杂。
我倒是赞成有限的使用现有的Script语言，代替一部分Protocal。比如，安全问题解决的情况下，传递一段Javascript, or Ruby 到 Server执行，而不是SOAP。
但是，不赞成用一个新的DSL代替本应该是协议级别的任务。

-----

其实就是侃侃。借题发挥，抒发对一些现象的想法。

兄弟，遗传算法没那么大本事。它只是更为广义的演化算法中的一个分支。
比他更牛X一点的是人工生命，但是从90年代后期已经逐渐和MultiAgentSystem(MAS)有融合趋势。最初的人工生命的起点太低，很难演化出复杂的结构来(但是那些相对简单的结构，确实干净漂亮.细胞自动机是冯诺依曼的另一个异常重要的创新，估计每隔20年就会有一坨子人被它吸引)
现在也就是MAS的发展才有可能有你说的那么恐怖的后果。不过，也有可能过了n年发现此路不通。这是一场复杂度、计算方法和计算能力的竞争。

才一天没来，这里都快变天了！

不过讨论多也好，开始把大家各自隐含的上下文倒出来了!
还是先要把DSL的类型先分清楚，限定了问题范围，大家再具体讨论！

说起来，现在还算是“商机无限”，过个10年、20 年，可能就会像buaawhl说的情况了。

我对DSL的理解比较接近buaawhl。
在现在的工作中发现xmlschema也挺适合定义一门语言
的。
“一个应用功能的改变超出DSL语法范围，需要修改DSL Interpreter Engine，然后用新语法特性编写DSL程序，来解决新增加的需求。”
这是肯定的。
不过我想应该会有DSL的DSL,DSL Interpreter Engine 也是可以生成的。