接上一篇文章。自從昨天設(shè)計(jì)了NativeX語言的泛型之后，今天又對昨天的草稿做了一下修改。設(shè)計(jì)語言的語法總是這樣，首先對你自己的需求提出直接的解決方法，然后看看是不是有些新的概念跟其他概念可以合并起來變成更抽象的概念，而且又不會在實(shí)現(xiàn)上導(dǎo)致困難，也不會讓編譯器變的突然難寫許多。經(jīng)過了昨天晚上和今天早上的思考，我決定簡化一下泛型的語法以及concept的內(nèi)容。

    首先說語法上的。上一篇文章在定義泛型頭的時(shí)候采用了generic<type T1, type T2, concept C1, concept C2>這樣子的語法。本著盡量減少關(guān)鍵字的原則，我決定去掉type，變成generic<T1, T2, concept C1, concept C2>。原因是concept關(guān)鍵字還能用來定義一個契約，而type則毫無用處。而且一個契約有了concept關(guān)鍵字作開頭，也不會跟沒有type關(guān)鍵字的類型參數(shù)混淆。

    其次是concept。昨天定義了concept instance和concept series。其實(shí)總結(jié)到最后，concept instance無非就是concept series的一個特例。根據(jù)昨天的說法，把所有的instance都替換成series其實(shí)結(jié)果還是一樣的。唯一的區(qū)別就是concept series不允許在既不是concept定義所在的Assembly也不是特化所涉及類型的Assembly里面出現(xiàn)它的一個特化。如果單純?nèi)サ袅薱oncept instance的話顯然會帶來問題：我在AssemblyA處聲明了一個concept Sortable<T>之后，沒辦法在AssemblyB處聲明一個concept series IntSortable : Sortable<int>。因此某一些限制需要放寬一點(diǎn)：
    1、concept series的原始版本可以在一個既不包含concept聲明和也不包含涉及的類型聲明的地方聲明。
    2、concept series的特化版本則必須出現(xiàn)在包含concept聲明或者包含涉及類型聲明的地方聲明。

    那么其實(shí)series關(guān)鍵字也不需要了，因此會獲得下面的寫法：

    operation和function的區(qū)分實(shí)際上沒什么大的價(jià)值，如果你真的需要一個函數(shù)指針的話，那就在參數(shù)傳進(jìn)去好了。而且constant也沒什么必要，因?yàn)閏onstant實(shí)際上是operation的一個特例，只是使用的時(shí)候需要多寫一個口號罷了。我們會看到上面定義concept其中的操作的兩個方法：指定函數(shù)和指定表達(dá)式。如果制定了表達(dá)是的話，那么該表達(dá)式將會被內(nèi)聯(lián)（啊）。所以constant存在的價(jià)值也就不存在了。因此我們甚至連function、operation和constant的區(qū)分也消失了，所以在語法上更加得到了簡化。

    NativeX每一次引入一個新的特性的時(shí)候都是迫不得已而為之，而且一旦引入之后我總是力圖將該特性設(shè)計(jì)成跟其他所有的特性正交。例如這里的泛型，所有的東西都可以加上泛型，譬如結(jié)構(gòu)體、全局變量、函數(shù)、契約和契約實(shí)例。所有的東西都可以是非泛型的，也可以是泛型的。有時(shí)候我們的確需要定義一個非泛型的concept，這其實(shí)也不是什么大問題。

    不過當(dāng)前的語法還會遇到C++那經(jīng)典的>>問題（一直到了C++0x才正式納入標(biāo)準(zhǔn)- -b）。這個問題有三種解決辦法，第一種是不允許寫成vector<vector<int> >，第二種是允許寫a>>b也允許寫a> >b（中間有個空格），第三種是跟VC++一樣一概支持。最后一個比較困難，第二個比較奇怪，第一個比較惡習(xí)。不過結(jié)合了各種因素之后，其實(shí)我覺得支持第二個倒是最簡單的辦法：你仍然可以寫出漂亮的代碼，而且你如果自己受得了a> >b而自己惡心自己的話，那也是你自己的事……

    至于其它問題，NativeX沒有逗號表達(dá)式，聲明NativeX的變量需要加上variable關(guān)鍵字，聲明NativeX的函數(shù)需要加上function關(guān)鍵字，所以全部迎刃而解。