類型化的球拍優化

Question

我學習一些類型化的球拍的那一刻，我有幾分哲學的兩難境地：

球拍宣稱自己是語言發展的框架和類型化的球拍是在它的基礎上實現的一個這樣的語言。該文檔提到，由於正在使用類型，編譯器現在可以做更多/更好的優化。

的具體問題：

在哪裏這些優化發生？

1）在編譯/擴大部分（其是「可編程」作爲語言建築物框架的一部分）

- 或 -

2）進一步向下的（字節碼）優化器的線（這是用C編寫的，不能通過框架直接修改）。

如果2）爲真，那麼這是否意味着類型信息在編譯/展開階段後丟失，並在稍後由優化器「重新生成/猜測」，或者中間表示已被更改爲適應類型信息並稍後通知關於他們的階段？

我問這個具體問題的原因是因爲我想知道Racket語言框架的真實性如何，也就是說，對於靜態類型語言也是可行的，而不需要在後端進行任何修改，而只對類型系統進行修改一個前端的東西，而在運行時的代碼仍然是動態類型的（但當然靜態檢查）。

謝謝。

Answer 1

類型球拍的優化發生在宏展開期間。要親自看看，可以將#lang typed/racket更改爲#lang typed/racket #:no-optimize，這表明類型化球拍完全控制了應用哪些優化。

優化包括使用類型信息來替換their unsafe equivalents的某些過程的各種用途。如果使用不正確，不安全的過程不會對其參數的類型進行運行時檢查並導致未定義的行爲（閱讀：segfaults）。您可以在標題爲Optimization in Typed Racket的文檔部分找到更多信息。

程序的不安全變體的暴露是真正使用戶定義的語言實現這些優化的可能性。例如，如果您使用類型系統編寫自己的語言，可以證明載體從未被超出邊界索引訪問，您可以用vector-ref替換unsafe-vector-ref的使用。

在字節碼級別有類似的優化，但這些優化主要適用於JIT可以推斷在宏擴展時不可見的類型信息。這些不是用戶控制的，但你不必依靠它們。