Course:CPSC312-2021/Tic Tac Toe

From UBC Wiki

Authors: Alan Yan, Richard Li

What is the problem?

We are exploring a Haskell implementation of the popular game Tic Tac Toe with a UI to see if making front end applications using Haskell would be easier or harder compared to other front-end solutions. A player vs computer mode is implemented, as well as a GUI for the game that opens in a new window when you run the program. The window has 9 empty squares for players to click and there will be a display box at the top of the window that will display various feedback messages depending on the current state of the game. We wanted to see if building a UI could be done functionally and feel natural in Haskell.

What is the something extra?

The GUI that we built improves the user interaction and appearance of the game. We used the Magic Sum game from class to represent the different states of the game and Minimax algorithm the decision making of the computer AI.

What did we learn from doing this?

We learned about using gi-gtk and GTK in general as a UI designing platform. We also briefly explored Glade as a tool to create a UI non programatically which we found to be quite laggy so we ended up not using it in our final UI. We learned about IORefs and we realized that GTK did not feel very functional because we didn't really need to rely on recursion to hold state as we have been doing in class and it felt quite different to the way we were programming in class because we ended up passing around a reference to State rather than threading it through which feels more like a non-functional language. We also found that this was necessary because there would be no way to hold a state across 9 buttons and so we found that this would be easier to keep a reference to a State which doesn't change in all the buttons.

We learned about Gtk.Entry and Gtk.Grid and Gtk.Button etc and we learned how useful Haskell can be when testing because it makes unit tests super straightforward and almost a natural part of the process to writing code and produce less bugs. This is again why we came to the conclusion using Haskell for asynchronous work can be kind of challenging as adding IO functions everywhere made it harder for us to truly test the behaviour in all cases and passing a reference rather than a value made it feel lower level than it normally does.

We still had a lot of fun building out this project and there are probably way better UI frameworks that are declarative rather than imperative or feel more functional in nature but gi-gtk was one of the most stable so we wanted to try it out. We think that either way Haskell at the moment serves better purpose for tasks not involving a UI especially when there are so many front end options that are declarative and built solely for creating user interfaces. We think for things such as Machine Learning, Spam Filtering and building more algorithmic solutions is there where Haskell's functional paradigm can truly be utilized.

Links to code?

Course title
Course title
Office Hours:
Class Schedule:
Important Course Pages