如果讓你來重新設計（或者改造）Haskell，你打算怎麼設計或者修改？

01-27

鏡像問題：如果讓你來重新設計（或者改造）C++，你打算怎麼設計或者修改？ - 編程語言

1. 完整的dependent type支持！！目前的GHC Haskell核心calculus是System FC，而System F家族的calculus並沒有term -&> type的能力（inductive families），也沒有dependent pair/function類型（sigma/pi type）。雖然可以有限度地模擬dependent type，但是需要使用大量編譯器擴展，在type level的一個極其有限的語言子集里進行操作，寫過的人都知道需要寫大量的boilerplate code（雖然singletons框架可以稍微減輕痛苦）。所以，重新設計Haskell，拋開表面語法等細節，核心calculus必定先換掉。至於運行時效率的問題可以再商榷，可以結合編譯器優化（就像Idris那樣）和手動標註的方式控制運行時typerep開銷。

2. refinement type支持，集成SMT solver。沒有靠譜solver時，使用GHC.TypeLits非常痛苦（比如GHC連整數加法的結合律都不知道）

3. 加入row polymorphism和polymorphic variant。

4. type class的coherency問題已經被ML社區的人揶揄過無數遍了！可以說type class同時是Haskell的力量之源與阿喀琉斯之踵。可以考慮顯式暴露type class dictionary，實現named instance，甚至和dependent type的elaborator放到一起實現。。OCaml那邊目前有一項類似的工作，叫modular implicit，大意也是在不傷害modularity的前提下實現輕量級的ad hoc多態。

5. 元編程方面：Template Haskell也是個毀譽參半的玩意兒。等到有了full dependent type以後，元編程的需求更加迫切了，有沒有什麼更優雅的機制可以做這件事情，我讀的文獻太少不清楚，但願會有吧。

6. 能體現在類型層面的rewrite rules！現在的Haskell一個非常顯著的問題在於：很多關鍵庫的性能依賴一些GHC rewrite rules的正確激活，而rewrite rules往往對庫的調用者是個黑箱子，說不清楚什麼時候會意外啞火，除非將GHC core simpifier輸出dump出來人眼看。。

7. 能夠用Haskell自己寫自己的並發運行時調度器。這個OCaml走在了咱們前面（話說明明是某人投稿被拒以後轉去給OCaml寫的實現來著，逃

8. 默認惰性求值這個應該留。現在已經有Strict擴展了，未來實現UnliftedDataType以後，配合現在的runtime representation polymorphism，在一門non-strict的語言里隨時使用strict的子集將是稀鬆平常的事。

先想到的也就這麼多。。

謝邀，就我個人來說最需要的是Haskell在並行編程方面的支持，能夠在語言的層面通過類型系統和編譯指示來實現友好的並行編程。

現在Haskell支持的並行編程有兩種，都是靠庫來實現的。一個是repa，這個庫不支持嵌套的array結構，也不支持simd指令。另一個是accelerate，是一個EDSL，將並行運算放在GPU端來實現並行，目前只對Nvidia的cuda有成熟的支持，OpenCL的支持有限。

另外Haskell的Data Parallel現在還只是實驗性質，而且還不完善。GHC對simd的支持前兩年比較活躍，現在也沒動靜了。

現在隨著多核芯的CPU的普及，和AR及VR之類產品的興起，移動端需要運行的演算法越來越複雜，需要充分利用多核CPU的並行計算資源才有可能運行這些演算法。然而現在的並行運算的編程是很麻煩的，而且難以調試。如果Haskell在這方面有很好的支持，將是一個很好的突破。

其它的如加強type level的表示能力，加強Haskell程序的推理能力這些已經包含在 @邵成的答案中了。

使用 S 表達式（逃

如果從方便的角度來講，我要給類型的泛型參數加上C++的那種尖括弧（或者有些人喜歡方括弧），這樣就可以完美的配合variadic template argument的做法，免去大部分template haskell的需要了（逃

不僅僅haskell，包括其他函數式語言：幹掉GC，顯式化共享（更好的支持 @parker liu 需要的並行能力）

這個問題不好答……有套路……

haskell社區和外面那些妖艷語言不一樣，沒有委員會內部的相互扯皮，也沒有商業利益的羈絆

簡單說，它是一個那種「能動手就盡量別bb」的社區。其他地方為了是否加個lambda能撕幾年，這種事絕不會發生在haskell，haskell的文化一直就是先把坑挖了再說，不行以後可以再弄掉嘛

所以，你若是不爽什麼東西，別bb，直接去改，去挖坑，誘騙新人往坑裡跳

所以，如果我洋洋洒洒寫了一大堆東西之後，有人在評論那裡問：你說的好有道理，但你為什麼不動手去改呀？

尼瑪這就尷尬了好嗎…… ( ????? )

其實haskell設計得很好，我是發自內心說這句話的 (*??`*)

PS：與其問想怎麼改haskell，不如問，在ghc那漫山遍野的坑裡面，你最想跳的，是哪個？