Dynamic binding to the Mono runtime API

[Jakub Szewczyk via Digitalmars-d-announce]

On Sunday, 4 June 2017 at 09:43:23 UTC, Adam Wilson wrote:
> On 6/4/17 01:18, Jakub Szewczyk wrote:
>> This is an interface to the Mono libraries, D/CLI would [...]
>>
> My interest is less in code ports than bindings to the actual 
> code. My experience with code ports or translations is that 
> often subtle bugs creep in during translation due to the fact 
> that each language has different idioms.
>
> What I am thinking about is a tool that loads an assembly, 
> examines it's types and methods via this API and emits D code 
> that directly interfaces into the .NET types via this API. The 
> tricky part here is mapping the .NET dependencies into D. The 
> moment the library exposes a type from a dependency, that 
> dependency ALSO needs to be included somehow. All libraries 
> reference "mscorlib", AKA the BCL, so we'd have to provide a 
> "mono-bcl" package on DUB.

That's what I actually meant, "porting" was a misused term on my 
part, "binding" would be a better word, sorry for that.
As for the dependency problem - I think that a linking layer 
generator would accept a list of input assemblies (and 
optionally, specific classes) to which it should generate 
bindings, the core Mono types could be automatically translated 
to D equivalents, and the rest could be left as an opaque 
reference, like MonoObject* in C, also providing support for very 
basic reflection through the Mono methods if it turned out to be 
useful for anyone.

>> Mono actually supports some kind of GC bridging as far as I 
>> understand, [...]
>>
> On the GC side I was mostly thinking about GC Handles so that 
> the objects don't get collected out from underneath us. That is 
> something is trivial to code-gen.
>
> As for exceptions, I like the catch->translate->rethrow 
> mechanism. And if the exception is unknown we could simply 
> throw a generic exception. The important thing is to get close 
> to the D experience, not try to map it perfectly.

Yes, GCHandles to keep Mono objects in D and a wrapper based on 
that GC bridge to keep D references from being collected by Mono. 
I have previously implemented a very similar mechanism for Lua in 
a small wrapper layer, and it worked perfectly.

>> I can make a static library version, [...]
>
> Thank you for this! I find static libraries easier to deal 
> with. I'm sure other people have differing opinions, so having 
> both would make everyone happy.

It's now public as v1.1.0, I've tested that it works with the 
tiny sample, the only important part is that the library to link 
must be specified by the project using this binding, because 
those paths may vary across systems, and they cannot be specified 
in code like the dynamic link ones. However, a simple 
"libs":["mono-2.0"] entry in dub.json should be enough for most 
use cases.