On Saturday 17 January 2009 23:29:06 David Teller wrote:
> On Sat, 2009-01-17 at 22:17 +0000, Jon Harrop wrote:
> > We've wrapped part of WPF in a functional shim for our F# for
> > Visualization product and, even though it was originally intended for
> > internal use only, our customers are loving using it themselves because
> > it is vastly simpler and less error prone than trying to use WPF's own
> > heavily-imperative but entirely thread unsafe OOP-based API directly.
>
> Out of curiosity: is there a public documentation for your functional
> API?

Sure thing:

http://www.ffconsultancy.com/products/fsharp_for_visualization/docs/namespaces.html

That reminds me, I need to update it for the latest release. Our Smoke Vector 
Graphics product for OCaml uses similar techniques but it is less evolved:

http://www.ffconsultancy.com/products/smoke_vector_graphics/

> > Incidentally, Cilk looks like the ideal tool to write a parallel GC...
>
> Mmmmhhh... Care to argument this? While I'd be glad to implement, say,
> graph search or min-max/alpha-beta with Cilk, I don't quite see how a
> concurrent GC would fit into the Cilk model.

Parallel, not concurrent. By parallel GC, I mean stop the world and call into 
code that traverses the heap using a parallelized algorithm. That would just 
be a simple recursive function in Cilk that is, of course, just graph 
traversal.

You are quite right that Cilk is not useful for writing a concurrent GC, where 
the mutator and GC use fine-grained concurrency to avoid global stalls.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e