[Haskell-cafe] Reflections on Haskell and ICFP Contest 2009

[minh thu]

Hi Rafael,

2009/6/29 Rafael Gustavo da Cunha Pereira Pinto <RafaelGCPP.Linux at gmail.com>:
>
> Hi All,
>
> As the ICFP 2009 contest (http://www.icfpcontest.org) approaches its end, I
> decided to write down some thoughts I had while trying.
>
> On Friday I downloaded the task (http://www.icfpcontest.org/task-1.9.pdf),
> read it for a while, and, since my goal is to finish by Xmas, went to the
> swimming pool. :-D While swimming, I started to think on the problem, and
> realized that the task is almost too easy for Haskell. Actually the task was
> so easy, that they added a final, non-scoring, task for those who have
> finished early.
>
> This year's task is to build a VM that runs a (simple) program that
> simulates the physics of a satellite. The VM code has no branches, acting
> like a huge pocket calculator. The mission is to create a simulator that
> interact with this VM and maneuver the sattelite(s) on predefined patterns.
>
> Here is how it went:
>
> 1) Reading the orbiter data file:
>
> The orbiter data file is a stream of 32-bit unsigned integers, which are
> commands, and 64-bit double precision IEEE-754 floats, which are data,
> forming a 96-bit frame. For this part I decided to use the Data.Binary
> module from hackage. The module is great, and it is very simple to use. But
> that took me 3 hours to learn how to use it (which, with my "honey-do" list
> ended up to be in Sunday morning)
>
> By Saturday night I was cursing "The Binary Strike Force" because
>
>           a) get :: Word32 reads it in little-endian
>           b) get :: Double reads the result of an decodeFloat, which has no
> resamblance at all with IEEE-754 standards
>           c) I spent the entire Saturday (2 hours, honey-do excluded)
> thinking I was doing something wrong!!
>
> I was really pissed of, until I found "getWord32le" and "getWord64le", which
> solved 80% of the problem. The final blow was to decode the Word64 encoded
> IEEE-754 float into a Haskell float, which took me another honey-do-free
> hour.
>
> First step solved. (BTW: I am attaching the first version to this e-mail. I
> will upload to Hackage upon completion, when getIEEE754float64le and
> putIEEE754float64le functions are done!)

Indeed, I found the binary format a difficulty for haskell. But in
fact, hackage has a module that does the work:
http://hackage.haskell.org/package/data-binary-ieee754

> 2) Running the VM:
>
> This is the step I am working on. A really good and obvious approach to run
> the VM is to use a RWS monad, since:
>
>          a) I have a fixed environment (the program and the input ports)
>          b) I have a state (the program counter, the status register and the
> data memory contents)
>          c) I have a monoid output (the output ports)
>
> This is my recurrent complaint (a rant, maybe): this really important monad
> is completely undocumented, left for the developer to figure out how to use
> it. Even each of the singular monads (Reader, Writer and State) is poorly
> documented.
>
> I will do some toy programs to understand each one. Let's hope I can create
> a hands-on tutorial on the RWS monad.

Why a monad ? Why not just a function State -> State and the use a function like
iterate to do the work ?

> 3) Controlling the sattelites
>
> This is going to be a piece of cake (aheeem! Just kidding!!). After
> computing the VM iteration, another computation will take the output data
> time series and estimate the next move.

The next move is easy to estimate : you have the vm and simulating code at hand.
Of course, making the best move is another problem.

> It will be a piece of cake, considering I would have learned enough of
> Haskell state monads on step 2 to have just to worry about the physics of
> the problem!!!
>
>
> I'll keep you updated as my tests go, and hopefully I will have a working
> demo of the task written in Haskell by Xmas... 2010! ;-)

Good luck !

Thu