Quantum Fortran
This page is a summary of the results of discussions in how
we might set about developing a Fortran programming language
for quantum computers.
These discussions were started in
a group of the LinkedIn website.
Booleans
Boolean expressions are easy to imagine in Quantum Fortran.
Instead of Alice=.TRUE. and Bob=.FALSE., we would have Alice=0.76 and Bob=0.24.
All booleans would then be handled as probabilities. Thus:
- Charlie=(Alice).AND.(Bob)
- would be implemented as Charlie=Alice*Bob
- Diana=.NOT.(Charlie)
- would be implemented as Diana=1-Charlie
- Eve=(Alice).OR.(Bob)
- by a bit of De Morgan, would be implemented as Eve=1-(1-Alice)*(1-Bob)
Where we have to start thinking about what is going on
is when we come to use those booleans in conditional statements, and conditional branches.
IF Charlie THEN call Fred(X,Y,Z) ELSE call Gertrude(P,Q)
There is a simple way to push this problem away, and into the inside of the procedures:
call Fred(charlie, X,Y,Z)
call Gertrude(.NOT.charlie, P,Q)
Entanglement
We could imagine stating something like:
entangled( Alice, .NOT.(Bob) )
When we next look at the values of Charlie and Eve
they are exactly 0.0 and 1.0, respectively.
Nature of the language
To embark on this, we could expect to go back to the roots of the language,
and let concepts from later versions slip in as appropriate
(already the IF THEN ELSE statement deviates from Fortran II).
But, we need to bear in mind
that Fortran was invented to act as a bridge
between the human mind and the von Neumann hardware of the time,
so this bridge might need a bit of adapting.
NIMD has been mentioned, as has DAP-Fortran,
which was written for the ICL DAP machine, which was a SIMD machine.
The phrase "when we next look at the values of"
in the section on handling entanglement
has started to assume
a functional programming flavour to the language
(hence, also, the insistence on using the IF THEN ELSE construct).
It has indeed been noted that other groups, too,
have already started to explore this route,
including Bob Coecke and Samson Abramsky
at ComLab
and others at nLab;
and the publication of
Thorsten Altenkirch and Alexander Green (2010), "The quantum IO monad",
in Semantic Techniques in Quantum Computation.
However, there are times when a distinctly non-functional-programming type of activity
needs to be triggered in the hardware, more like a procedure call in Fortran
(and hence the inclusion of Call Fred and Call Gertrude
in the example on handling booleans).
In particular, Fortran's call-by-reference mechanism made it notorious for it own
programming language equivalent of spooky action at a distance.
Certainly, the language will need to handle information that flows backwards through functions,
retrospectively changing the inputs.
At some point, too, the behaviour of the Xeno effect will need to be handled,
but this necessarily needs to be integrated with the way that parallel operation is handled
(since it depends on an interrupt signal to terminate the evaluation of a procedure or function).
Ackowledgements
To be written, once permission is given by the people concerned.
|