Interfacing Viewdata & APL

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 59

“Learning is learning not to think about operations that once needed to be thought about. We learn to make processes of deliberate thought instinctive and we learn to make automatic and instinctive processes the subject of discriminating thought.” Sir Peter Medawar.

Viewdata Systems¶

Viewdata systems provide a simple and effective means of accessing a large database of information. One or more mainframe computers contain thousands of “pages” of text. A page of information represents a string of text that will fit on a standard television screen, 24 rows by 40 normal characters or graphic symbols. The mainframe computers are linked to the user of the viewdata system by telephone via a modem to a display device. This display device may be either a standard television, VDU or microcomputer screen. The user accesses the viewdata system by dialling a local number, or if the modem is “smart”by pressing a key on the modem to dial the number, or if using a microcomputer by having the software program the modem to dial the number. The user signs on to the viewdata system by typing an identification and a password. This again may be done automatically by the software on the microcomputer, in which case the password could be checked by the software on the microcomputer. Once signed on the user may access any page directly by typing the page number or from any given page specify a number from 0 to 9 which determines the next page to be shown. Not all pages need provide the full ten choices. The definition of which pages will be connected to the current page is made by the information provider.

In fact the pages held by the mainframe computer form a network in which it would be possible to access any one of a million pages directly with only eight keystrokes, or be directed through a sequence of just six directory pages, just six keystrokes, to any particular page. It is possible to be directed “down” to pages providing more detailed information on a particular topic, but you can then be directed back “up’ by a different route from the one you came “down”.

The standard viewdata modem sends to the mainframe computer at 75 baud but receives from the mainframe computer at 1200 baud. This means that sending is fast enough to cope with the speed of the user typing the few characters needed to request the next page, but the response time required to send the thousand or so characters representing the page is small. In addition the system operates in full duplex, so that the user may request the next page even if the system is in the middle of displaying the previous page. so that to see choice 2 from the current page, choice 8 from that page and choice 3 from that page, entering 283 will immediately display the last page and omit display of the two intermediate pages.

Microcomputer/Viewdata Interface¶

The microcomputer can be programmed to act as a television with viewdata attachment, in which case it will allow the display of pages in exactly the same fashion as the television system does. But given the ability to program the microcomputer it is possible to provide additional facilities:

a) Save pages on disk.

b) Recall pages saved on disk when off line.

c) Display two pages at once.

d) Changing resolution of display.

e) Programmable baud rates.

f) Programmable user identification.

g) Interface to other packages on the micro.

h) Interface to other languages on the micro.

The last facility is of interest as it is posible to make the information contained on a page available for further processing. Currently two interfaces are available from Inner Product, one to BASIC and one to APL.

APL/Viewdata Interface¶

The interface to APL consists of a single APL function. The left argument is a numeric or character string and the right argument is a function number. The functions available are:

a) Set baud rates for send and receive.

b) Send character string to viewdata system.

c) Send character string to viewdata system and await reply.

The result is returned as a character string which may then be saved or manipulated in any way desired using APL.

Interfaces¶

The ease with which it is possible to scan the vast amount of information on a viewdata system prompted me to consider the interface between the user and the microcomputer presented by APL, systems written in APL and other microcomputer packages. This is the relevance of the quote at the start of the article, as after many years of using solely APL to implement systems, I have over the last few years been using other computer languages, systems not written in APL both on mainframe computer systems and on microcomputer systems. The consequence has been a reexamination of some assumptions and habits acquired over the years. BASIC can seriously damage your health but so can any prejudice.

Some prejudices in favour of APL were merely confirmed. For instance, many other languages either do not have a consistent syntax or are internally inconsistent or both. Inconsistent syntax means that it is not possible to deduce how statements should be phrased from what is already known about the language. For example, rather than a function producing a result which can either be displayed or can be assigned to a name or a file, some functions will display, some can only be assigned to a name and some can only write to file. It is of course possible to design APL systems with inconsistent syntax but there is less excuse. Another example that appears in many languages is the treatment of empty character strings. Many do not allow them; a character string must have at least one character in it, which can be extremely irritating if you wish to distinguish between a null response and a blank.

In other areas APL systems come off less well by comparison. One of these is in full screen interfaces. Historically, APL systems have been designed round fifteen character per second Selectric typewriters and many systems seem to be designed as if this was still the form of access. Even those that take advantage of full screen still do so in a static mode, whereas a quick look at any standard spreadsheet or word processing package confirms that a much more dynamic and responsive interface is possible.

Languages¶

The first thing most people do with APL is to write a “language” of functions appropriate to the application under development. A chisel is fine, but a table and chairs are more useful when giving a dinner party. A Swiss army knife is fun to have, especially if you find a horse with a stone in its hoof, but it’s easier to eat dinner out of bowls. APL is fine for developing such languages but already enforces constraints on the type of syntax that is possible if APL functions are used, rather than writing a syntax analyser in APL. For example: right-to-left order and a maximum of two arguments per function. A look at other languages will demonstrate that there are other possibilities. For example, spreadsheets provide a language that essentially gives a function with as many arguments as you like, up to the number of cells in the spreadsheet. Such a language represents a “non-algorithmic” method, not a sequence of steps but a sequence of states. It is quite possible to give spreadsheet solutions to problems that at first sight would seem unlikely candidates for such non-algorithmic methods. Good examples include the Tower of Hanoi problem and the eight-queens problem; see Scientific American “Computer Recreations” section, for October 1983 and January 1984. Other languages such as Smalltalk provide examples where the function depends on the “class” of its arguments, thus generalising the idea sometimes used in APL of the same function doing different things depending on the type or rank of its arguments.

Functional design¶

It is extremely difficult to forget how a problem might be solved using a particular programming language or a particular package chosen from the ones that you happen to be familiar with. Trying to sit back and design how a system will look and feel without having some part of you saying “how the hell can you achieve that effect with a Dodo Megabit Mark IV computer and the ‘Obvious’ data base language” is hard. But the means for achieving Visicalc were available a long time before the program was actually produced.

Conclusions¶

As microcomputers become more common, APLers should not remain parochially confined to the way things have always been done when communicating with APL, but should look outside APL to other languages and other systems for new ideas and methods. Crossfertilisation can produce offspring better suited to a new environment.