[Caml-list] choosing modules at runtime

[Caml-list] choosing modules at runtime

[Henri Dubois-Ferriere]

Say I have a module signature M which is implemented by module structs 
M_1, M_2, M_3, .. M_N.

At runtime , depending on some command-line parameters, I will choose one 
of the module implementations (they use different algorithms internally). 

This means my main code will be littered with things like

if (use algorithm 1) then
M_1.run_algo()
else if (use algorithm 2) then
M_2.run_algo() ...

each time I use a function from the signature M. Of course I could do a 
shorthand hack like

let run_algo = 
  if (use algorithm 1) then
  M_1.run_algo
  else if (use algorithm 2) then
  M_2.run_algo ...

and then simply call run_algo from then on. (But this needs to be done for 
every function/value that the signature M exports).

Am I missing something obvious here? Of course what I would conceptually 
like to do would be something like

let Mod = if (use algorithm 1) then M_1 else if (use alg 2) then M_2 ..

and then be able to call Mod.run_algo(), but that probably belies that I 
am still thinking in an OO manner...

Thanks for any hints on the matter.

Henri

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Andreas Rossberg]

Henri Dubois-Ferriere wrote:
> 
> let run_algo =
>   if (use algorithm 1) then
>   M_1.run_algo
>   else if (use algorithm 2) then
>   M_2.run_algo ...
> 
> and then simply call run_algo from then on. (But this needs to be done for
> every function/value that the signature M exports).

It's not too bad, just do:

 let (algoA, algoB, algoC) =
   if (use algorithm 1) then
   (M_1.algoA, M_1.algoB, M_1.algoC)
   else if (use algorithm 2) then
   (M_2.algoA, M_2,algoB, M_2.algoC) ...

But admittedly it still is somewhat annoying.

> Am I missing something obvious here? Of course what I would conceptually
> like to do would be something like
> 
> let Mod = if (use algorithm 1) then M_1 else if (use alg 2) then M_2 ..
> 
> and then be able to call Mod.run_algo(), but that probably belies that I
> am still thinking in an OO manner...

No, you are right. Unfortunately, this either requires 1st-class
modules, or if-then-else on the module level. (The latter can be
partially faked by heroic use of higher-order functors, but you don't
want to see that and it most likely does not apply to your particular
problem, since the condition itself had to be expressible in the module
language). Both is not (yet?) available in OCaml, and in very few other
languages, for that matter (Moscow ML currently being the only MLish
exception). Such a feature is not impossible to add, but represents a
significant complication of the language that may not be considered
worthwhile.

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Markus Mottl]

Andreas Rossberg schrieb am Dienstag, den 24. September 2002:
> It's not too bad, just do:
> 
>  let (algoA, algoB, algoC) =
>    if (use algorithm 1) then
>    (M_1.algoA, M_1.algoB, M_1.algoC)
>    else if (use algorithm 2) then
>    (M_2.algoA, M_2,algoB, M_2.algoC) ...
> 
> But admittedly it still is somewhat annoying.

Especially if you have many more than three functions.

Even worse, if the modules are generated locally, they might involve
abstract types not visible outside. It could be legal to combine these
functions to generate something that is concrete in another context,
but the type system won't allow you to escape scopes, e.g.:

  module type M = sig
    type t
    val v : t
    val to_int : t -> int
  end

  module Func (Arg : M) : M = struct
    include Arg
  end

  let f x =
    let module Arg = struct
      type t = int
      let v = x
      let to_int x = x end in
    let module MyMod = Func (Arg) in
    MyMod.v, MyMod.to_int

  let _ =
    let v, to_int = f 42 in
    print_int (to_int v)

