《ruby元編程》有獎試讀中�。ǐ@獎名單已公布）

starwing83

回復(fù) 50# OwnWaterloo


    哥哥，編譯的時候就一個OP_ADD，運行的時候判斷類型。JIT的話，運行的時候進(jìn)行跟蹤，如果發(fā)現(xiàn)1.對象沒有改過2.執(zhí)行過多遍，就直接把執(zhí)行過程變成native跑了……

OwnWaterloo

回復(fù) 49# starwing83

相差不大的結(jié)論是怎么來的？
有僅解釋就與非JIT編譯的lua相當(dāng)?shù)膌isp，除非作者在吹牛。
http://picolisp.com/5000/!wiki?NeedForSpeed  這里有與sbcl的對比。

我說過這么多次了……  是否被優(yōu)化，是否會被阻止優(yōu)化， 是由你需要的靈活性決定的。
lisp的概念，至少我最欣賞的部分，是程序由語言內(nèi)建的數(shù)據(jù)結(jié)構(gòu)表示，于是可以像操作數(shù)據(jù)那樣產(chǎn)生新的程序 —— 而且通常是在編譯時。
http://www.paulgraham.com/diff.html  也就是這里說的8. A notation for code。
code與data是可以被設(shè)計為有界限的，但它們的表示方式相同。

其余部分也很有用，而且我沒看出有哪部分是阻止lisp被優(yōu)化的，除了：9. The whole language always available。
lisp缺少（或者說還沒發(fā)現(xiàn)）一種實現(xiàn)是有意圖地將9的功能劃分出明顯界限， 并且僅當(dāng)需要時才產(chǎn)生所需代價。

OwnWaterloo

回復(fù) 51# starwing83

你說的這種處理方式與 (+ a b) 的區(qū)別到底在哪里……

starwing83

回復(fù) 53# OwnWaterloo


    (+ a b)并不知道+到底是什么。比如這里：

(let ((+ (if (rand) (lambda (a b) (+ a b))
                     (lambda (a b) (- a b)))))
   (+ 2 1))

答案究竟是3還是1呢？是運行時決定的，不是3就是1,取決于（rand）的值。因此下面的(+ 1 2)就不可能翻譯成OP_ADD 1 2，也不可能做constant fold，最多只能搞成：OP_CALL 1 1 2（第一個1指第一個local變量），最終的結(jié)果是一次調(diào)用（而且是不可避免的）。因為這些原因。要么lisp編譯器要做所有的解析，確�？梢跃幾g成字節(jié)碼的函數(shù)或者special-form完全沒被修改，要么就只能保守地把所有的(op args...)翻譯成OP_CALL op args...，那樣基本上沒法做優(yōu)化了（你看，上面的constant fold就沒法做了，注意lua是有constant fold的）。

除非這時不允許改變+的值，或者在某個block改變了+的時候做個標(biāo)記，說明這里必須得用OP_CALL，而不是OP_ADD。而每個內(nèi)建函數(shù)做這樣的標(biāo)記是很累人的，意味著每次賦值都必須查找。而且如果有scheme式的全局變量話，這種標(biāo)記都有可能沒法做到，如下：

