You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the future Haskell would move away from CUSK to a more rigorous kind/types algorithm, moving away from CUSK would allow more easily do some complex things in the code. And all that means that the proper standalone kind signatures in the future would be more needed/expected to be in the code.
Kind signatures are simple to construct and provide, they are considered towards good coding style, it would help a type system, which in place would help a bit, developers. Kind signatures would be very useful to rely on and allow developers to be able to go into more type level programming features.
Bigger code signatures would be compensated by outshine/literate structuring and the ability to wrap the code.
To newcomers - providing kind signature allows to read through the chunks of the code what would introduce them to the project. And in the process - they would at the same provide useful work to make code style of the project better and more robust.
Anton-Latukha
changed the title
Adding KindSignatures to all exported funcitons, to all module scope functions
Adding Standalone Kind Signatures to all exported funcitons, to all module scope functions
May 23, 2020
Anton-Latukha
changed the title
Adding Standalone Kind Signatures to all exported funcitons, to all module scope functions
Adding Standalone Kind Signatures to funcitons
Mar 17, 2021
Anton-Latukha
changed the title
Adding Standalone Kind Signatures to funcitons
Adding Standalone Kind Signatures to functions
Nov 6, 2021
Not far ago the third semantic level of Haskell was provided with ability to give standalone kind signatures.
-> GHC manual
In the future Haskell would move away from CUSK to a more rigorous kind/types algorithm, moving away from CUSK would allow more easily do some complex things in the code. And all that means that the proper standalone kind signatures in the future would be more needed/expected to be in the code.
Kind signatures are simple to construct and provide, they are considered towards good coding style, it would help a type system, which in place would help a bit, developers. Kind signatures would be very useful to rely on and allow developers to be able to go into more type level programming features.
Bigger code signatures would be compensated by
outshine
/literate structuring and the ability to wrap the code.To newcomers - providing kind signature allows to read through the chunks of the code what would introduce them to the project. And in the process - they would at the same provide useful work to make code style of the project better and more robust.
+====
For more information:
-> GHC proposal
-> Good explanations and documentation in the implementation
The text was updated successfully, but these errors were encountered: