| {------------------------------------------------------------------------------ | |
| reactive-banana | |
| Implementation of an "industry strength" game loop with fixed time step | |
| and variable fps. | |
| See also http://gafferongames.com/game-physics/fix-your-timestep/ | |
| -------------------------------------------------------------------------------} | |
| {-# LANGUAGE NoMonomorphismRestriction #-} | |
| module Main where |
Have you ever had to write code that made a complex series of succesive modifications to a single piece of mutable state? (Almost certainly yes.)
Did you ever wish you could make the compiler tell you if a particular operation on the state was illegal at a given point in the modifications? (If you're a fan of static typing, probably yes.)
If that's the case, the indexed state monad can help!
Motivation
| {-# LANGUAGE RankNTypes #-} | |
| {-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-type-defaults -fno-warn-unused-do-bind -fno-warn-unused-imports -fno-warn-orphans #-} | |
| -- | |
| -- Random walk emitter with go and stop button | |
| -- | |
| module Main where | |
| import Control.Applicative |
| A Whirlwind Tour of Combinatorial Games in Haskell | |
| ================================================== | |
| Combinatorial games are an interesting class of games where two | |
| players take turns to make a move, changing the game from one position | |
| to another. In these games, both players have perfect information | |
| about the state of the game and there is no element of chance. In | |
| 'normal play', the winner is declared when the other player is unable | |
| to move. A lot of famous strategy games can be analysed as | |
| combinatorial games: chess, go, tic-tac-toe. |
| # Install a local copy of Hoogle (OS X 10.10, GHC 7.10.1) | |
| # Download | |
| cd | |
| cabal unpack hoogle | |
| cd hoogle-4.2.40/ | |
| # Use a sandbox | |
| cabal sandbox init |
| The Challenge | |
| ------------- | |
| Given the following riddle, write a regular expression describing all possible answers, | |
| assuming you never make a move which simply undoes the last one you made. | |
| The Riddle | |
| ---------- | |
| You are on your way somewhere, taking with you your cabbage, goat, and wolf, as always. | |
| You come upon a river and are compelled to cross it, but you can only carry one of the | |
| three companions at a time. None of them can swim because this isn't THAT kind of riddle. |
| -- in reply to http://www.reddit.com/r/haskell/comments/21mja6/make_lllegal_state_transitions_unrepresentable/ | |
| -- | |
| -- We implement a tiny language with three commands: Open, Close, and Get. | |
| -- The first Get after an Open returns 1, the second Get returns 2, and so on. | |
| -- | |
| -- Get is only valid while the state is open, and | |
| -- Open must always be matched by a Close. | |
| -- We enforce both restrictions via the type system. | |
| -- | |
| -- There are two valid states: Opened and Closed. |
This document is a collection of concepts and strategies to make large Elm projects modular and extensible.
We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:
