Why not ILAsm?

[siwatanejo]

I've read in some discussions that ILAsm is not a good option for the project in terms of long-term feasibility. What are the reasons for this?

[FractalFir]

1. ILASM is slow (takes up most of the time spent compiling)
2. ILASM is not actively developed
3. It is an external dependency

[siwatanejo]

Fair enough, my initial question was actually inspired by the idea that this project could actually use this other alternative instead of ILAsm: https://github.com/rspeele/LicenseToCIL

Now, my guess is that you're going to say that it doesn't solve (3) because it is still an external dep, it doesn't solve (2) because its last commit was years ago, and I don't know about its performance but I guess it will be slower than ILAsm because the latter is written in C/C++, right?

However, LicenseToCIL written in F# means:
a) Safer code as its written in a managed language.
b) AFAIU it provides protection against compiling invalid IL code (which would make rust_codegen_clr produce compiler errors instead of producing code that might break at runtime).
c) It could be compiled with AOT to maybe put it on par wrt speed (or better) with ILAsm?
d) And last but not least, an idea that is maybe a bit far fetched: compile LicenseToCIL with Fable? Fable has a Rust transpiler in its last versions.

Now, before you freak out with the (d) idea (haha!), I know that the Fable transpiler is precisely the opposite of what your project is, but why not? Let's put ourselves into the skin of a developer that finds rustc_codegen_clr useful: he's probably an F#/C# developer that wants to consume some Rust library and doesn't want to deal with platform differences (providing different binaries for each platform/arch/etc). He then uses rustc_codegen_clr which is still a Rust tool (instead of libary), which then by using LicenseToCIL+Fable would just mean also using Rust as a tool (instead of library). So it doesn't pose any drawback from the initial advantages that rustc_codegen_clr would provide to him.

Let me know what you think :)

[FractalFir]

Sorry for taking long to answer, I had to take some time to evaluate your idea. LicenseToCIL seems like a good option to have, but it is not a perfect fit for the project.

First of all, Rust code heavily uses pointers, which seem to not be fully supported in F#. I could use unativeint as a replacement, but this would make the conversion lossy, and would entail some other issues.

Second of all, I am not very familiar with F#. I know roughly how it works, but I am not "fluent" in it.

I would also like to trim down on dependencies as much as possible. I have a WIP solution that does not require the .NET runtime to be present (it is needed only to build the project), which would make distribution easier (since the prebuilt binaries could come bundled with the Rust compiler).

That being said, I do see the benefits: this could make AOT easier, and the additional checks could really help me out. I am still not sure this approach is worth it, but I am considering having this as one of the available options.

Thank you for your suggestion!

[siwatanejo]

Second of all, I am not very familiar with F#. I know roughly how it works, but I am not "fluent" in it.

Why would you need to be fluent in it? I mean, the way I understood how this integration would work, is that rustc_codegen_clr would, instead of generating IL files to be consumed by ILAsm, just .fs files (or "file", just one?) that gets consumed by the F# compiler. But if I understood LicenseToCIL properly, then you would only need to generate the CIL inside a big computation-expression block, and some boilerplate F# code to wrap around it. I don't think this requires deep F# knowledge :)

[siwatanejo]

Side note: AFAIU, Rust has some constructs that are better mappable to F# concepts rather than C# (e.g. DUs in general, or Result<_,_> and Option<_> types in particular). Are you planning to use FSharp.Core base types for these to save up some overhead/boilerplate?

[siwatanejo]

In F#, DUs are implemented using polymorphism and inheritance

Where did you get this from? Please note, in F# an enum is different than a DU. The former is object-based (similar to C#), but the latter is idiomatic F#.

[FractalFir]

Where did you get this from?

From looking at F# assemblies :). Here is the basic DU example from MS docs, decompiled into CIL.

It is implemented using inheritance and polymorphism. There is a class Shape with child classes Rectangle, Circle and Prism.
A DU is stored as a reference to the parent class, and downcast appropriately.

An F# DU is a managed class, so it can't be used like a Rust enum, since in Rust, you can take a pointer to a Option, Result and such.

[siwatanejo]

Can inheritting from System.Object be really considered inheritance? You cannot do inheritance of DUs inside F#, so the only reason for F# compiling this into a class that inherits from System.Object is, I guess, compatibility with the .NET runtime. Which means you'll probably need to do the same for Rust DUs?

since in Rust, you can take a pointer to a Option, Result and such.

So? in F# too, via Ref<'T>.

[FractalFir]

They inherit from more than just System.Object . The variants inherit from the DU type, and DUs are stored as a managed reference to a polymorphic class(a byref type).

Rust enums have very strict layout requirements, and are value types.

Yes, you can take a managed reference to a managed byref type, but you can't have an unmanaged pointer to a byref type without pinning it, which is bad for GC performance. F# DUs also incur the cost of allocating a managed object, while Rust enums require no allocations.

While F# DUs and Rust enums serve the same purpose, the implementation details differ diametrically.

[siwatanejo]

Ah right, interesting!