As hardware innovation grinds to a halt and designers turn their attention to software, E&MM looks at a new programming language that could be more than a little useful to the computer musician.

The electronics industry is only just beginning to realise that the 'leaps-and-bounds' progress it has become used to over the last few years cannot go on indefinitely. Certainly, computer hardware will get a good deal more powerful over the next 20 years as new theories (like concurrency) become reality, but the end, as far as conventional techniques are concerned, is in sight.

The reason is that, as computing devices get both faster and smaller, the laws of nature come into play and designers find themselves up against a brick wall, and there appear to be two possible ways around this.

The first is to admit that present techniques will be inadequate for the 1990s and to pursue new ideas such as the Josephson junction (which operates at very low temperatures to increase electron mobility and hence speed) or a computer that sends signals by means of pulses of light (since photons are rather more fleet of foot than electrons). However, such research would require a budget of similar magnitude to the GNP of a small country.

The second, and seemingly more immediately viable possibility is to channel a large proportion of the research effort into the development of clever software that makes the most of the latest machines. The Japanese are already saying that while the seventies were the years of hardware innovation, the nineties will see the same advances in the area of software: the eighties are described, perhaps rather cautiously, as the years of transition. The so-called 'software crisis' has arisen because computers have been too difficult to program quickly, so that any bespoke software (made to measure for a particular task) is simply too expensive for many companies to afford. Today's technological outlook puts the emphasis on user-friendly systems designed to overcome some of these problems. Lest anyone doubt the opportunities even the humblest of micros can provide, compare the games software currently available for a machine like the Spectrum with the quality of the product available shortly after the machine came out. The immense improvement amply demonstrates what can be achieved if the incentive is sufficient. And business being what it is, that incentive is inevitably financial in nature.

Prolog

It's interesting to reflect that the best ideas are also often the simplest. A piece of software called Prolog, currently receiving a good deal of publicity, must rank as one of the simplest and yet most elegant of ideas to have emerged in recent years.

