This answer seems to be the popular definition of "programming language". I propose that a combination of image canvases and the fx operator available in ImageMagick satisfies this definition.
The language must:
Support a representation of natural numbers and of tuples. (We're talking about languages rather than implementations, so we will leave to one side the issue of type widths).
Variables in an fx expression are floating point numbers.
An array of values can be represented by putting pixel data into a canvas. Each pixel is a 4-tuple of floating point values.
A tuple, then, would be a canvas with just one pixel. It is possible to create a canvas, put values into it in one fx expression, and then read those values in a later fx expression. This behavior cannot, however, happen within a loop.
Be able either to transform inputs into outputs (transformational model) or to distinguish an "accepted" input from a "rejected" input (decision model). Be able to take two natural numbers and add them. In the transformational model, this means transforming an input tuple of two numbers into an output which correctly represents their sum. In the decision model this means deciding whether an input contains the representation of a tuple of three natural numbers such that the third is the sum of the first two.
Inputs are in the form of an image representing an array (of zero, one, or two dimensions) of 4-tuples. Providing a list of integers is trivial. A string would be a simple matter of ASCII-to-bitmap conversion. Input can also be provided as a variable at the start of a program.
Outputs are also in that same form, or as text to stdout using the debug() operator.
The default behavior is transformational, and adding together two values is one of the simplest operations available in fx expressions. A decision model can be simulated by making the output conditionally map to one of two values.
Be able to take a natural number and say whether or not it is a prime. In the transformational model this means transforming a natural number into the representation of 0 or 1 according to whether it is a composite or a prime number. In the decision model it means accepting precisely those inputs which represent a prime.
This expression checks the primeness of 3 through 32:
mogrify -fx "x=32;while(prime=1;cand=ceil(sqrt(x));while(prime=x%cand>0?prime:0;cand=cand-1;cand>1);debug(x);debug(prime);x=x-1;x>2)" xc:
1/3 of the output:
[0,0].blue: x=32
[0,0].blue: prime=0
[0,0].blue: x=31
[0,0].blue: prime=1
[0,0].blue: x=30
[0,0].blue: prime=0
[0,0].blue: x=29
[0,0].blue: prime=1
[0,0].blue: x=28
[0,0].blue: prime=0
[0,0].blue: x=27
[0,0].blue: prime=0
[0,0].blue: x=26
[0,0].blue: prime=0
[0,0].blue: x=25
[0,0].blue: prime=0
[0,0].blue: x=24
[0,0].blue: prime=0
[0,0].blue: x=23
[0,0].blue: prime=1
[0,0].blue: x=22
[0,0].blue: prime=0
[0,0].blue: x=21
[0,0].blue: prime=0
[0,0].blue: x=20
[0,0].blue: prime=0
[0,0].blue: x=19
[0,0].blue: prime=1
[0,0].blue: x=18
[0,0].blue: prime=0
[0,0].blue: x=17
[0,0].blue: prime=1
[0,0].blue: x=16
[0,0].blue: prime=0
[0,0].blue: x=15
[0,0].blue: prime=0
[0,0].blue: x=14
[0,0].blue: prime=0
[0,0].blue: x=13
[0,0].blue: prime=1
[0,0].blue: x=12
[0,0].blue: prime=0
[0,0].blue: x=11
[0,0].blue: prime=1
[0,0].blue: x=10
[0,0].blue: prime=0
[0,0].blue: x=9
[0,0].blue: prime=0
[0,0].blue: x=8
[0,0].blue: prime=0
[0,0].blue: x=7
[0,0].blue: prime=1
[0,0].blue: x=6
[0,0].blue: prime=0
[0,0].blue: x=5
[0,0].blue: prime=1
[0,0].blue: x=4
[0,0].blue: prime=0
[0,0].blue: x=3
[0,0].blue: prime=1
This expression converts an 8-bit greyscale image such that any pixel with a prime intensity (greater than 2) becomes white and composite intensities become black:
convert -fx "x=max(intensity*255,2);prime=1;cand=ceil(sqrt(x));while(prime=x%cand>0?prime:0;cand=cand-1;cand>1);debug(x);debug(prime);prime" gradient.png out.png
Input: 
Output: 
The addition and prime testing requirements can be met without using new canvases to represent tuples. Those and many (most?) other problems can be solved solely within a single -fx expression. In that context, is display -fx foo analogous to `perl -e foo'? In the latter case, the program is just the three bytes "foo", which should apply to scoring the length of the former as well.
convert, etc.) \$\endgroup\$