4 ms·
A lot of languages(including forth) maps really poorly to LC. Read some of the Forth writing on portability at all costs: http://www.ultratechnology.com/antian
by entaloneralie 1y ago
A lot of languages(including forth) maps really poorly to LC. Read some of the Forth writing on portability at all costs:
http://www.ultratechnology.com/antiansi.htm http://www.ultratechnology.com/antiansi.htm
- tromp 1y agoSimple pure concatenative languages map quite well though [1]. [1] https://github.com/tromp/AIT/blob/master/ait/mlatu.lam https://github.com/tromp/AIT/blob/master/ait/mlatu.lam
- entaloneralie 1y agoJoy, right? Not Forth. Conversion between spagetti stacks and pure stack programming(in which the stack contains numbers and no GC) has a massive translation cost if you go from LC to Forth and back.
- js8 1y agoForth is an imperative language and as such you will have to model memory state (at least) somehow, if you want to use purely functional language as a representation. But that's the cost of doing business. The thing is though, you don't translate to LC for performance, but for understanding. At any point, the LC evaluator might recognize a known subterm and replace it with a known equivalent. Depending on the goal, that might help to improve evaluation performance (skip known steps of beta reduction), reduce memory consumption (reduce size of the term), or improve readability (refactor code to use better known abstractions).
- skybrian 1y agoIt's difficult to understand what they were actually doing, but reading between the lines, it sounds like an advantage of 'machine Forth' is writing some Forth words in assembly? I can see why that would run much faster for a jpeg decoder.