(define (foo a b) (+ a b))
(if (rand) (set! + (lambda (a b) (add a b))
           (set! + (lambda (a b) (sub a b)))
注意我這里故意把set!寫里面，這意味著任意一個位置的自由變量（scheme默認(rèn)是全局變量）改變都可能導(dǎo)致整個程序的狀態(tài)改變。如果是這種情況就很不好判斷了。

惟一的辦法就是不允許修改這些值，那其實和lua（以及l(fā)ua ast）沒啥差別了。lua照樣可以生成lua代碼，而且根本不難。lisp除了語法和編譯器支持以外，看不出什么優(yōu)勢。操作程序表只是在提取信息而不是構(gòu)造程序方面有優(yōu)勢。然而只要有了ast，連這種優(yōu)勢也沒了。

starwing83

回復(fù) 52# OwnWaterloo


    說到靈活性，你能假設(shè)沒有人會有需求去改變+么？也許有也許沒有，照你的理論這個就得支持，不然就是“限制程序員”，我的意思是，這里面的確需要有個度。如果說只要“有可能”會用到的都要支持，那語言就很難在語義和實現(xiàn)上取得平衡了。

zhlong8

starwing83 發(fā)表于 2012-03-01 09:59
回復(fù) 53# OwnWaterloo

common lisp 是限制修改內(nèi)置函數(shù)，racket 是通過 syntax 抽象來判斷是否是原始的 +，比如你用 let 那個完全沒問題，不過用了 set! 那就沒辦法了，很多優(yōu)化都不能用了

OwnWaterloo

回復(fù) 54# starwing83

前面那一堆，除了const fold，還是沒說出與lua的差別。

>> (define (foo a b) (+ a b))
lua里面 function(a,b) return a+b end
也只是固定了一個OP_ADD而已，也就只是知道它對兩個number會數(shù)字+， 對有元表的看元表定義。 具體會做什么依然不清楚。
(defun foo (a b) (funcall #'+ a b))
(define foo (let ((+ +)) (lambda (a b) (+ a b))))
取出+的定義，對兩個number(fixnum/bignum/real...)會數(shù)字+， 對其他無定義。 +的function cell不再影響foo函數(shù)。


>> 惟一的辦法就是不允許修改這些值，那其實和lua（以及l(fā)ua ast）沒啥差別了。
這段，連著后面那樓
>>     說到靈活性，你能假設(shè)沒有人會有需求去改變+么？也許有也許沒有，照你的理論這個就得支持，不然就是“限制程序員”，我的意思是，這里面的確需要有個度。如果說只要“有可能”會用到的都要支持，那語言就很難在語義和實現(xiàn)上取得平衡了。

一起回復(fù)了。
有差別，而且你怎么想不到呢……  支持了又不是說所有地方就必須都有這種靈活性……
你這等于是在說： C/C++支持指針運算，支持類型轉(zhuǎn)換，沒有限制程序員， 所以是不安全的。 但其實良好的C/C++程序里這些不安定因素只在很小范圍內(nèi)。
那個cl反匯編的例子， 沒說add以外的函數(shù)中的+的行為全都被固定了啊， 也沒說不允許const fold啊， 只是那個例子沒有掩飾而已。

你怎么和327一樣呢……  要么C，要么C++了就必須全private……  不是的，private也是在你需要時才用的。


>> 惟一的辦法就是不允許修改這些值，那其實和lua（以及l(fā)ua ast）沒啥差別了。
lua有辦法讓foo函數(shù)告知編譯器： 我這函數(shù)就用內(nèi)建+了， a,b就只支持整數(shù)了， 給我優(yōu)化到addl？

>> lua照樣可以生成lua代碼，而且根本不難。lisp除了語法和編譯器支持以外，看不出什么優(yōu)勢。操作程序表只是在提取信息而不是構(gòu)造程序方面有優(yōu)勢。然而只要有了ast，連這種優(yōu)勢也沒了。

什么叫這種優(yōu)勢也沒了？這也不是第一次與你說這個了： 能獲得ast的語言早就有了， 為什么在元編程(code transformation)方面依然沒超過lisp？
lua的宏，等它出來之后再說好嗎？這只是說lua有這個能力， 并不能肯定lua能夠很容易的使用這個能力。
上面的，什么使得lisp不同，貌似是第8點，特有的代碼記法。 代碼中寫的樣子就是讀的樣子，已經(jīng)被人肉parse過了。
不僅僅是能夠獲得， 而且是在代碼文本中能夠清晰看見。  這就是被人詬病的lisp難看的語法的優(yōu)勢。

starwing83

回復(fù) 56# zhlong8


    是啊，我也說了這樣可以啊，可是處理起來復(fù)雜哈，而且還有情況是沒法優(yōu)化的。所以lisp實現(xiàn)才要么慢要么大，根本找不到一個平衡的嘛～我就是這個意思。

starwing83

回復(fù) 57# OwnWaterloo


    你怎么就完全不了解我的意思呢？？？？

我一直在圍繞語言設(shè)計和實現(xiàn)這個角度在說話，根本就沒說程序員用不用。一點一點說：

1. 我說惟一的辦法是不允許修改，我不是怕程序員改壞了，我是說不這樣就會導(dǎo)致優(yōu)化復(fù)雜，是實現(xiàn)問題�。�！你曲高和寡，得不到一個好的實現(xiàn)！這種沒有優(yōu)秀實現(xiàn)的語言又怎么可能流行起來呢？js做html5流行起來不也是v8帶起來的么？包括node.js都是在v8基礎(chǔ)上做的，沒v8哪來的node.js？？？

2. 我不是說要禁止程序員做什么做什么，我是說如果給予完全的靈活性，比如規(guī)定語言里面所有的東西都是可以改的，那么實現(xiàn)會遇到大量的困難！除非你打算做一個玩具。否則你必須得限定一個東西是不變的。我一直是在從語言實現(xiàn)上談?wù)撨@個設(shè)計問題，你扯程序員用不用干嘛？我承認(rèn)規(guī)則范化有好處，問題是如果泛過頭了，泛到了實現(xiàn)都困難的時候，你隨便編譯一個hello world都是一個5M的exe你怎么搞？？

好，繼續(xù)說+的問題。

這里的問題是：我知道+的語義是固定的，我可以用一個特定的方式處理它，這個方式可以是很復(fù)雜的（根據(jù)類型來的），但是至少是特定的，好，假設(shè)是123號功能吧。123號功能可能是個很大很大的函數(shù)，這不要緊，但是在我看到+的時候，我就知道我要調(diào)用123號功能，這時我可以寫死：OP_123，這樣就直接查表了（查表和執(zhí)行包括判斷類型都是運行時的事情）。

然而，如果+是能改的，那么我就根本不知道這個時刻的+是不是真的對應(yīng)123號功能了，它可能已經(jīng)被修改成456號功能了，也可能被修改成一個自定義字節(jié)碼函數(shù)了，那么我怎么去寫死呢？我沒法寫死，我只能說：查看+的值，然后根據(jù)選項去調(diào)用這個值，假設(shè)這個“查看且跳轉(zhuǎn)”的功能是3號，那么我就只能寫：OP_3 a 了，而a是OP_123，我才能再去執(zhí)行123號功能。

注意lisp里面所有的東西都是可以改的，那么其實我的字節(jié)碼就只有一個了，就是3號，因為我根本不知道哪個東西是固定功能！我只能把固定功能寫成獨立的函數(shù)，然后讓3號功能去根據(jù)變量的值去調(diào)用這些固定的函數(shù)。據(jù)lua郵件列表的說法，這兩種不同的調(diào)用方法去調(diào)用同一個函數(shù)，其效率可以相差一個數(shù)量級！

這就是我的意思。lisp的所有東西都是可以改的會導(dǎo)致優(yōu)化困難，甚至難以優(yōu)化。我不是說為了安全去禁止程序員咋樣咋樣，我是說讓程序員這樣做本身的實現(xiàn)都是非常困難的！甚至實現(xiàn)出來這樣的功能，程序員又不用，卻要帶上幾M的運行時環(huán)境去支持這種可能一輩子都用不著的功能，是非常浪費的，這就是我的意思。

如果是這樣，干脆限制一些東西以方便實現(xiàn)，C就是這么干的。

OwnWaterloo

回復(fù) 58# starwing83

我了個去……  你是不是老是糾纏lisp實現(xiàn)……    去試試gambit……
以前我只關(guān)注cl，因為想寫些非toy的東西，但連模塊機(jī)制都沒有的標(biāo)準(zhǔn)scheme根本不可能……

其實scheme與lua比實現(xiàn)大小就不公平， scheme支持任意精度（就這東西做好了就比lua大了）， 支持continuation， 比lua大很正常。
cl就更不公平了……
其他lisp很多都被OO教壞了， 看的興趣都沒有……


先看gambit老版本，3的，也許才符合你的胃口……  也別吐槽生成的C代碼了……  它們都將C作為可移植的匯編用……
guile(scheme)是有虛擬機(jī)的， 不過貌似移植性不好， 不知道Windows原生支持出來了沒……  但LuaJIT的移植性又很好么？ 將C當(dāng)可移植匯編才是王道……
還有以前提到的chicken？還是chibi？是它么？是哪被你吐槽了？