return args().skip(1).next().unwrap().length();
(-> (args)
(skip 1)
(next)
(unwrap)
(length))
This isn't really related to the Lisp to Rust transpiling thing though.
You could use slightly different syntax, such as (foo x) versus (.foo x).
Scheme48 was based on itself as a bootstrap language, with the restriction that only those closures that could be stack allocated were allowed. This restricted Scheme the implementors called Prescheme and it was pretty readable.
Indeed ZF relies on stack allocation, but this is done "optimistically" and for all code.
I'm just wondering...with modern CPUs, isn't this just a version of subroutine threading [1] that doesn't take advantage of modern pipelined CPU hardware and also blows up instruction caches? Why not go for subroutine threading?
[1] https://en.wikipedia.org/wiki/Threaded_code#Subroutine_threa...
There's no need to write things like this in the current decade. LuaJIT has been able to provide comparable performance to the implementation language, in important cases, since 2.0.
It achieves this with a very different philosophy to what's being proposed here, one which in fact requires considerable assembler for each instruction set.
It's certainly not the only way to get the job done, other comments have pointed to the various ways Scheme has tackled this problem.
What isn't the case is that implementing a runtime for an interpreted language in a 'systems language' requires that code written in the interpreted language be slower than comparable code in the systems language, let alone that a "very large difference in performance" is inherent to the approach.
Edit: perhaps this is about missing the word "primarily", that performance in such an implementation is bound by interpretation speed.
These are the two requirements of the sentence I quoted.
There's no need for the Zero Feet proposal to say something untrue to justify their approach. I'm not imputing malice because I see none, but moderating that sentence or just removing it would strengthen their case.
[1] https://dotat.at/@/2007-04-16-awash-in-a-c-of-objects.html
Putting aside the considerable differences between Pascal/Modula/Oberon era languages and those of today, the primary purpose of any compiler has not changed: it is to read a source language, analyze it and produce executable machine code.