> You can see how this makes it impossible to mutate the state without remembering to aquire the lock.

Not quite true. Looking at the type signature of e.g. RWArc::write I see this:

    fn write<U>(&self, blk: |x: &mut T| -> U) -> U

which means I could probably do:

    let mut n = local_arc.write(|nums| {
         nums[num] += 1;
         return ~(*nums);
     });
    n[2] = 42;

You're not letting anything escape. You're copying `nums` and then mutating your copy. And this only works because `nums` can be implicitly copied like this. If you changed it from `[int, ..3]` to `~[int]` you'd get a compiler error (as `~[T]` cannot be implicitly copied).

What puzzles me about Jolla and it's Sailfish OS is the constant emphasis on being "truly open" when in fact the sources of the OS are nowhere to be found. They point you to projects such as Mer and say Sailfish OS is based on it but by the same logic Apple is "truly open" because OS X is based on Darwin.

It's not fully open. See http://piratepad.net/JollaSoftwareState

However Jolla said that long term plans about opening things up aren't finalized.

WebOS is not open source so I fail to see why a "geek" should love it. On the contrary - they should avoid it!

You sound a bit like Stallman. Even if you are using open source software you still use closed source hardware most of the time.

What's really wrong with closed source?

Funny thing...it is more open than the open source alternative.

I wonder if someone wants to port the type checker of Typed Racket over to Clojure?

The type checker would have to play nice with java types. Does the racket type checker support inheritance and interfaces/protocols?

FRTime first please!

The HLVM implementation is for everyone to see at http://hlvm.forge.ocamlcore.org/ . There is a public mailing list at https://lists.forge.ocamlcore.org/pipermail/hlvm-list/ and I am sure Jon Harrop would be more than happy to discuss all technical details there.

Mono OTOH might be okayish for C#, but for instance F# so far has no open source implementation. Also Mono is lacking w.r.t. TCO and GC, so its not even close to a decent VM for functional languages.

Yes, it's 'open' -- not arguing that, nor would I dispute that Mono is far from perfect. [1]

But, like so many FF projects: is this the cart, or the horse?

In other words, this feels more like a promotional project for the consulting firm and its pay products than it does a 'real' project. I freely admit this judgement has some external bias; Jon H. has a reputation.

[1] footnote: (Of course, neither is the linked project... 128 bits for each and every pointer on a 32-bit architecture? Does that mean 256 bits per pointer on 64-bit? Yikes!)

I'm Jon Harrop. HLVM is a hobby project that I work on when I can find the time. If I could commercialize it then I would but there is no short-term way to make decent money from a VM/language that I can see.

I suggest you think carefully about when HLVM's fat references are a disadvantage compared to the alternatives and why. The real reasons are not at all what you're thinking (or what I thought for a long time).

This VM is based on LLVM and in particular aimed at parallel programming. As its author said: "HLVM is an experiment to see what a next-generation implementation of a language like OCaml might look like, addressing all of OCaml's major shortcomings (interoperability, parallelism and some performance issues)." [http://caml.inria.fr/pub/ml-archives/caml-list/2009/09/a94db...]