The compile will print the following error:

  File "foo.ml", line 12, characters 2-143:
  This `let module' expression has type Func(Arg).t * (Func(Arg).t -> int)
  In this type, the locally bound module name Arg escapes its scope

If we could return the whole module "MyMod" instead (much more convenient
than returning a tuple anyway), the context (i.e. the one including the
abstract type) could be always provided at the place of use.

> Such a feature is not impossible to add, but represents a significant
> complication of the language that may not be considered worthwhile.

It would be interesting to learn, how many people could really need
first class modules already now. Then we'd see whether the complication
is worthwhile or not. If it doesn't take a Herculean effort to implement
them, I'd find them useful enough. Of course, if INRIA has even better
things to do implement now, I won't mind... ;-)

Best regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Markus Mottl]

On Tuesday, 24 Sep 2002, Henri Dubois-Ferriere wrote:
> At runtime , depending on some command-line parameters, I will choose one 
> of the module implementations (they use different algorithms internally). 
[snip]
> Am I missing something obvious here? Of course what I would conceptually 
> like to do would be something like
> 
> let Mod = if (use algorithm 1) then M_1 else if (use alg 2) then M_2 ..
> 
> and then be able to call Mod.run_algo(), but that probably belies that I 
> am still thinking in an OO manner...

What you are actually looking for is first class modules, i.e. modules,
which can be passed around at runtime. This topic has already popped up a
couple of times in the past, especially since Claudio Russo implemented
them along the lines of his PhD-thesis for Moscow ML. Here is a link to
the start of such a thread:

  http://caml.inria.fr/archives/200101/msg00054.htm

Unfortunately, I haven't heard of any efforts to integrate this extension
into the main distribution of OCaml. I do indeed have quite a few
sources that would benefit from first class modules. Parameterization
of algorithms can be quite painful without.

E.g., I have a large number of modules implementing various machine
learning heuristics that all have their own concrete types and algorithms
but match the same signature. Depending on some command-line arguments
I'd like to use some of them as arguments to a functor to instantiate a
machine learning system. If I didn't use some absolutely awful workarounds
(extracting functions from modules and passing tuples of them around just
to recreate the modules elsewhere), I'd even suffer from combinatorial
explosion, because I'd have to consider the Cartesian product of all
possible functor applications.

I'd really highly appreciate some extensions to the module system that
make such things simpler...

Best regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Olivier Andrieu]

 Henri Dubois-Ferriere [Tuesday 24 September 2002] :
 >
 > Say I have a module signature M which is implemented by module structs 
 > M_1, M_2, M_3, .. M_N.
 > 
 > At runtime , depending on some command-line parameters, I will choose one 
 > of the module implementations (they use different algorithms internally). 
 > 
 > This means my main code will be littered with things like
 > 
 > if (use algorithm 1) then
 > M_1.run_algo()
 > else if (use algorithm 2) then
 > M_2.run_algo() ...

You could use local modules :

 if (use algorithm 1) then
  let module M = M_1 in
  M.run_algo() ...
 else if (use algorithm 2) then
  let module M = M_2 in
  M.run_algo() ...

the point is that the blocks under the `let module .. = ' are the
same, so you can copy/paste them. You could use some preprocessing
treatment to make it look better.

-- 
   Olivier
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Sven LUTHER]

