Browse thread
C++/C# inheritance is bad?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2009-01-17 (23:46) |
From: | Jon Harrop <jon@f...> |
Subject: | Re: [Caml-list] C++/C# inheritance is bad? |
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