Re: [Caml-list] Functional design for a basic simulation pipe.

[Pietro Abate <Pietro.Abate@anu.edu.au>]

Hi,

On Wed, Oct 10, 2007 at 11:56:02AM +0100, Hugo Ferreira wrote:
> >> a: requires the input of a state and outputs an event
> >> b: requires input of a state and the event generated at that state and
> >> outputs processed data
> >> c: consumes n number elements of processed data and stops when it
> >> requires no more such data
> >>
> >> Note that "c" will "pull in" for example 10 states and check for
> >> termination, "b" will therefore need "pull in" 10 events. Each time it
> >> pulls in an event it generates a state. This last state must be made
> >> available to "a" so that it may generate its next event.
> >>
> >> The issue here is how can I implement this so that I can flexibly
> >> configure experiments by "constructing" a chain of actions but still be
> >> able to pass back the state to one of those actions. Something like:
> >>
> >> let exp = a |> b (output 1 back to a) |> c
I'm not entirely sure this is correct. Note that I've used an exception
to get out of the loop just because I'm too lazy to wrap my head around
the exception monad. I'm also not sure that is the best way of using a
state monad... Any monad-experts out there to comment ?

This is the code:

type inputstate = int
type output = int
type final = int
type event = int

module StateMonadMake(T:sig type t end) =
struct
  type 'state mt = 'state -> T.t * 'state

  let return a = fun s -> a, s
  let bind m f = fun s -> let a, s = m s in f a s
  let fetch = fun s -> return s s
  let store = fun s -> fun _ -> return () s
  let modify f = fun s -> return () (f s)
end

module SM = StateMonadMake(struct type t = inputstate end)
exception Stop of final

let a (s : inputstate) : event = 1

let b (e : event) ( s : inputstate ) : (inputstate * output) =
    match s with
    0 -> print_endline "final state" ; (0,1)
    |_ -> Printf.printf "at state %i\n" s ; (s-1,s+1)

let c ( l : output list ) : final =
    List.iter print_int l ;
    List.fold_left (+) 0 l

let rec exp inputstate =
    SM.bind inputstate (fun state ->
        let newevent = a state in
        let (newstate,newdata) = b newevent state in
        SM.bind (SM.modify (fun olddata -> newdata::olddata)) (fun _ ->
            if newstate = 0 then
                SM.bind (SM.fetch) (fun data ->
                    raise ( Stop ( c (data) ))
                )
            else exp (SM.return newstate)
        )
    )
;;

let run =
    try exp (SM.return 10) []
    with Stop(i) -> Printf.printf "final %i\n" i

$ocaml hf.ml 
at state 10
at state 9
at state 8
at state 7
at state 6
at state 5
at state 4
at state 3
at state 2
at state 1
234567891011final 65


pietro

> > 
> > Just to be sure I understood well, here is a diagram:
> > 
> > --> a --> b -+-------------------------------------------------> output1
> >              |
> >              +--state1-> a --> b -+----------------------------> output2
> >                                   |
> >                                   +-state2-> a --> b -+--------> output3
> >                                                       |
> >                                                          ...
> >                                                               -> outputn
> > 
> >                                                                     |
> >                                                                     |
> >                                                                     |
> >                                                                     V
> > 
> >                                                                     c
> > 
> > 
> > Do you agree with this ? (n beeing a variable of course...)
> 
> Not quite. More like:
> 
> (_,s0)
> -> a-> s0,e1 -> b -+--------------------------------------> s1
>                    |
>                    +--s1-> a -> s1,e2 -> b-+--------------> s2
>                                            |
>                                             ...
>                                                          -> sn
>                                                             |
>                                                             |
>                                                             |
>                                                             V
>                                                             c
> 
> Note that "a" doesn't generates states "sn" it just passes it on.
> It only generates events "en". "b" simple takes a state "sn-1" and the
> events "en" and generates a new state "sn".
> 
> > Shall c also take the states ?
> > 
> 
> Yes. But the idea is to add other functions to the "pipe" that will
> change states to other data types for further processing.
> 
> Note also that only the last function actually knows how much data is
> required.
> 
> > (I believe in good drawings to help finding an answer...)
> 
> Well it certainly easier to express the flow of the data.
> 
> 
> 
> > _______________________________________________
> > Caml-list mailing list. Subscription management:
> > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> > Archives: http://caml.inria.fr
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> > 
> > 
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
++ 
++ "All great truths begin as blasphemies." -George Bernard Shaw
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.gnu.org/philosophy/no-word-attachments.html