Java (5 or later), 15 characters
02367?\abcdeitu
We've had a few previous answers in Java. The basic approach in all of them is to a) identify a minimal Turing-complete subset of the language, and b) find a minimal way to express the constructs of that language in Java's syntax.
Hexagraph notation
Let's look at b) first. As explained in @Poke's answer above, Java has a hexagraph syntax (analogous to C's trigraph syntax) to allow arbitrary characters that might not exist in your character set to be included in your program. For example, a newline could be written as a literal newline, but it could also be written as the hexagraph \u000a
; the hexagraph consists of \u
followed by four hexadecimal digits, specifying the character's Unicode codepoint. Unlike C's trigraphs, which can only be used for a few awkward characters, a Java hexagraph can be used for absolutely any Basic Multilingual Plane character we might happen to need (including printable ASCII characters).
The previous records, 17 by @Poke, and 16 by @Poke and me, were based on taking relatively normal-looking Java programs and simply trying to hexagraph every character in them: your character set is then based on which nybbles occur in the codepoints you're using. If a nybble occurs in two different codepoints, it typically saves character set entries to include that nybble in the character set, so you can construct the codepoint with it. One minor improvement for this entry is that if a nybble only occurs in a single codepoint, we may as well include that codepoint in our character set directly: the resulting programs will end up slightly shorter.
Of the 16 nybbles, this entry manages to omit 2 entirely: 5
, and 8
. 4
, 9
, and f
are also omitted; each is only needed to write a single character (t
= U+0074, i
= U+0069, and ?
= U+003F respectively), and including that character directly leads to shorter and "more readable" programs. One final saving is available from a
/1
: we don't need a
as a nybble to write any character, we do need to be able to produce U+0061, a
's codepoint, but we don't need 1
for any other codepoint. So a
and 1
are redundant with each other: we need at least one of them, but don't need both; and omitting a
/1
, 5
, and 8
from our base set of 18 characters \u0123456789abcdef
gives us our final character set.
Of course, this means that we have to avoid many more missing characters than in the other entries. In particular, we can no longer create the boilerplate for a main
method (which must have a parameter of type String
; S
= U+0053 contains the forbidden nybble 5
). So we're going to need a radically different way of running a Java program.
Java as an interpreter
Java is normally a compiled language; a typical workflow is to use the compiler javac
to compile your Java source files into one or more .class
files, and then the JVM java
to run those source files, and take the output of java
as the output of the program. None of your code actually runs at compile time, so the output of javac
is typically regarded as uninteresting.
Nonetheless, javac
does contain some nontrivial functionality; Java is, after all, a fairly complex language. We can take a single Boolean of output from the compiler javac
by checking to see if there are compile errors, looking at its exit code: if the program has errors, that will produce a different output from if the program doesn't have errors. Of course, Java being a compiled language, an erroring program might not seem particularly useful from a Turing-completeness point of view: if it has errors, it won't actually run, so how could it be Turing-complete? However, it turns out that type-checking Java programs is in of itself a Turing-complete operation; all we need to be able to do is to be able to compile programs from some Turing-complete language into Java's type system, in such a way that, in order to determine whether the resulting program is valid Java or not, the type-checker will have no choice but to run the program we compiled.
The Subtyping Machine
The Subtyping Machine is an esoteric programming language that was "back-derived" (by Radu Grigore in 2017) from Java's type system, looking at the algorithm that Java actually uses to determine whether an expression has the correct type or not. Here's an example I wrote of what this sort of program looks like:
interface xx {}
interface A<x> {}
interface B<x> {}
interface d<x> extends
A<s<? super X<? super B<? super s<? super X<? super d<x>>>>>>>,
B<x>, xx {}
interface X<x> extends xx {}
interface s<x> extends xx {}
class x {
d<? super X<? super d<? super X<? super d<? super X<? super s<xx>>>>>>> xc;
A<? super s<? super X<? super d<xx>>>> xd = xc;
}
The bulk of the program is basically just a lot of interfaces extending each other with contravariant generic type parameters. If you have A<x> extends B<…<? super x>>
, and you're trying to see whether an expression starting A<…>
can be stored in a variable of type B<…>
, what ends up happening is that the first type ends up getting potentially much more complicated as the generic parameter is expanded, and then the resulted B<…>
wrappers cancel, but (because the types are contravariant) the two parameters basically swap roles within the type-checking algorithm. The result is a type-checking problem that could potentially be more complex than the problem we started with; the operation effectively boils down to popping two stacks and then pushing onto one of them based on the value popped. You have to push onto the two stacks alternately, but that isn't a major issue, so we effectively end up with a two-stack machine, and two stacks are enough for Turing-completeness. Full details of how the language operates are in the link at the start of this section.
Minimizing the character set of The Subtyping Machine
Now that we have a Turing-complete operation that can be run by java
, thus avoiding the need for the public static void main(String[] a)
boilerplate that's required for the benefit of javac
(but not java
), the final step is to reduce its character set as far as possible.
There are some characters that are absolutely necessary. To use this technique, we need to be able to declare interfaces (interface … {}
) and contravariant type parameters (<? super …>
), which already ties up many of our nybbles. The main problem I encountered in this solution was in trying to avoid the nybble 8
, most notably used by (
= U+0028 and x
= U+0078. (1
/a
end up not being used for anything important, e.g. they're merged in @Poke's answer just as they are here; and 5
turns out to be used only for e
=U+0065 and u
=U+0075, but fortunately both those characters are needed for other reasons, e
as nybble and u
because it's part of the \u
hexagraph introducer, so we never need to write them as hexagraphs. Unlike in the previous record-holder, c
is unavoidable because we need it for <
=U+003c, pretty much unavoidable for any type-system-based approach.)
Avoiding parentheses is a little annoying, but not that hard; in fact, I did it in the example program above. The reason they'd be helpful is that once we declare a bunch of interfaces extending each other, we actually need to cause the type checker to type-check something; Radu Grigore's original program did this by defining a function. The approach I used above works by defining two variables and assigning one to the other, which will also force the type-checker to be involved; fortunately, neither =
=U+003d nor ;
=U+003b uses a forbidden nybble.
Avoiding x
is harder; despite being pretty rare as letters go, it's needed to spell extends
, the keyword Java normally uses to introduce a subtyping relationship. That might at first seem impossible to avoid, but we do have an alternative; when a class extends an interface, Java uses the keyword implements
instead, which despite being longer doesn't contain any problematic characters. So as long as we can divide our program into classes and interfaces, with the only hardcoded subtyping relationships being between a class and an interface, we can make the program work. (We also have to use the class
keyword, but that contains only letters we already have: interface implements
.) There are several possible approaches that work, but one simple approach is to ensure that classes and interfaces always alternate within the two types being compared; that means that at any point in time, we're always comparing a class with an interface (and because we unwrap both stacks one level at a time and the direction of a comparison is reversed with every step, we're always checking to see whether a class implements an interface rather than the other way round, which is impossible in Java).
My compiler from The Subtyping Machine to compile-time Java proves the Turing-completeness of this 15-character subset of Java by being capable of compiling to it; use the -jj
option and it'll output in this subset, rather than in more readable Java (by doing things like choosing a class
/interface
split that avoids the use of the extends
keyword – in a marginally more sophisticated way than is described above – and changing variable names to only use the letters that exist in the character set, and of course hexagraphing any character that needs to be).
I was hoping to produce a more complex example, but I've spent enough time on this as it is, so I thought I may as well post it. After all, it shaves one character off the best known character set via ridiculous means, and isn't that what this question is all about?