Interested in joining forces?

[ngortheone]

Hi @cherryman @shymega @Javyre

I have an interesting idea/proposition for you.

I am author of https://github.com/org-rs/org-rs
(also check out my reddit post)

The long standing goal of my project is to make org-mode available to non-emacs users.

While I am working on a parser rewrite in pure rust, it is only a small part of org-mode itself. There are thousands of lines of elisp code that will also need to be ported outside of emacs. Rewriting it all may take ages, unless a smarter approach is taken.

Since version 2.2 Guile claims to have 100% compatibility with elisp and this opens a unique opportunity of running unmodified elisp code outside of emacs.

I badly need a project like yours to make this possible.
Will you be interested in continuing work on giule-rs and/or joining forces with org-rs organization?
We already have a couple of members and I am recruiting like-minded people.

Here are some examples of goals for guile-rs

• calling guile from rust and vice versa: emacs primitive funcitons,like cursor movements, text search etc will be implemented in rust, but have to be called from guile
• compiling rust statically linked with guile library - to be able to distribute the packaged code.

You are also welcome to take participation in org-rs directly, if you are interested. Let me know what you think!

[Javyre]

It's been a while since I have put any work into this project.
But from what I remember, the main issue is that the guile api is (in very GNU fashion) written mixing the use of tons of CPP macrcos with normal function calls interchangeably.

An example of this is the scm_is_false "function". Documented as a function, implemented as a macro.

Here is how we wrap them in guile-rs:

#define gen_macro_proxy(r, n, t) \
    r gu_##n (t x) {             \
        return n(x);             \
}
gen_macro_proxy(bool, scm_is_false, SCM);

One problem with this is that there is no explicit guarantee that the functions will remain functions in the future or that macros with remain macros.
Also, the way we wrap them is either by the above method, or by reimplementing them in rust which is not the aim of the project. We want to wrap, not reimplement.

The use of the above method of wrapping these means that guile-rs requires the c compiler in order to compile.

I don't mean to sound discourag(ed/ing) but reading this article recently, it looks like guile-rs has many similarities with the wlroots-rs project. Not exactly the same problems, but it shows that its worth considering just having some c code in your project that interfaces with guile and exposes a more predictable and specialized api for your exact use that you then use from rust.

If we decide to continue work on the guile-rs project in the future, I'd be more than happy to collaborate with your projects needs, but we are reconsidering our approach and our priorities in terms of projects were working on.

[ngortheone]

@Javyre
Thanks for the info.
One more question - can you compare your project to https://github.com/ysimonson/guile-sys?
It seems like it takes a different approach. I'd be very much interested in your comment.

[Javyre]

guile-sys is basically the same as guile-rs-sys minus the manual patching of macros to functions in the wrapper.c (guile-sys just doesn't do it. Seems to simply include the guile header and calls it a day).

guile-rs aimed to be a high level rusty wrapper more than just the binding generated in guile(-rs)-sys.

[shymega]

Most of what I said here applies to this issue as well.

However, to comment on what @Javyre said about C bindings, I agree - it is rather messy with Guile, and whilst its not impossible to combine Guile and Rust together, I do have some reservations on the complexity, and how to minimise that.

Additionally, guile-sys's approach of using build.rs is something I feel our project should utilise..

[shymega]

Hey all! I've recently been going through my GitHub - I think guile-rs is worth going back to, for me at least. I'm sorry for letting it go so quiet, I've had so much going on, and maybe with lockdown going on now, I'll have more time. For now anyway, I am waiting to hear back about an apprenticeship, but no idea when that will be.

I have created a GitHub organisation for the purposes of creating a single unified repository for merging Guile and Rust.

I see the benefit of having this organisation as a common ground to develop Rust bindings to Guile, and also to have a single representation and unification of the Guile and Rust attempts.

What do you think? Ping me if you want to be added, and I'll do it ASAP. Looking forward to it.

I'm mentioning @ChristopherDumas here, as we had discussed guile-rs over email.