| Maybe so, but that completely gives the lie to the idea that two languages are equipotent if they're both Turing complete. The sorts of abstractions you'd need to implement go far beyond what's required for Turing completeness Unlambda, for instance, is Turing complete, and moreover, it can do I/O. An Unlambda program is nevertheless incapable of opening files or doing different things depending on its command-line arguments. You can write cat (the version of cat that just echoes stdin to stdout) in Unlambda, but not ls. You might be able to write an Unlambda-based operating system in which all the various sorts of input events that an OS needs to respond to are represented as elements in its input stream (or, even better, an OS in Lazy-K). But when you've got that OS up and running, Unlambda programs running on it still won't be able to open files. (Frankly I'd be surprised if the "abstractions" necessary to get something like that up and running weren't essentially an interpreter written in another language dealing with the encoding and decoding of input and output to your Unlambda/Lazy-K program, rather than abstractions written in Unlambda/Lazy-K. (Consider that the numbers that Lazy-K outputs are church encoded and must be converted by the Lazy-K interpreter into C-like integers before characters can be output to stdout.) This isn't really important, though.) Consider also this final note from the Lazy-K page: "Remove output entirely. You still have a Turing-complete language this way, and it is if anything more elegant. But, as with the equally elegant SMETANA, you can't do anything with it except stare at it in admiration, and the novelty of that wears off after a few minutes." That's not really true, of course: there are other things you can do, like increase the temperature of your processor. Not many other things, though. |
This says nothing about practicality, but nobody ever said it did. Of course practicality is important, but a conversation about Turing completeness is a conversation about "can compute", not "can easily compute". If you look at venues such as POPL, ESOP, and PLDI, fairly often you will find proofs for some abstract representation that is then implemented in a real world language. Thus while it would be impractical to compute something in the abstract form, it is often more elegant for proof construction, and then proof results are transferable if you can demonstrate bisimulation between the two forms. All this to say that "can compute" is nevertheless an important determination with respect to equipotency.
If you had an Unlambda OS (or VM is better perhaps), then anything running on it would be an Unlambda program, including C programs, just as anything running on an x86 machine is an x86 program.