[Haskell-cafe] Reflections on Haskell and ICFP Contest 2009
Rafael Gustavo da Cunha Pereira Pinto
RafaelGCPP.Linux at gmail.com
Mon Jun 29 09:29:18 EDT 2009
Hi Tuh2009/6/29 minh thu <noteed at gmail.com>
> > First step solved. (BTW: I am attaching the first version to this e-mail.
> > 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:
Shame on me! :-(
If only I have posted this rant earlier! :-D
> 2) Running the VM:
> > This is the step I am working on. A really good and obvious approach to
> > 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
> > data memory contents)
> > c) I have a monoid output (the output ports)
> Why a monad ? Why not just a function State -> State and the use a function
> iterate to do the work ?
I am considering that using the monad all the state and environment
threading will be simplified. The output part is optional.
But you are absolutely right, I could use a state composed by (Inputs,
program counter, status, data), which would do just as well, as it is just a
matter of not touching the program and the input.
> > 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
> Of course, making the best move is another problem.
I think the simulator itself is another State->State function, but this time
the state is a [Output].
> Good luck !
> Rafael Gustavo da Cunha Pereira Pinto
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe