As noted, um, everywhere, Haskell is a really deep language. As a beginner, the features that have struck me are the ease of defining functions, pattern matching in definitions, currying, and the seemingly endless stream of higher order functions.
Making function definitions as easy as variable assignments in other languages encourages me to break apart logic and leads to cleaner code. Defining functions in the `where` clause I've found to be especially handy and elegant. Unlike imperative programming, where code with very similar functionality can hide in a jungle of statements, repeating code in Haskell is easy to pick out and convenient to factor out.
Pattern matching in function definitions has been incredibly handy. In Perl, I'll often use a hash to map things like tetris shapes to their set of points. Haskell's version is more useful because I can define a function which takes a shape and returns a set of points associated with it. The difference is I can pass this function around or use it in higher order functions without using extra syntax to do the lookup.
Currying without any extra syntax is a big contributer to Haskell's clarity. Now that I've experienced it's usefulness, I don't think I could go back to languages like Scheme without constantly complaining about its absence.
Besides the standard `fold` and `map`, I find myself thinking "Wow, that will be usefull" whenever I look through Haskell's standard libraries. Functions like `zipWith` or `unionsWith` make even the most useful Java classes look barbaric.
When I first started writing Haskell, the thing I found most annoying was the big change in associativity. The downside of functions being treated exactly like data is that it becomes impossible for the compiler to correctly predict how you want things grouped. It didn't take long to become accustomed to Haskell's rules, but for whatever reason learning to use $ and . correctly took a bit time.
Monads obviously need to be included in this list, but I found understanding the simple monads such as IO, Maybe, and Either simple enough to quickly make progress. I have not implemented my own, and I suspect my Tetris code could be significantly improved with better understanding, so I'll be digging into this area again soon.
Typing has not been a problem for me. Haskell's typing inference system works great, and the times I've run into typing errors have been either an error in my code (most frequently), or, in my belief, a bad framework for what I was trying to accomplish.
I've basically run into the same problem with libraries and setup documented by Eric. Documentation of libraries could also use a lot of improvement. Here's an example of documentation for a function in some introspective code that I was trying to understand:
mkConstr :: DataType -> String -> [String] -> Fixity -> ConstrNot very helpful.
Constructs a constructor
What About Tetris?
First off, I don't think that Tetris and OpenGL map onto Haskell very easily. OpenGL in particular is very stateful, and even setting up a simple animation requires using Monads to work around Haskell's lack of side effects. I think this excersize is still useful, though, because in pushing a language to it's boundaries and forcing you to use it's less hyped features, you can often getter a better understanding of it's strengths and limitations. Before starting this project, I read over Michi's posts. In fact, his cube generation code is largely unchanged in mine.
What I'd like to see happen is for the amazingly helpful Haskell community (seriously, check out #haskell some time, it is the nicest, most helpful channel I've visited) to take my crappy code, explain why it sucks, and show me and other timid beginners how to do better. Just add a comment to where people should look for improved versions.
My code is available at PBWiki.
This is the code that kicks off the OpenGL loop. Callback functions are used to display objects, coordinate movements, and set state. You can see by the number of newIORef calls how much state is being passed around to each callback. The most confusing line here is probably the assignment to curMatrix. curMatrix keeps track of the matrix transformations that occur when the mouse is moved so you can use a "glass ball" type interface to rotate the tetris board around.
This file contains the display call backs that render the pieces and board. To implement the mouse interface, the display matrix is reset with loadIdentity. The new translations from the most recent mouse movement are applied, then the previous matrix is applied.
dropPiece drops the current piece, or sets the fallen piece and starts a new one.
idle is a callback that is continually called and it simply asks OpenGL to redisplay the screen in it's next loop. This is the alternative to calling postRedisplay after all movement changes.
This file contains the code that keeps the coordinates for shapes and instructions on how to render them. translatedPoints is a function which can take the default coordinates of a shape and apply the transformations that the displayed shape receives so that collision detection can be done.
Setup for the shape of the board and the boundary initialization are done here. tableMap is basically an array of all the (x,y) coordinates with False inside the boundaries (because there are no fallen pieces yet), and True along the boarders.
clearLines takes a board and clears any full lines; basically, the purpose of Tetris. Using foldl, it iterates over a list of lines given by their 'y' coordinate. For a given line, if that line is at or above 'y', it takes the contents of the line above it. The base cases are the boarders of the board, which should keep their boundaries.
Sorry for the mixed naming, by the way. 'board', 'b', 'tableMap', 'boarder' are all generally the same thing: the mapping of the contents of the Tetris board, ie the fallen pieces.
keyboardAct defines how a key press can move a shape on the board, while movePiece determines if this movement is valid.
These functions are used to calculate translated points for collision detection and the "tetris unit" is defined here. Using `tunit` not only helps to keep things in correct proportion, but it also helps Haskell's typing inference when used as a unit.