Thanks. Is there any code to look at? (Couldn't easily find anything relevant on that repo…) I didn't mention it earlier, but I'm collecting a list of alternative TeX implementations[1] so if there's even (say) a dozen lines of WEB that have been converted to Rust, I'd be very eager to take a look and compare — it would be illuminating.
You can draw your own conclusions from comparing the code samples, but to point out a few obvious differences:
• What has the symbolic name “fi_or_else” in the WEB code has become the magic number “108” in the Rust code. (This is because the author of this project decided to have their Rust code start from the autogenerated C code which has already lost this symbolic information.)
• What is simply “if tracing_ifs>0” in the WEB code is 29 lines of Rust code, involving a magic offset into eqtb.
• The comments from the original are gone.
• Something like “cur_if:=subtype(p);” becomes “cur_if = (*mem.offset(p as isize)).b16.s0 as small_number;”.
I wonder how maintainable such Rust code will be. These problems are not insurmountable and the code can always be cleaned up later I guess… my point is simply that at the moment it is not idiomatic Rust code, for instance.
It's the result of automated c2rust[1] conversion. Of course it will be cleaned up. C2rust itself provides handy refactoring tools scriptable in Lua language. A lot of the code will be removed, for example image handling can be done through image-rs crate, etc.
All that's fine, and good luck to you; I wish you well.
But I guess I wasn't clear. This project is described as a TeX engine “in Rust”. Has any code been actually written in Rust—as opposed to either Rust code that wraps C code (as in the main repo), or autogenerated Rust code (as in this one you linked)—for any of the core parts (as opposed to system-dependencies like I/O or whatever) of the TeX engine?
I'm genuinely curious, and if there is any such code I'd like to read it (and compare it to the equivalent WEB code).
I completely understand that this could be done at some future date. The question is about the description of the current state of the project. The impression from a statement like “Efforts to ditch any C remnants are being made” is that the C code is only a few “remnants”, when in fact it appears to be the entire TeX engine itself.
(Also, I do not foresee any refactoring tool being able to convert, for instance, “108” into “fi_or_else”, recovering information that's already lost. The point here is that it would have been better to start with the original WEB code, not the lossy and autogenerated C code.)
[1]: https://tex.stackexchange.com/questions/507846
Edit: To answer my own question. The relevant source (corresponding to the main part of xetex.web) is here: https://github.com/crlf0710/tectonic/blob/2580c55/engine/src... I've posted a comparison of some example code first from the official xetex.web listing, and then from the “Rust” code here: https://gist.github.com/shreevatsa/627399d0150e66d211a264bc0...
You can draw your own conclusions from comparing the code samples, but to point out a few obvious differences:
• What has the symbolic name “fi_or_else” in the WEB code has become the magic number “108” in the Rust code. (This is because the author of this project decided to have their Rust code start from the autogenerated C code which has already lost this symbolic information.)
• What is simply “if tracing_ifs>0” in the WEB code is 29 lines of Rust code, involving a magic offset into eqtb.
• The comments from the original are gone.
• Something like “cur_if:=subtype(p);” becomes “cur_if = (*mem.offset(p as isize)).b16.s0 as small_number;”.
I wonder how maintainable such Rust code will be. These problems are not insurmountable and the code can always be cleaned up later I guess… my point is simply that at the moment it is not idiomatic Rust code, for instance.