roc-lang/roc
1
1
Fork 0
mirror of https://github.com/roc-lang/roc.git synced 2024-11-13 09:49:11 +03:00
Code Issues Packages Projects Releases Wiki Activity

Revise FAQ section on Rank-2 types

Browse Source
This commit is contained in:
Richard Feldman 2022-12-08 05:59:47 -05:00
parent 5cfa6d8e12
commit 436dd9edad
No known key found for this signature in database
GPG Key ID: F1F21AA5B1D9E43B
1 changed files with 1 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
FAQ.md
View File

@ -204,9 +204,7 @@ No implementation of Rank-2 types can remove any of these downsides. Thus far, w
with sufficiently nice APIs that only require Rank-1 types, and we haven't seen a really compelling use case
where the gap between the Rank-2 and Rank-1 designs was big enough to justify switching to Rank-2.
Since I prefer Roc being simpler and having a faster compiler with nicer error messages, my hope is that Roc
will never get Rank-2 types. However, it may turn out that in the future we learn about currently-unknown
upsides that somehow outweigh these downsides, so I'm open to considering the possibility - while rooting against it.
As such, the plan is for Roc to stick with Rank-1 types indefinitely. In Roc's case, the benefits of Rank-1's faster compilation with nicer error messages and a simpler type system outweigh Rank-2's benefits of expanded API options.
### Higher-kinded polymorphism