Hi Tuh2009/6/29 minh thu <noteed at gmail.com>
> > 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>
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
> 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)
> >
>> Why a monad ? Why not just a function State -> State and the use a function
> like
> 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
> hand.
> 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 !
>
Thanks!
> Rafael Gustavo da Cunha Pereira Pinto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090629/1326125e/attachment.html