[MLton] F# - the future of ML?

[Daniel C. Wang]

BTW the MSIL need not be typesafe for the CLR to run it. In fact I 
suspect it would not be too hard to emit unsafe C code that compiles 
under "cl" with /clr. The advantage of this is that you then can just 
call .NET code transparently from the emitted C code.

http://msdn2.microsoft.com/en-us/library/k8d11d4s.aspx


skaller wrote:
> On Tue, 2006-12-19 at 01:29 +0100, Wesley W. Terpstra wrote:
>   
>> I realize this is a bit off-topic, but wanted the opinions of the  
>> people on this list. :-)
>>
>> I ran into F# over the weekend and was quite impressed!
>>     
>
>   
>> Thoughts?
>>     
>
> F# stole the Felix model of code generation :)
>
> Felix is built on C/C++ the same way as F# is on .NET,
> and for the same reasons.
>
> [NekoML is also built that way, on top of Neko 
> which has its own VM]
>
> The downside is: you're stuck with what might be an
> inappropriate object and type model.
>
>
> For those that don't know: F# defines primitives in terms
> of CLR machine instructions. It therefore has direct,
> native, access to the .NET platform.
>
> Felix defines its primitives with snippets of C++ code,
> such as:
>
> 	fun print[t]: t = "cout << $1;";
>
> This model, which allows embedding of the target language
> directly into the source language makes for a very powerful
> and easy to develop translator .. although the embeddings
> may be unsafe (as with any binding). However the 'FFI' here
> is mainly a type wrapping -- the native object model is used
> so there is no need for run time glue logic.
>
> So .. if you tried to do this with Mlton and C you'd be stuck
> unable to use a continuation passing model, or implement the
> user space high performance threading, since C doesn't really
> support that.
>
> Felix makes that compromise for compatibility, availability
> of libraries, and easy wrapping for end users etc, but has
> the luxury of being designed from scratch to do so.
>
> Mlton on the other hand wants to implement SML so doen't
> have the luxury of designing the language to suit the
> target object and type model.
>
> So my guess is that this model is useful when your
> primary goal is compatibility with a target model,
> but not so good when your goal is compatibility with
> a standardised source model.
>
>
>