On Tue, Sep 24, 2002 at 12:18:49PM +0200, Olivier Andrieu wrote:
>  Henri Dubois-Ferriere [Tuesday 24 September 2002] :
>  >
>  > Say I have a module signature M which is implemented by module structs 
>  > M_1, M_2, M_3, .. M_N.
>  > 
>  > At runtime , depending on some command-line parameters, I will choose one 
>  > of the module implementations (they use different algorithms internally). 
>  > 
>  > This means my main code will be littered with things like
>  > 
>  > if (use algorithm 1) then
>  > M_1.run_algo()
>  > else if (use algorithm 2) then
>  > M_2.run_algo() ...
> 
> You could use local modules :
> 
>  if (use algorithm 1) then
>   let module M = M_1 in
>   M.run_algo() ...
>  else if (use algorithm 2) then
>   let module M = M_2 in
>   M.run_algo() ...
> 
> the point is that the blocks under the `let module .. = ' are the
> same, so you can copy/paste them. You could use some preprocessing
> treatment to make it look better.

But some sort of syntactic sugar could be added to ocaml in order to
handle this properly, could it not ?

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Yamagata Yoriyuki]

From: Henri Dubois-Ferriere <henridf@lcavsun1.epfl.ch>
Subject: [Caml-list] choosing modules at runtime
Date: Tue, 24 Sep 2002 10:48:55 +0200 (CEST)

> Say I have a module signature M which is implemented by module structs 
> M_1, M_2, M_3, .. M_N.
> 
> At runtime , depending on some command-line parameters, I will choose one 
> of the module implementations (they use different algorithms internally). 

How about making the whole program into the functor, say, Prog.  Then,
the branch appears only once for the "main".

if (use algorithm 1) then
Prog (M_1).main ()
else if (use algorithm 2) then
Prog (M_2).main () ...

Numerix uses this trick for choosing implementation of big integers

> but that probably belies that I am still thinking in an OO
> manner....

Yes :-)
--
Yamagata Yoriyuki
http://www.mars.sphere.ne.jp/yoriyuki/
PGP fingerprint = 0374 5290 7445 4C06 D79E AA86 1A91 48CB 2B4E 34CF

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Alessandro Baretta]

Henri Dubois-Ferriere wrote:
> Say I have a module signature M which is implemented by module structs 
> M_1, M_2, M_3, .. M_N.
> 
> At runtime , depending on some command-line parameters, I will choose one 
> of the module implementations (they use different algorithms internally). 

I do the same in my application. I have a module defining a 
module type which provider modules must implement. I then 
dynamically link a cmo specified on the command line, which 
implements the module type. This file registers the exported 
functions and values with Registry module, through which 
they are called and used by the application. Not a simple 
scheme, but useful and appropriate in my case.

> This means my main code will be littered with things like
> 
> if (use algorithm 1) then
> M_1.run_algo()
> else if (use algorithm 2) then
> M_2.run_algo() ...

Dynlink solves this problem. But, I'll admit, conditional 
module expressions would be a cool, cool feature. And I 
don't believe this requires first class modules.


Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Maxence Guesdon]

You can use records :

type t = {
	f1 : int -> int
	f2 : string -> int
	...
}	

let module1 = 
	let ...
	  (* whatever you want *)
	in
	{
	f1 = ... ;
	f2 = ... ;
	...
	}

let module2 = 
	let ...
	  (* whatever you want *)
	in
	{
	f1 = ... ;
	f2 = ... ;
	...
	}

let algo = if cond then module1.f1 else module2.f2

-- 
Maxence Guesdon
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] choosing modules at runtime

[Sebastien.deMentendeHorne]

Hmmm, by the way, if a plugin architecture is needed, are we facing the same
problem ?

I did look at OCaml some weeks ago for an application which is at the moment
written in C++ and that needs a plugin architecture.
There are virtual classes on one side for specifying the interface of the
plugin (in ocaml, I think it would be module signatures) and concrete
classes that inherits from the virtual ones and that implements in different
ways the same signature (module implementations in ocaml). The algorithms
are generic as they are written for the virtual classes.
The loading of the different implementation is done dynamically and
dispatching of methods is done via polymorphism.

Is first class modules the elegant solution for this plugin framework (OCaml
not useful here)?
Does Ocaml offer another solution for this problem ?

Best regards,

Sébastien de Menten               |    ELECTRABEL 
Tel:  ++32 10 48 51 76            |    Risk Asset and Liability Management, 
Fax:  ++32 10 48 51 09            |    Place de l'université, 16, 4ème étage

Gsm:  ++32 478 789 444            |    B-1348 Louvain-la-Neuve, BELGIUM 



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Markus Mottl]

On Tue, 24 Sep 2002, Sebastien.deMentendeHorne@electrabel.com wrote:
> Hmmm, by the way, if a plugin architecture is needed, are we facing the same
> problem ?

It depends. In most cases higher-order modules (i.e. functors) are perfect
tools for creating plugin architectures. Problems only sometimes arise
when "plugins" are dynamically selected or even generated, e.g. depending
on some command-line switches. Then they can become somewhat cumbersome
to use. In such cases first-class modules would be fine.

Best regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] choosing modules at runtime

[Sebastien.deMentendeHorne]

> 
> On Tue, 24 Sep 2002, Sebastien.deMentendeHorne@electrabel.com wrote:
> > Hmmm, by the way, if a plugin architecture is needed, are 
> we facing the same
> > problem ?
> 
> It depends. In most cases higher-order modules (i.e. 
> functors) are perfect
> tools for creating plugin architectures. Problems only sometimes arise
> when "plugins" are dynamically selected or even generated, 
> e.g. depending
> on some command-line switches. Then they can become somewhat 
> cumbersome
> to use. In such cases first-class modules would be fine.
> 
I looked at functors and they suffered of staticity.
The plugin we use are dynamically (runtime) selected and they should/could
be even generated at runtime, compiled, loaded and selected... I think that
plugins are most often used in a dynamic way so definitely, first-class
modules would be great.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Markus Mottl]

On Tue, 24 Sep 2002, Sebastien.deMentendeHorne@electrabel.com wrote:
> I looked at functors and they suffered of staticity.

It seems you are coming from an OO-background... ;-)

> The plugin we use are dynamically (runtime) selected and they
> should/could be even generated at runtime, compiled, loaded and
> selected... I think that plugins are most often used in a dynamic way
> so definitely, first-class modules would be great.

Actually, I'd say that most problems of "programming in the large" can
be and are best solved statically. But in some cases, one needs more
dynamic means of parameterization. Then, first-class modules or objects
enter the game.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[John Max Skaller]

Markus Mottl wrote:

> On Tue, 24 Sep 2002, Sebastien.deMentendeHorne@electrabel.com wrote:

> Actually, I'd say that most problems of "programming in the large" can
> be and are best solved statically. But in some cases, one needs more
> dynamic means of parameterization. 


It is a nice specification that clearly admits its own weakness.

It is possible to have a purely static solution to almost
any problem. The simple demonstration is that you can write
an interpreter -- add one more level of indirection.

Of course, that interpreter itself is for some programming
language with static type checking or not ..

It is clear the correct language to interpret here would be
the same as the orginal source language..

Which implies dynamic loading is a mandatory feature
for solving general problems.

The particular weakness here is the notion that
a particular problem has a static solution .. the difficulty
being most modern programs need to solve a class of problems,
not a single one.

For example, in a telco environment a high level
service handling program has to implement *arbitrary*
business rules. One solution is C++ with dynamic loading.

Sure, you can write an interpreter..but the cost in 

performance terms could be nasty .. and the cost in

terms of maintenance could be a nightmare .. better to
use a tried and proven language translator.


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Alessandro Baretta]

I just realize that only John Max Skaller got this message. 
I am now sending it to the list, for which it was intended.

Alex

John Max Skaller wrote:
 > Markus Mottl wrote:
 >
 >> On Tue, 24 Sep 2002, 
Sebastien.deMentendeHorne@electrabel.com wrote:
 >
 >
 >> Actually, I'd say that most problems of "programming in 
the large" can
 >> be and are best solved statically. But in some cases, 
one needs more
 >> dynamic means of parameterization.

There's a bunch of people in the Java community who might 
disagree.

 > It is a nice specification that clearly admits its own 
weakness.
 >
 > It is possible to have a purely static solution to almost
 > any problem. The simple demonstration is that you can write
 > an interpreter -- add one more level of indirection.
 >
 > ...
 >
 > Which implies dynamic loading is a mandatory feature
 > for solving general problems.

Very true. A concrete business example: I will be deploying
this week a program I wrote which uses PXP to interpret XML
templates, to format a datastructure built by a Dynlinked
module. The datastructure could be built by parsing an ASCII
file (as is the present case) or by executing a query on a
database or by parsing an XML document downloaded from an
intranet server or in any other conceivable way. This is a
polymorphic problem class which admits only solutions
comprising runtime parametrization, both is terms of
data--the XML templates--and of code.

Coincidentally, I have recently come across the GCC Java
project. (http://gcc.gnu.org/java) They have a compiler with
   both a bytecode and a native backend, much like Ocaml. In
addition they get a native runtime system which is more
flexible than either the JVM or ocamlrun in that it enables
both byte-compiled and natively compiled classes to be
linked dynamically and automatically with the usual
classpath resolution strategy. This might be the way to go
for Ocaml, too, with the possible exception of the classpath
thing, which we sort of agreed against.

One example: I'd love to write a generic client application
capable of connecting with a database server for the data
and to a remote repository of compiled modules implementing
the logic of different application tasks the customer wishes
the system to automate. Dynlink already partially solves the
problem by allowing dynamic linking of cmo's over NFS, but
dynamic linking over other network transport protocols would
be a real pain, requiring explicit downloading and temporary
storage. And finally, a mixed byte-native runtime is not
supported.

Anything we can do about this?

Alex


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Dave Mason]

>>>>> On Wed, 02 Oct 2002 15:04:48 +0200, Alessandro Baretta <alex@baretta.com> said:

> One example: I'd love to write a generic client application capable
> of connecting with a database server for the data and to a remote
> repository of compiled modules implementing the logic of different
> application tasks the customer wishes the system to
> automate. Dynlink already partially solves the problem by allowing
> dynamic linking of cmo's over NFS, but dynamic linking over other
> network transport protocols would be a real pain, requiring explicit
> downloading and temporary storage.

We will very shortly be releasing just such a thing, called InetApp.
It only runs bytecode, but it runs transparently on Windows, Mac, and
Linux.  Hopefully the release will be in the next few weeks.

> And finally, a mixed byte-native runtime is not supported.

This is definitely something I'd like to see.  As I understand it,
there are 2 problems: bytecode vs. native function dispatch, and GC.
Trying to resolve this is on my list of things to do, but it's a long
list, so I'd love to hear that someone else has done it first!

../Dave
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] choosing modules at runtime

[Chris Hecker]

> > And finally, a mixed byte-native runtime is not supported.
>This is definitely something I'd like to see.  As I understand it,
>there are 2 problems: bytecode vs. native function dispatch, and GC.
>Trying to resolve this is on my list of things to do, but it's a long
>list, so I'd love to hear that someone else has done it first!

I looked into this a fair amount and there were some threads on this topic 
on the list.  It's totally possible to do, but it looks like a 
mess.  Xavier explained the problems in the old thread.  I looked into how 
to do the function dispatch without requiring an if statement or two 
pointers in the closures, and it seems doable by being wacky with nop 
instructions on the various supported architectures (for better or for worse).

Here's the thread:
http://groups.google.com/groups?th=d0d0f6e6592e11ea

A unification of the GC between bytecode and native would be good for the 
other wacky feature I'd like to see implemented: 
coroutines/fibers/cooperative-threads/whatever-your-pet-name-is.  These 
require allocating a block of memory, treating it as a stack and switching 
to it to run a coroutine.  All of the allocated stacks have to be visible 
to the GC so it doesn't treat as garbage something living on a non-running 
stack.  I haven't looked into this at all, but I assume there's something 
in there for the preemptive threads, but I wonder how different it is for 
bytecode versus native.  Coroutines are useful in games for writing AI code 
so you don't have to write it as an FSM to spread it across frames.

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners