This is a F# -> Javascript compiler and environment, itself running in your browser (in Javascript, obviously).
https://github.com/kjnilsson/fez
This is a project running F# on BEAM (Erlang).
So yes, of course you _can_ write a compiler from F# to whatever platform you choose. It's just a really major effort, in no small part because F# is a way, _way_ higher-level language than C (you'll remember 'worse is better' - a big deal with C is that it's easy to write a compiler for).
We are still feverishly at it in 2018 and there is no end in sight.
> It's just a really major effort
That is neither here nor there.
Can you make F# the language meaningful on other VMs? Not really, as F# is a deep, deep, .Net language.
This isn't about abstraction or syntax, it's that every concept, feature, and element of the toolchain bases itself on .Net capabilities and considerations. From referencing libraries, to scripting, to type generation at specific points in the compile cycle to support Type Providers... Async computation blocks...
Remember, F# came from MS research based on the established working .Net framework, and was tighly tied to fundamental framework improvements (like generics and dynamics). It was built by hardcore .Netters, it's the first "true" .Net language, and it bases major language features on deep-down .Net capabilites not found in other VMs.
The point of the quote is that if you were to try this, at best you'd get "OCaml Over There", not "F#", since F# without .Net is "OCaml". It's not the syntax, it's the deeply intertwined nature of everything else.
What are "dynamics" in this context?
>and it bases major language features on deep-down .Net capabilites not found in other VMs.
Can you give some examples of that?
The differences between the two languages are primarily in the way it integrates with the .NET platform and many assumptions on it.
If you wanted something similar on say, the JVM, starting from OCaml, you would make many different design choices and the result would be a very different language.
For example, the whole type system is based on .NETs type system. interfaces, subtyping and generics, properties and indexed properties, which are quite different on the JVM and other platforms.
F# usually relies on having attributes (annotations in Java) for compatibility with other .NET languages like C# where certain features did not fit into the OCaml syntax and semantics cleanly. These also wouldn't transfer over to other platforms very well.
Some features which F# has that could transfer over to other platforms include measure types, active patterns, and type providers. I believe some of these have already made it to other languages. Gosu, for example, on the JVM had a feature similar to type providers before F# got them, so you could argue that F# borrowed that feature.
Come on, surely you can make a non-.NET dialect of F#. Sure, not every .NET F# program will be portable to it. There must be some considerable abstraction in F# that isn't tied to .NET.