Previous
or Next 
Previous
or Next Written by Pete Fenelon (pete@minster.york.ac.uk)
This article originally appeared in Teletype, the magazine of the University of York Computer Society, in early 1988. Stunned at the bulk of Ada, which a few of us braver souls were teaching ourselves strictly against the wishes of the Pascal-loving Department, the concept of a language so huge and awful that it was utterly impossible to write a meaningful program, and with such bizarre constructs that nobody would want to use it, evolved. And all before Ada 9X escaped into the real world... This is fairly typical of the longer articles which used to appear in the magazine at the time. Thanks are due (alphabetically) to Steve Gallimore, Pete Hart, Chris Sampson, Graham Taylor and Gary Whitehead.
With the major defence crises of the 1980's - Oliver North, Irangate, etc., it is becoming increasingly obvious that Ada simply lacks the necessary facilities for generating truly paranoid programs. What is needed is a language which is not merely user-indifferent, but totally user-scared: in short, a Paranoid Programming Language.
Who could meet the challenge? IBM? No, too neurotic already. DEC? No, VMS was far too paranoid. It fell eventually to your humble editor and his motley crew of hackers to design, implement, debug, y'know, the LOT, the ULTIMATE programming language one cold evening on the way to Alcuin College Bar.
So, what features does PPL offer the user?
For the most part, PPL data types are comparable with those offered in conventional languages. However, a feature based closely upon the storage class specifiers of C and the various ramblings of Ada has been introduced. Typical declarations would look something like those listed below:
x : dodgy integer;
y : unreliable string;
z : inaccurate float;
a : unlikely array [x..y or_maybe z : could_be integer]
of maybe_ebcdic_or_possibly_sixbit char;
p : pointer to random location;
Compound types can also be declared as follows:
slightly_iffy structure blob =
x : hopelessly_broken list of too_small integer;
y : improbable set of overflowing string;
end blob;
It has been said that this adds a certain degree of polymorphism to the language, but the person who said it that was drunk at the time.
While PPL recognises the normal "\fC:=" method of assignment, this is recognised as being slightly conventional. The normal alternatives to this rather pedantic style of programming are:
x !:= 3
which assigns any other value but 3 to x.
x REALLY 3
which insists strongly that x is 3.
x HONESTLY 3
which forces the system to believe that x is 3.
x MIGHTBE 3
which just lets the system make its mind up, and most powerful of all,
I DON'T CARE WHAT YOU SAY ABOUT x
which doesn't really give a damn.
BEGIN and END, or their terse C equivalents { and } were discarded as modelling a co-operative, nice environment in which things went as planned. This was no good to the brave designers as PPL. Instead we went for the more prosaic approach. Blocks of code are introduced with the
GET_MOVING_YOU_XXX
statement, where XXX ranges through CRETIN through a range of increasingly obscene Albanian phrases, with increasing obscenity implying higher priority. The end of a block is marked with the
PACK_IT_IN_YOU_XXX
statement, where the same set of obscene phrases are used. The certainty with which statements are separated is purely dependent upon the number of semicolons between them... For example:
GET_MOVING_YOU_INFERNAL_DEVICE
x MIGHTBE 44;;;;;
y !:= 100;;
z REALLY 200;;;;;;;;;;
PACK_IT_IN_YOU_INFERNAL_DEVICE;
might be an example of initialisation.
Well, this is the field in which PPL really scores over all other programming languages. Whereas other languages only offer a generalised IF-THEN-ELSE or a CASE statement, PPL has a whole class of utterly novel wish-fulfilment statements. For example...
IF x WAS_EVER 100 THEN
DON'T print(x)
IF j IS_NEARLY right
DELETE ALL INCORRECT
REFERENCES TO j
UNLESS a IS "My Name" THEN
crash_unix
WHENEVER errors THEN
run_in_circles_scream_and_shout
ON_SUSPICION_OF x < 100
CORRECT ANY OTHER
REFERENCES TO x
IN_CASE y NEARLY x THEN y
REALLY x
It can be seen that the REFERENCES TO modifier is particularly useful for creating self-modifying code which is ludicrously easy to prove formally - quite simple, really, since it corrects itself!
Comments begin with the ERRRM... statement, with varying numbers of Rs and Ms implying varying degrees of certainty. They end with the OKAY??? construct. This allows total paranoia to be exercised over the source code, e.g:
z MIGHTBE "hello" ;;;;;
ERRRRMM... or perhaps not OKAY????
In the matter of control flow it is hard to find anything in the same league as PPL. For the most part this can be taken care of by the conditional statements mentioned above; however, sometimes even these prove to be far too lax in their grip on reality and a set of more general statements are employed:
REPEAT
x !:= x + RANDOMLY VARYING y;;;
UNTIL x NEARLY RIGHT
WHILE some_bits STILL wrong
GET_MOVING_YOU_FOUL_BEAST
fiddle(x);;;;;;;;
PACK_IT_IN_YOU_FOUL_BEAST;;;
INSIST UPON a IS 1;;
UNLESS void OR illegal OR broken;
There is a CASE statement in PPL but since every possible outcome, even being eaten by wild dogs whilst whilstling "Land Of Hope And Glory" has to be taken into account, it is rarely, if ever, used.
Naturally a language as rich as PPL offers a sophisticated range of reality-altering features. These are not defined by the normal PPL specification document but are left to the implementors. Typical pragmas include the following:
#distrust(procedure)
to put extra suspicion on a procedure,
#ignore(procedure)
to totally forget about any calls to a procedure,
#blame(procedure)
to pin the blame on this procedure whenever something dies
#hide(procedure)
to forget that a procedure ever existed.
Combined with a version of the Unix make command (renamed i'll probably break it but anyway let's give it a go) this enables programs to accurately reflect the state of mind of the development team at any time.
These aren't too difficult. However, as with the rest of PPL the situation is complicated by the need to tangle with the language's paranoid view of life. The syntax is as follows:
CALL procedurename;;;
CALL procedurename WITH MISSING
[parameters];;
CALL RANDOM LOCATION;;;;;
CALL procedurename REPLACING parameters
WITH others;
To return the address in memory of a procedure a statement of the form
RUN AROUND LOOKING FOR
procedurename;;;
is used. Where external procedures are needed, we use the following:
FROM
WHERE THE HELL IS procedurename
GRAB procedurename;;;
Functions are declared similarly to procedures, but since they're too anal-retentive paranoid to return anything they always cause errors. Such is life.
At present, PPL is implemented on a heavily expanded homebuilt Z80 system running under a strictly unlicensed port of Berkeley Unix 4.999999 and therefore offers the full range of interprocess communications offered by this seriously dubious operating system. These are implemented as standard library procedures, for example:
shout(processid, "Oi you!!!");;;
kill(processid, "grievous bodily harm");
File access is slightly problematic. PPL expects all files to be in the directory
/usr/spool/secret/keep.out/$USER/private/danger/secret/locked
with permissions 0000. There can be no actual access to files in programs, as file handling statements are equated to comments by the pre-processor. The exception to this is the shred library procedure which deletes all references to a file, forgets the file ever existed, does not tell the president, does not pass go and does not collect \(ps200. It has never met Oliver North, President Bush, Jeffrey Archer or Ernest Saunders and does not own a copy of Spycatcher.
It is unlikely that full PPL will ever be implemented on a micro; the compiler (well, it's more of a groveller than a real compiler, but the PPL implementation commmittttteeee insist upon calling it that) is actually over 4.3Gbytes in size - bearing in mind the fact that PPL can look into absolutely EVERY ramification of EVERY decision, e it false, incorrect, scandalous or just plain WRONG, in a program, it is felt that this is quite small. It is quite likely, owever, that cut-down versions of PPL will become available - Paranoid Systems is already working on a smaller version targetted on Sun alled MDL (Manic Depressive Language) and consists of an Ada-compatible kernel with new paranoid keywords thrown in. An even smaller version could well become available for machines in the PC class; this is likely to go by the name of SDL (Slightly Dubious Language) and be based exclusively around the concept of protecting the user's decisions, filofax and BMW in the executive environment. Its programming facilities will, in tune with the target market, be considerably limited but still pretty bloody paranoid.
I was extremely privileged to visit the labs of Paranoid Systems, where work is in progress (or so they tell me- if you count a crowd of morose black humming things by the Smiths work) on the first totally paranoid computer system. The PCS1 has been designed from the tart to run PPL; the compiler has been ported from its original Z80 incarnation and is now in late beta-test on the first prototype machine.
What makes the PCS1 so powerful? Or, indeed, so paranoid? For a start, it's a long way from a traditional Von Neumann machine. In keeping with the requirements of the language, the computer implements a sophisticated scheme of parallel processing- each processor tries to minimise the risk of any decision it is bullied into making, then checks it for consistency with all the others before it's willing to do anything at all. And even then it does it slowly.
Originally Paranoid Systems intended to use the Transputer as the processing element in the PCS1; however, after a considerable pause for thought and much real ale it, this audacious concept was rejected in favour of a strange mixture of Intersil 6100s, COSMAC 1802s and SC/MPs. These processors were chosen for their technical interest, lack of speed and total obsolescence. It was also felt that the Transputer might begin to get ideas above its station and spend too much time talking to other processors... and you know what that can lead to...
Several of the machine's design concepts stand out as unique. Interprocessor communication is, whilst being an integral part of the machine's design, normally carried out secretly by a Main Bus Arbitration (or, in PSL parlance, "Miserable Bugger, aaargh") unit. The MBA randomly steals bytes from the memory of a processor and distributes them freely to any other processors which are not too paranoid to listen. This actually forms quite a powerful means of communication, and any rumours that attempts to prove theorems about it in Communicating Sequential Processes notation can cause brain overheating are utterly false.
Few peripherals have yet to be interfaced to the PCS1 apart from the standard system console consisting of an ASR-33 teletype at 110 baud, a paper tape reader for downloading the compiler and a rectal pattern-recogniser for security checks. When an attempt to interface an IEEE-compatible toaster to the floating point co-processor was made the system merely wrote the message
"ERROR 9: FLOATING POINT UNIT REFUSES TO COMMUNICATE
WITH ANY OTHER DEVICES ON MAIN BUS. NOT MY PROBLEM"
on the console. Since this attempt a team of AI experts, psychologists and psychopaths have been trying to interface a DecWriter to the beast in a vain attempt to ask it why....
All in all the PCS1 is an interesting product which will, eventually, with much development, perhaps work. Well, slightly better than it does at the moment. Potential customers apparently include such paranoid institutions as the Cabinet Office, MI5, MI6, Special Branch and the University of York.
Censored. ;o)