Create initial Haskell basics/basics page

[TrueBoxGuy]

This resolves #3.

I have written a page that does the following:

• Provide instructions for installing Haskell
• Introduce ghci and import the Text type
• Cover basic data types
• Cover basic operators

[TrueBoxGuy]

I've implemented these changes, but may see if there's some way to fix the highlighting. It gets problematic when printing: I've seen some libraries with repl highlighting, so it may be possible to find out a way to do this. However, these changes, along with that of adding the ghc version to _config.yml, should probably be part of another pull request.

[TrueBoxGuy]

Sorry if this has been discussed elsewhere, but wouldn't it make sense to simply hide Prelude.putStrLn and import T.putStrLn unqualified? Can be easily added in the initial blurb of imports.

@ulysses4ever

Seems like it may be a viable idea, but I'll ask others. There was one discussion during the office hours about prelude/alternative preludes, and we came to the decision was to replicate real-life Haskell code: I don't have much experience of Haskell codebases, but how are Text imports for IO usually handled?

[Kleidukos]

In all the codebases I've worked on, the decision was made to always use the qualified version, and I think it is honest to show this to the learner

[ulysses4ever]

I'm fine with whatever you think is better, but I want to make a meta-comment here. Using your industrial experience (e.g. with qualified imports of Text) when you write a beginner's tutorial may not always be the best approach to the task.

[TrueBoxGuy]

I don't think the import being qualified makes it particularly more complicated (it's just a T. at the beginning): I agree with you that we shouldn't try to fully replicate industrial Haskell, but believe that the flip side of the spectrum is that the code shouldn't be too cute either. Having hidden name conflicts by importing Prelude without putStrLn seems somewhat contrived to me, and the few benefits of this are quickly lost when you use more functions from Data.Text. Ultimately, I think that showing the user that you can solve name conflicts by removing functions from Prelude isn't a good practice: even when writing their own non-industrial code, they'll quickly reach a point wherein using this tactic as a default offers little benefit.

Similarly, a more important point of contention is that of using Text, which does introduce quite a lot of clutter to the tutorial and potentially puts off the reader. I believe that importing Text in this tutorial enables for the tutorial to be a baseline for the reader for the standard look of a tutorial (with the setup, such as imports and language extensions, for the tutorial being at the beginning), and somewhat removes the hurdle of parsing the structure of other tutorials.

However, I recognise this as an unusual decision, and would be happy if a completely separate reviewer voices their opinion.

[Kleidukos]

I'm fine with whatever you think is better, but I want to make a meta-comment here. Using your industrial experience (e.g. with qualified imports of Text) when you write a beginner's tutorial may not always be the best approach to the task.

@ulysses4ever Having a qualified import of Text functions is far from being an "industrial" practice. Open-source projects, research projects that need proper Text functions and an appropriate data-structure will do this without hesitation. The problem here is that the Haskell standard has badly evolved, and at the present time we do what we can to compensate. Yes it sucks.