<div dir="auto">Thank you Zoltan for your clear reply, this is pretty much in line with what I thought.<div dir="auto"><br><div dir="auto">Yes, I did check the PhD-related papers on RBMM before asking. As they looked promising, I wondered whether any progress had been made ever since.</div><div dir="auto"><br><div dir="auto">Two points though: </div><div dir="auto"><br></div><div dir="auto">1. The original implementation of GNU Prolog did *not* resort to GC, this is made very clear in Diaz & al. 2010,  "On the Implementation of GNU Prolog", p. 29.   Clearly confirmed in a 2013 SO reply by Diaz. In a nutshell, they do not do dynamic heap allocation, they instead mmap all stacks in virtual memory and use swap. Stack sizes are controlled via env vars and generously set on startup. They may have been trying to fiddle with GC of late,  anyway it is not an essential part of the gprolog implementation.</div><div dir="auto"><br></div><div dir="auto">2. Another case in point is scryer-prolog, a recent implementation written mostly in Rust. Only compiles to bytecode this far, yet with no GC. </div><div dir="auto"><br></div><div dir="auto">The motivation of my question was not predominantly code safety (even though FLI via C is by design limited to unsafe Rust, a limitation that would hopefully be lifted with a Rust backend). </div><div dir="auto"><br></div><div dir="auto">It arose from my pro experiences with Rust over the past 2 years. I came to be aware of GC footprint both on RAM use and execution speed a bit more acutely than I used to be in younger years. A quick look at older Mercury benchmarks (in which GC is deactivated on command line or alternatively is not) confirms that GC footprints may be quite significant too.</div><div dir="auto"><br></div><div dir="auto">Well, I'll give it a try at scryer therefore.</div><div dir="auto"><br></div><div dir="auto">Fabrice</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><br><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">Le ven. 19 sept. 2025, 22:54, Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com">zoltan.somogyi@runbox.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Fri, 19 Sep 2025 13:49:00 +0200, Fabrice Nicol <<a href="mailto:fabrnicol@gmail.com" target="_blank" rel="noreferrer">fabrnicol@gmail.com</a>> wrote:<br>
> Is there any project around aiming at a Rust backend?<br>
<br>
No.<br>
<br>
> With its growing adoption as a memory-safe alternative to C and runtime<br>
> wonders one might be tempted to see it as a possible step forward for<br>
> Mercury integration in a number of promising projects.<br>
<br>
Generating Rust instead of C would not improve the memory-safety of the<br>
generated code, for the simple reason that it is *already* memory safe.<br>
Rust's advantage over C is that it proves memory safety, but the Mercury compiler<br>
also ensures memory safety for the code it generates, and a second proof<br>
would not help.<br>
<br>
And since Mercury and Rust ensure memory safety through approaches<br>
that are broadly similar (controlled mutability) but different in detail<br>
(gc vs the borrow checker), even supporting the ability to link Rust code<br>
into Mercury programs would not help *that* much. Such linking is already<br>
possible because both languages have interfaces to C. The Mercury/C interface<br>
is effectively limited to atomic data items (integers, floats, chars and strings),<br>
with any compound Mercury data structures being effectively opaque blobs,<br>
and any Mercury/Rust interface would also be limited in this way, due to<br>
differences in data representations for compound data in the two languages.<br>
So a direct link could improve the ergonomics, but could not really add any<br>
capability that isn't already there in an indirect link to (unsafe) Rust via C.<br>
<br>
> The elephant in the room here will be how to cleanly get rid of global heap<br>
> GC. Not a minor hurdle to jump over considering the extensive use of the<br>
> Boehm GC at runtime.<br>
<br>
"not a minor hurdle" is a vast understatement. The Mercury implementation<br>
*assumes* that the target language has gc, and changing that assumption<br>
is literally a research project. Have a look at the papers on adding region-based<br>
memory allocation to Mercury. A student spent a whole PhD on that, with<br>
significant help from us (he even came to Melbourne for some weeks), and<br>
the result was still an incomplete system: good enough for some benchmarks,<br>
but not good enough for general use.<br>
<br>
> Note that some stack-oriented Prologs like GNU do not<br>
> resort to GC<br>
<br>
The last time I checked, which I admit was many years ago, GNU Prolog<br>
did use gc.<br>
<br>
> So my<br>
> question, before giving it a try myself: is the whole endeavour doomed from<br>
> the start or is there any glimmer of hope?<br>
<br>
Sorry to be the bearer of bad tidings, but I am afraid it is doomed.<br>
<br>
Zoltan.</blockquote></div></div></div>