2 ms·

Code and types can very much diverge if the types aren't checked by the compiler, as my parent poster indicated. Case in point: type aliases instead of (Haskel

Code and types can very much diverge if the types aren't checked by the compiler, as my parent poster indicated. Case in point: type aliases instead of (Haskell) newtypes. Type aliases (which are unchecked, unlike newtypes) can lead to exactly the kind of diverging that I alluded to. Look at the mess that is all the typedefs and defines in the Win32 API for example. It's extremely hard not to pass in the wrong typedefs, and there must be extremely few programmers who know which aliases are the same on every platform and which could change. Aside, newtypes (Or the equivalent in C for example, wrapping a single member in a struct) can be very annoying. I would advicse against this, just like I'd advise against using type aliases.

pyrale 6y ago
Curious to know what led you to interpret this: > which happens to be checked against the compiler as: > the types aren't checked by the compiler, as my parent poster indicated. (also type aliases are still checked. The check is less useful, but it's still a check) > Why would any experienced programmer make such a blanket statement? Because type annotations are less work than tests or documentation, don't suffer from falling out of sync like doc does, and because experience shows that haskell users typically find it useful to write types despite it not being necessary to compile. It would be surprising to skip types but invest in writing more complicated means of documenting and testing the software.
- jstimpfle 6y ago
  maybe I misread. I went with > 95% of annotations in the average haskell codebase are unneeded for compilation Like type aliases. They are not distinct types, so the compiler doesn't (can't) check that you're using the "right" name.
  - pyrale 6y ago
    What I mean is that these annotations are going to prevent compilation if you get them wrong, but the compiler's type inference is good enough that you only need to provide types when there is ambiguity. That means most of the type annotations written exist because developers find them useful for documentation.

pyrale 6y ago

Curious to know what led you to interpret this: > which happens to be checked against the compiler as: > the types aren't checked by the compiler, as my parent poster indicated. (also type aliases are still checked. The check is less useful, but it's still a check) > Why would any experienced programmer make such a blanket statement? Because type annotations are less work than tests or documentation, don't suffer from falling out of sync like doc does, and because experience shows that haskell users typically find it useful to write types despite it not being necessary to compile. It would be surprising to skip types but invest in writing more complicated means of documenting and testing the software.

jstimpfle 6y ago
maybe I misread. I went with > 95% of annotations in the average haskell codebase are unneeded for compilation Like type aliases. They are not distinct types, so the compiler doesn't (can't) check that you're using the "right" name.
- pyrale 6y ago
  What I mean is that these annotations are going to prevent compilation if you get them wrong, but the compiler's type inference is good enough that you only need to provide types when there is ambiguity. That means most of the type annotations written exist because developers find them useful for documentation.