31–40 of 69 posts
Rust is already doomed. The amount of literature being published about either comparisons or compatibility with C is a strong indicator C is here to stay.
You can pass closures to C as C functions in TXR Lisp, a language I created. Example: http://rosettacode.org/wiki/Window_creation#Win32.2FWin64 In this program, a translation of Microsoft's "Your First Windows Program" from MSDN, defun is used to define a WindowsProc callback. defun generates a lambda under the hood, which carries a lexical scope. The lambda is passed directly to Win32 as a callback, which is nicely…
Here is another example of callbacks at work from the TXR Lisp test suite: using the C library funtion qsort to sort a Lisp array of strings. http://www.kylheku.com/cgit/txr/tree/tests/017/qsort.tl It's done in two ways, as UTF-8 char * strings and as wchar_t * strings. What's used as the callback is the function cmp-str which is in TXR Lisp's standard library. A lambda expression could be used instead. Also tested i…
Earlier quoted context omitted.
Definitely. Technically this can also be done via static code trampolines that are mmap'd as well [1]. That approach has been used on iOS in the past to turn blocks into raw function pointers. If you have a platform that allows W+X on code (yikes!), you can do [2] as well. [1] https://github.com/plausiblelabs/plblockimp/blob/master/Sour... [2] https://www.mikeash.com/pyblog/friday-qa-2010-02-12-trampoli...
Anything that doesn't require W+X would need an entire page allocated per closure, wouldn't it?
Or if the OS doesn't support W+X allocation at all, then you can have a bunch of tightly packed pregenerated trampolines in the binary.
Rust is already doomed. The amount of literature being published about either comparisons or compatibility with C is a strong indicator C is here to stay.
If Rust is intended to replace C, wouldn't you expect lots of this sort of literature? i.e. isn't this actually a sign of its _success_?
Now call qsort with a closure.
Side point: ftw(3) is much more interesting unix API to call from some FFI layer than qsort(3). And I spent about a year pestering people from Sun with you should implement fts_open(3) and friends because it presents more sane API for FFIs for the same functionality.
Is this a neat trick or just standard operating procedure for calling C from ? As it was billed as a trick, I was expecting some sort of runtime code generation to pass the data pointer and some jump instruction to jump to the right spot and unpack the data pointer. Maybe I just overcomplicate things ;-)
It does seem quite similar to Haskell FFI code: https://github.com/bobfrank/hasqlite/blob/4e38801d969a43e88b... The "neat" factor comes from how little type wrangling and unsafe code is needed.
(Also hi, go contribute to Nixpkgs again!)
Rust is already doomed. The amount of literature being published about either comparisons or compatibility with C is a strong indicator C is here to stay.
If Rust is intended to replace C, wouldn't you expect lots of this sort of literature? i.e. isn't this actually a sign of its _success_?
This is just like the node.js craze a few years ago - people will rant on trying to justify why you should use rust and write the "rust" way before realising that what they already had worked as intended.
A true replacement for C (when one is finally developed) will remove all of these doubts and back-shadowing behaviour almost instantly (kind of like the react way of ux did)
EDIT: typo
Earlier quoted context omitted.
Here is another example of callbacks at work from the TXR Lisp test suite: using the C library funtion qsort to sort a Lisp array of strings. http://www.kylheku.com/cgit/txr/tree/tests/017/qsort.tl It's done in two ways, as UTF-8 char * strings and as wchar_t * strings. What's used as the callback is the function cmp-str which is in TXR Lisp's standard library. A lambda expression could be used instead. Also tested i…
TXR looks interesting. Is there a project README?
And big honkin' manual.
Earlier quoted context omitted.
Anything that doesn't require W+X would need an entire page allocated per closure, wouldn't it?
No, you can of course allocate W+X pages from the OS and put multiple closures in them using a standard userspace memory allocator. Or if the OS doesn't support W+X allocation at all, then you can have a bunch of tightly packed pregenerated trampolines in the binary.