The current interest was triggered by the Japanese - a surprising move from a country not particularly noted for its computer industry despite its undoubted expertise in the field of electronics - when the so-called Fifth Generation project was announced three years ago. (For those unfamiliar with computer generations, the Fourth Generation refers to the super-micros currently being developed using 32-bit CPUs, while the Fifth Generation refers to the machines to follow.) Now, Fifth Generation computers are likely to abandon the traditional approach to computing (it's called Von Neumann architecture) in favour of a system of parallel processing: that is, doing several things at once. And amongst other things, the new computers will allow direct access using natural language, enabling users to issue commands in everyday English or, indeed, Japanese.

The field of Artificial Intelligence (AI) was investigated for the Fifth Generation project and a programming language called Prolog, much favoured in AI circles, was adopted as the one most suitable for use. Overnight, Prolog rose from almost complete obscurity to gain a considerable share of the limelight.

In fact, Prolog was first introduced in 1972, (around the time that the ubiquitous teaching language Pascal emerged) and has therefore had plenty of time in which to make its impact. The important point is that the language has a lot to offer many different fields of interest, including music, and deserves a wider exposure than that afforded by research establishments alone.

Not surprisingly, Prolog's sudden burst of popularity has been accompanied by a series of implementations on cheap home micros: there now seem to be almost as many versions of Prolog in the pipeline as there are versions of Forth, and what's more, they're reasonably priced. A copy of Prolog for the Spectrum costs just £24.95 - remarkably cheap for such a sophisticated piece of software.

Philosophy

To understand Prolog, it's important to appreciate that it's a 'descriptive' language rather than an 'algorithmic' one. Most common programming languages in use today are algorithmic - BASIC is a typical example. A BASIC program consists merely of a list of instructions that the computer executes to solve a particular problem. The list may contain jumps to other parts of the program, but in general the instructions are executed in more or less the order in which they were written. On the professional front, machine code is preferred for various reasons, particularly speed, but is in fact very similar to BASIC in that it also requires a list of instructions, albeit at a much simpler level. To produce a program, the user must still write a sequence of commands, type them into the machine and then go through the all-too-familiar process of debugging.

At this point, we can begin to see just how dim most computers really are. If a programmer expects a machine to solve a problem, he or she must tell it precisely what it should do and in what order. In fact, the programmer doesn't need a computer at all: a BASIC (or machine code) program can be executed perfectly well using no more than a pencil and paper, since the program is simply a list of steps showing how to solve the problem. All the computer does, in most cases, is to execute the code quickly. It neither knows, nor cares, what it is really achieving.

The list of commands (the program) is known as an algorithm, and hence BASIC, Fortran, Algol (which actually stands for algorithmic language), Pascal, COBOL, machine code and so on are all algorithmic languages.

Prolog, in contrast, takes the bold step of abandoning the above approach altogether. It doesn't actually require an algorithm of any sort, so that a programmer need never sit down and write a routine to tackle the problem in question. The reason for this is quite simple - Prolog does the thinking itself. All the programmer need do is tell the computer everything he or she knows (or more accurately, everything he or she wishes the computer to know) about the problem. The computer then uses Prolog to find one or more solutions consistent with what it has been told. Precisely how it achieves this need not concern the programmer particularly: that can safely be left to the machine.

Of course, life is seldom that easy, and it's generally necessary to know the workings of a Prolog system in some detail before successful programs can be written.

The information given to Prolog is held in a database that's accessed by the program as it runs. This data details the environment or 'universe' in which we wish to place our problem. For instance, if we were considering a problem in dynamics where balls were travelling over a surface and colliding with each other, our universe might be a snooker table. Alternatively, if we wanted a program to lay out the offices in a new building so as to minimise wasted space, comply with fire regulations, and ensure adequate power supplies in each room, we might define the universe as the floor space of the building. If we were considering a musical problem, the universe might be the chromatic scale, or indeed any other scale, for that matter. In such a definition, it's important to remember that Prolog will consider only the information it's given. Anything that leaves the universe (a ball that falls off the snooker table, say) will cease to exist as far as the computer is concerned, and this can lead to unexpected results. It should therefore come as no surprise to know that considerable care is sometimes necessary whenever you describe a problem.

The information you place in the database (which is actually the Prolog program itself) is a description of the problem you wish to solve. This explains the term 'descriptive language' used earlier, since the language is really just a formal way of describing a problem. The Prolog interpreter consists of a series of searching and matching routines that are employed to search the database and find a suitable solution.

Prolog is far less restrictive than an algorithmic language. When information is placed in the database, it's not always known exactly (or even roughly) what questions will be posed later on. The user might ask almost anything and the language is expected to cope. This highly flexible approach is absent in BASIC, where the programmer must have a fairly good idea of what has to be done before coding begins.

Unfortunately, nothing is quite as straightforward as we'd all ideally like. The idea of a language that can apparently think for itself and look for the correct answer to a problem sounds wonderful, but Prolog (for the time being at least) does have certain drawbacks.

First, it's rather inefficient in its use of memory. This may not seem much of a problem when the language is run on something as powerful as a minicomputer, but if it's implemented on a home micro, 64K suddenly becomes surprisingly restrictive, especially when a large part of it is taken up by ROM. The language isn't particularly fast to run, either, since a complex task can require a large number of successive searches through the database before all the required answers are found. And although new computers are appearing with 16-bit or even 32-bit architecture which makes the processor considerably more powerful than current devices and allows easy addressing and fast access to much more than 64K of memory, a somewhat limited subset of the language is all that most users can hope for at present. This is perfectly sufficient to give a taste of Prolog, however.

Symbols

In common with other AI languages, Prolog is a symbolic code rather than a numeric one. It's ideally suited to the manipulation of complicated structures (such as lists) that are necessary for many AI problems. On the other hand, Prolog is relatively poor at handling numbers, though fortunately, AI problems are rarely soluble by number crunching alone.

A typical example of an AI task is the understanding of natural language - English as it is spoken in conversation, for instance. In this case, a lot of meaning is implied, with context serving to resolve ambiguities. The human brain can generally cope with this problem quite easily, but most computers are totally baffled; after all, the days of machines like HAL are still some way off. The reason for the great interest in this problem is simply that traditional ways of communicating with a computer are poor; some people cannot or will not use a typewriter keyboard, and many more shudder at the prospect of sitting in front of a VDU for long periods. Wouldn't it all be so much easier if we could talk to a computer and if it in turn could 'tell' us the answers? Decoding of the spoken word is difficult, but can still be performed - even today - with some measure of success. However, decomposing sentences in order to extract their precise meaning is a very tricky task, because as any journalist will tell you, there are all manner of different ways of saying the same thing. However, the problem can be resolved down to the manipulation of symbols (letters or words) and is well suited to Prolog. In contrast, such a task in BASIC would be rather frightening, to put it mildly.

Applications

So, to come to the really important question, what impact is Prolog likely to have for the computer musician?

Well, if a system can be developed to analyse notation in English, it should equally well be able to deal with musical notation, since the latter is also symbolic and concerned with lists of things.

Next, the analysis of a score could be performed to assist with the interpretation of a difficult piece. This could include various facilities such as pinpointing the introduction of themes (a base of pattern recognition if ever there was one) or, for the more technically minded, a frequency scan to delineate the harmonic structure of a piece. Mozart, with his penchant for strings, produced music with a high-frequency component significantly greater than average, so perhaps other composers have unwittingly left a musical 'fingerprint' behind in their orchestrations to identify themselves. Prolog would tell us who they are and what they've done.

Automatic composition is a slightly more obvious application. It would certainly be interesting to produce a system that could hold samples of a composer's work in its database and then produce music in a similar style.

Unfortunately, none of the above examples could be achieved in real time, since Prolog is far too slow at present, but the results could always be saved (to disk, tape or RAM) and inspected later at leisure.

The suggestions I've made are somewhat tentative, I admit. However, some are being actively considered as you read this, even if others may as yet be a little out of reach. All I can say is that it's unfortunate that no implementation of Prolog currently available can drive a micro's sound generators, meaning that the language cannot actually produce any audible results.

Still, the version of Prolog for the Spectrum can be highly recommended, since it includes a fairly substantial paperback book explaining the language in detail. For anyone seeking further information, the standard textbook on the subject is Programming in Prolog by Clocksin and Mellish, published by Springer-Verlag. It's occasionally heavy going but covers the language in great detail with plenty of explanatory examples.