Clarify how to use types for more than validation

[gelisam]

The "Statically typed" feature snippet ends with:

Types become not only a form of guarantee, but a language for expressing the construction of programs.

But the text before that only talks about rejecting bad programs at compile time, and the examples after that too.

I think it's a good idea to mention the fact that we use types for more than just catching errors, but we should at least give a hint of what we're talking about, or give a link to a more complete explanation. Here is my attempt at a very short explanation of what types are used for in Haskell.

In order to avoid using too much space, I've also removed the unicode example, which didn't add anything to what had already been said. If it was there to point out that yes, Haskell does support unicode, then the example should be moved to a more appropriate section than "Statically typed".

[chrisdone]

There's some stuff about using inference to consume JSON in the inference section, but I like the direction of this too and the mention of needing documentation less.

I think we should drop the isDigit example in favour of the ByteString/Text example because that's a classic problem with languages of accidentally double-encoding or forgetting to decode/encode a string: Haskell solves that problem outright (although I'm not married to it).

I'll come back to this after reviewing the other 5 PR's in case there's overlap.

[chrisdone]

Second thought: Perhaps we can put much of your content in the Inference section. Now that I re-visit it, it looks much more appropriate for this section which is "types are helpers too!" as opposed to "types stop bad things". And get rid of the JSON examples in there which, while a good demo, are probably a bit too complicated whereas your tuple + holes example is much cleaner.

[gelisam]

Perhaps we can put much of your content in the Inference section

How does my example illustrate type inference?

the JSON examples in there [...] are probably a bit too complicated

I agree, I also plan to submit a pull request for that section :)

[gelisam]

I think we should drop the isDigit example in favour of the ByteString/Text example because that's a classic problem with languages of accidentally double-encoding or forgetting to decode/encode a string: Haskell solves that problem outright (although I'm not married to it).

Okay, I'll rework my pull request around that example instead.

[chrisdone]

How does my example illustrate type inference?

This bit: mySnd (x, y) = _hole

Uses inference doesn't it?

[gelisam]

Hmm, that's true, that part would make more sense in the inference section.

The part about using types as a lightweight documentation still belongs to this section, right?

[chrisdone]

The part about using types as a lightweight documentation still belongs to this section, right?

Works for me. Whatever you're baking locally sounds good.

I think you're already keeping this in mind but just in case: try to keep all the sections roughly the same size, short and snappy. We'll later be able to add "Learn more" links that take you to a full page, but that content is not yet created.

[gelisam]

I'm indeed trying to keep things short, but the length did increase a bit. Stop me if I go too far!

[gelisam]

Here's a version with decodeUtf8 instead of isDigit. I'll send a separate pull request for the mySnd example.