4 ms·

The fact that code and types don't diverge can make types useful as documentation, albeit limited documentation. Ideally the compiler figures out the types so y

The fact that code and types don't diverge can make types useful as documentation, albeit limited documentation. Ideally the compiler figures out the types so you don't have to. Haskellers often find this useful when they refactor a month later.

jstimpfle 6y ago
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.
higerordermap 6y ago
> Ideally the compiler figures out the types so you don't have to. Doesn't it cause unintended API breaks because type changed from, say, a single type to union type, without changing any annotations?
- pyrale 6y ago
  If that change goes through your whole program without causing any breakage, from Haskell's point of view it's a good change. If you have an API that exposes data to external systems, that may cause an integration breakage, indeed. That is why Haskell users like to use libs like Servant, which let you specify your API as a type. This way, if you change your system, your API has to change aswell. Another benefit of Servant is that you can generate swagger and clients for other languages easily, which your users can use in their own build to get type safety too.

jstimpfle 6y ago

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.

higerordermap 6y ago

> Ideally the compiler figures out the types so you don't have to. Doesn't it cause unintended API breaks because type changed from, say, a single type to union type, without changing any annotations?

pyrale 6y ago
If that change goes through your whole program without causing any breakage, from Haskell's point of view it's a good change. If you have an API that exposes data to external systems, that may cause an integration breakage, indeed. That is why Haskell users like to use libs like Servant, which let you specify your API as a type. This way, if you change your system, your API has to change aswell. Another benefit of Servant is that you can generate swagger and clients for other languages easily, which your users can use in their own build to get type safety too.