Rust bindings

[vshymanskyy]

Implement Rust bindings, so wasm3 can be easily used from Rust.

[Veykril]

I'll take a stab at that over the next few days. 😄
https://github.com/Veykril/wasm3-rs

[vshymanskyy]

@Veykril FYI the project now uses CMake library structure.

[Veykril]

Ah great, I'll see if I can make use of it.

[Veykril]

I got a small question regarding the M3Result type. Currently its just a char pointer to static strings if I'm not mistaken in case of errors. What I would like to know is whether it would be possible to maybe replace this with constants/an enum and offer a function to map from that to the static error message string for example. The reason for why I am asking about this is because having the MResult the way it currently is makes it kinda annoying to map to in rust, while if they were just integer constants I could properly match on them and map them to rust error enums for example.

Would be great if you could let me know whether this would be possible. I wouldn't mind being the one to do the change either in that case 😄

[vshymanskyy]

@soundandform any objections?

[soundandform]

Seems okay. The interpreter does use these as well: the trap conditions. The interpreter return type needs to remain as-is. But it's probably fine to cast the enum to a fake pointer in those cases.

[Veykril]

Why exactly do the traps have to stay pointers? Aren't all traps checked by pointer equality anyways? I don't quite see where the problem would arise from moving those to the enum as well.

[soundandform]

Yes. I'm saying make them enums as well. But when you do that work, you will find that the exec portion of the code is what returns the traps. Without going into deep discussion of how the interpreter works at this moment, this return type must remain a pointer. So, you'll have to do some enum to pointer casting and back.

[vshymanskyy]

@Veykril let me know if you need any help

[Veykril]

Tried making the changes in #76. Also I think understood what Steven meant, I assume it was about the m3ret_t return type staying a pointer which makes sense.

[soundandform]

Reflecting on this more, I don't see value in enumerating every error message for this library. These error messages are largely intended for humans, not the machine. Largely, there are just two cases: success (Wasm code is cool) and fail (Wasm code is bogus). This should be easy to distinguish in the foreign language: null-pointer or not null-pointer, which can be casted to a bool in C before the interface, if necessary.

The only fined-grain compare and switch I see in our own code thus far is (result == m3Err_trapExit). If this is difficult in the foreign language, it can be achieved by using a C helper function, e.g. bool m3_IsTrapExit (M3Result result) { return result == m3Err_trapExit; }

I use C-strings for errors because I've spent a lifetime looking at useless error dialogs on stupid-crashy software. Internal Error -10298 "Yeah, thanks!" :) Software developers (aka people) are lazy and if you give them a number to work with, they'll just print the number. Giving them a string forces their hand to display something useful.

[Veykril]

Mmh, ye thats actually a good point, given its only failure or success it's really not necessary. It would probably do more harm than good in the end I agree. I'll close the PR then. 😄

[vshymanskyy]

Thanks @Veykril. The wasm3-rs is featured on the main README file.
I'm closing this, but let's continue discussion here!