caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Hugo Ferreira <hmf@inescporto.pt>
To: caml-list@yquem.inria.fr
Subject: Functional design for a basic simulation pipe.
Date: Wed, 10 Oct 2007 08:39:05 +0100	[thread overview]
Message-ID: <470C8199.4080708@inescporto.pt> (raw)

Hello,

I have been looking at how I may go about developing a very simple
simulation system for my experiments. The simulation consists in
generating a set of events, these events then cause a state change, the
state change is then analyzed and processed in several steps and finally
termination conditions are checked. When said termination condition is
true the simulation ends and the results are saved.

Now I figured this could be done using composition. For example:

# let ( |> ) f g x = g (f x) ;;
val ( |> ) : ('a -> 'b) -> ('b -> 'c) -> 'a -> 'c = <fun>

# let gen_events s0 = () ;;
val gen_events : 'a -> unit = <fun>

# let gen_states e = () ;;
val gen_states : 'a -> unit = <fun>

# let analyze_data s = () ;;
val analyze_data : 'a -> unit = <fun>

# let check_stop s = () ;;
val check_stop : 'a -> unit = <fun>

Then I could set-up an experiment so:

# let exp = gen_events |> gen_states |> analyze_data |> check_stop ;;
val exp : '_a -> unit = <fun>

And execute it so:

# let start_state = () ;;
val start_state : unit = ()

# let _ = exp start_state ;;
- : unit = ()

Please note that I have used any old types just to get the idea through.
Also note that experiments are set-up with a given set of parameters.
Such parameters can be defined when the "exp" composition is set up.

Ok, so far so good. Now notice how the data events and state change are
potentially infinite. I figured the best way to go about it is with lazy
evaluation so that the calculations terminate when the last function in
the pipe stop "pulling" data in.

This is all "fine and dandy" but the problem I have however is that the
"gen_events" function depends on the last state reached. In other words
"gen_states" updates the current state which should then be made
available to "gen_events" when the next events are "pulled in". Of
course this could be solved with a global reference but this is not
functional. Alternatively we could combine "gen_events" and "gen_state"
into one function (my best bet?).

My question is: how can one design and implement such a "pull pipe" and
solve the problem I have of propagating state back to a previous
function. If this is not possible functionally what other options do I
have? Better yet, what is the better way to implement such a system?

TIA,
Hugo F.


             reply	other threads:[~2007-10-10  7:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-10  7:39 Hugo Ferreira [this message]
2007-10-10  8:34 ` [Caml-list] " skaller
2007-10-10 10:08   ` Hugo Ferreira
2007-10-10 10:31     ` Vincent Aravantinos
2007-10-10 10:56       ` Hugo Ferreira
2007-10-11 12:01         ` Pietro Abate
2007-10-11 13:52           ` Hugo Ferreira
2007-10-11 14:20             ` Pietro Abate
2007-10-10 15:00     ` skaller
2007-10-10 15:56       ` skaller
2007-10-11  6:57         ` Hugo Ferreira
2007-10-11  8:09           ` skaller
2007-10-11  9:54             ` Hugo Ferreira
2007-10-11 13:47               ` skaller
2007-10-11 11:17 ` Zheng Li
2007-10-11 13:48   ` [Caml-list] " Hugo Ferreira
2007-10-15 23:04     ` Zheng Li
2007-10-22  7:48       ` [Caml-list] " Hugo Ferreira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470C8199.4080708@inescporto.pt \
    --to=hmf@inescporto.pt \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).