6 ms·
The example seems to be wrong https://github.com/Wilfred/remacs#porting-c-functions-to-rust-walkthrough https://github.com/Wilfred/remacs#porting-c-functions-to
by fafner 10y ago
The example seems to be wrong https://github.com/Wilfred/remacs#porting-c-functions-to-rust-walkthrough https://github.com/Wilfred/remacs#porting-c-functions-to-rus...
fn Fnumberp(object: LispObject) -> LispObject {
if lisp::SYMBOLP(object) {
unsafe {
Qt
}
} else {
Qnil
}
}
It uses SYMBOLP instead of NUMBERP. Highlighting the risk of introducing new bugs.
Which leads to the question, why Remacs can't just auto-wrap the lisp::* functions, which I assume are the Rust versions of the C Macros. If you look at Emacs' C code there are a lot of functions and macros that implement Elisp primitives in a C way. E.g., NUMBERP(x) will return 1 if x is a number or else 0. So you can use this function to deal with lisp objects in C code. The function that exports this primitive to elisp is Fnumberp. Rust has a better type system than C and supports meta-programming. So why not have a simple wrapper that can take a (LispObject) -> bool and turn it into a (LispObject) -> LispObject. Similar for other Elisp<->Rust types.
However unless GNU Emacs is willing to accept the Rust replacement code I don't think this will succeed. It is a lot of work and it takes quite some time until it actually pays off. It seems simpler to do what GCC and GDB have done and switch from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries.
And the reasoning given in the announcement are rather weak:
* "We can leverage the rapidly-growing crate ecosystem." Emacs recently added module support allowing leveraging all kinds of ecosystems
* "We can drop support legacy compilers and platforms (looking at you, MS-DOS)." how is that an opportunity when it effectively removes support for platforms.
- jdub 10y ago> However unless GNU Emacs is willing to accept the Rust replacement code I don't think this will succeed. There are many kinds of success. :-)
- i336_ 10y ago> GCC and GDB have ... switch[ed] from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries. Interesting! Where can I read more about this? Is it true that gcc compiles using g++? That's rather amusing. :) > "We can drop support legacy compilers and platforms (looking at you, MS-DOS)." > how is that an opportunity when it effectively removes support for platforms. Supporting MS-DOS is something of a challenge now. I've not done any research but I have vague notions that GCC ports aren't really being maintained anymore. Besides that, many platforms (for example BeOS) are stuck on GCC 2.95.3, a rather famous last version using a particular ABI. A lot of stuff is stuck on that GCC version. (I don't know many details, although I'm very interested to learn more if anyone else has any insight.) With the above said, I do disagree with wholesale willingness to summarily sweep legacy platforms off the table. Rust has saved itself some maintenance nightmares because it doesn't support DOS, but it means quite a large number of people are still stuck on C for industrial control system tooling. (Granted, I can't deny that I'm talking about a really tiny niche here...)
- pjmlp 10y agoYes it is true, all major C compilers are now written in C++. You can find everything related to GCC's C++ transition here: https://gcc.gnu.org/wiki/gcc-in-cxx https://gcc.gnu.org/wiki/gcc-in-cxx On Windows even the C runtime, MSVCRT.dll got re-written in C++ and the C functions are actually extern "C" ones. https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/ https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great... So a kind of small victory for us on the C++ side of the fence on the endless C vs C++ discussions. Now the joke "my compiler compiles yours" has been reversed.
- i336_ 10y agoWow, that's a surprise. I'm really considering learning C++ now... I'm just hugely put off by the long compile times :( (I have 10+ year old hardware)
- adrianN 10y agoThe compile times are not that long unless your program is very big. I also have 10 year old hardware.
- AlphaSite 10y agoIts all relative.
- pg314 10y agoI guess it depends on what you're used to. Each time I switch from C to C++, compile times take some adjusting. If you're not careful about how you organise your C++ code (be careful what you put in headers, don't go crazy with templates), compiling can get really slow, even for relatively small projects. Just #include <iostream> and the compiler needs to process 37,799(!) lines and more than a MB of data: echo '#include <iostream>' | g++ -E -x c++ - | wc 37799 104779 1280834 To contrast in C: echo '#include <stdio.h>' | gcc -E -x c - | wc 456 1638 20880 Comparing the compile times of PostgreSQL (C, minutes on an old laptop) and MySQL (C++, 30+ minutes) is also instructive. Maybe when modules are finally introduced, things will improve.