I'm paying infrastructure costs for our little art community, chatbot crawling our servers and ignoring robots.txt, mining the work of our users so it can make copies, and being told that I don't get because this is such a paradigm shift, is pretty great..
Possibly this is why it wasn't mentioned? There are enough differences in that list that I can't imagine any existing C library would compile unchanged.
After using cc<< for non-trivial programs, it's about as quirky as the Plan 9 C compiler, the lack of multi-dimensional arrays is the one thing that trips me up the most with cc<<
Lol I feel the similar, I signed an earlier version when the Manifesto was far different but since they've changed it from that I now want my name removed >:(
One of the creators is Alex (former Google Chrome Project Lead ~ https://komoroske.com/) and we spoke on a Google meet call recently. He's currently trying to hype up confidential computing which is a cool technical challenge but I have my doubts in regards to confidential compute being super feasible/realistic. I suspect crackers/hackers will always find a way in
For sure, here are the registers used for each fraction:
comp h^2 > comp H^2
comp h c > done H
comp > done c^2
done H^2 > done h^3
done H > comp
done > comp
Accumulator: comp h^8
The first two does the comparison for odd/even, the h register is moved to the H register during the comparison, then done does H += H>>2, and then keep trying.
Do you happen to know what the smallest/first (by some measure) Fractran program is of which it is unknown whether it halts or not? Or even undecidable?
I don't, sorry. I have played with rewriting systems a lot, but not within the lens of computability. One thing that I've noticed where that some rules can be inferred to be exhaustive(an exhaustive rule can be applied without searching for another rule for as long as the rule can be applied), and that a program where all the rules have less tokens on the right side than on the left side are not turing complete.
Conway's Fractran traditionally compares the accumulator against reduced fractions, but computationally-speaking, getting to the gcd of a fraction does little more than getting rid of otherwise valuable information used during comparison to match against a restricted set of fractions. The support for catalysts, symbols found on both sides of a rewrite rule, makes for a simpler and faster implementation.
15/6 red [green] > blue [green]
5/2 red > blue
red green
These two fractions are not equal and reducing the first into the second, eliminates the capability to match against it only when the catalyst green is present in the accumulator.
I see, so you are using a different model for computation that does not use rational numbers, but instead pairs of integers. From a computational point of view, that makes a lot of sense, disallowing catalysts is quite annoying, but I would not call this Fractran, instead I would call it something like a prioritized chemical reaction network or something like this. The wikipedia article explicitly states:
> The same variable cannot be both decremented and incremented in a single instruction (otherwise the fraction representing that instruction would not be in its lowest terms). Therefore each FRACTRAN instruction consumes variables as it tests them.
I've seen this variance used a lot in the code golfing challenges I participate in, I feel like if I called it something other than Fractran, it wouldn't be long before someone points out that this is quite like fractran and I ough to call that
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.
Forth 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).
It'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.
reply