CURRENT NOTES SEPTEMBER 1987 T R U E B A S I C ? W H A T ? A N O T H E R B A S I C F O R T H E A T A R I S T? (And a very, very good one, too) Review by Andrzej Wrotniak Look, what is going on: everybody seems to be writing BASIC for our computer! After the original ST BASIC, we've had LDW BASIC, Fast BASIC/M, Fast ST BASIC, SoftWorks BASIC, GFA BASIC, and some others do we need yet another implementation? Yes, I think we do. This one. Here is why. THE BASIC FAMILY TREE Advocates of the structured approach to programming compare BASIC to the Communist system: you may try to "improve", or "reform" it, but it will always remain a kludge. In 1975, Edsger Dijkstra (co-author of Algol and a big name in computer languages) wrote: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as po tential programmers they are mentally mutilated beyond hope of regeneration". At least some things can be said in BASIC's defense: it can be implemented on machines with very small amounts of memory (remember the times of 8K number crunchers?) and it is easy to learn. Now, times are changing. Memory is cheap and simple does not have to mean primitive or harmful (would you mutilate your child mentally "beyond hope of regeneration"?). Since 1964 (when BASIC was first introduced), many new dialects have been introduced. More recently, a number have claimed to be "structured". These claims are usually exaggerated (like "glasnost"): the implementors throw in a couple of new language constructs, as IF...THEN...ENDIF, or WHILE...WEND, and announce a programming revolution to the world. Structured syntax alone does not make a structured programming language, which needs also a well-designed procedure/function formalism (local variables, passing information via parameters), and preferably the concept of modules (as in Modula-2 and Ada). These features allow us to build our own libraries of subroutines, ST - 1 - ST CURRENT NOTES SEPTEMBER 1987 which later may be accessed from any program as "black boxes". Do you need to know how the LOG function (or a CD player) works inside? As long as it returns the logarithm of its positive argument (or the music), it does its job and that's all you care. All right, but can we eat our cake and still have it? Can we allow for democracy and still have a one-party, centrally-planned state? Can we have a really structured BASIC and still be able to learn it in two hours? Enter TRUE BASIC. TRUE BASIC STANDARD Do you think that listening to opinions like Dr.Dijkstra's is fun? Twenty years after inventing the original BASIC its authors, Messrs. Kemeny and Kurtz, rolled up their sleeves and went back to the drawing board. In 1985 the standard of True BASIC (registered trademark of True BASIC Inc.) was published, and in 1987 we have implementations for the IBM PC, Apple MacIntosh, Commodore Amiga and, now, the Atari ST. Yes, the code is portable between all these machines (including sound and graphics), and more: True BASIC claims to be compatible with the proposed ANSII standard (Dr.Kurtz was the chairman of the ANSII committee). And the standard itself is very, very good. It sets not only general syntax, but also graphic commands, standard libraries, modular features and last but not least the programming environment (with extensions possible for particular machines). Let me give you a guided tour. SYNTAX AND STANDARD FUNCTIONS Most recent BASIC dialects have a decent set of control structures. Still, True BASIC looks here as good as (or better then) anything else. The IF construct has the advanced form: IF.. THEN.. ELSEIF.. ELSE.. END IF. The DO... LOOP may have a WHILE clause on the top, or UNTIL at the bottom (or none, or both), and EXIT DO may be used for jumping out of the DO scope. There is a SELECT CASE statement (like CASE in Pascal), and of course a regular FOR loop (with EXIT FOR for jumping out). Efficient, readable and consistent control structures: Pascal and Modula-2 could borrow some. The GOTO statement may be used only when the program is written using line (optional, not recommended and included only for compatibility with old BASIC code). Arrays can be easily re-dimensioned and manipulated; there is a whole family of powerful if you need them matrix and vector handling statements. Standard functions: you'll find all you would expect and then some. Among those: Round(x,n) round x to n decimal places, Eps(x) the largest value negligible when compared with x (more useful than it may seem!). Time, Date and about 50 others. ST - 2 - ST CURRENT NOTES SEPTEMBER 1987 String handling is good, too. In addition to a comprehensive set of string functions, there are sub-strings, which may be used on both sides of an assignment (much like in Sinclair Basic or VAX/VMS FORTRAN). GRAPHICS AND SOUND True BASIC was designed as a machine independent standard and as such cannot make any explicit use of GEM VDI. GEM AES features (standard GEM windows, menus, alerts and dialog boxes) also could not be included (see below for more on this subject). Most users will not miss those, as True BASIC includes a good number of well-designed graphic primitives for plotting points, lines, boxes, or ellipses, filling them, setting up colors etc. Graphic operations take place in windows; if you do not care about windowing, the better: a default full-screen window will be opened for you. Coordinates are resolution-independent; you may, for example, specify that your window ranges from -100 to 100 and from 0.5 to 1, and then refer to all the coordinates in these terms. In other words, you do not have to recompute everything from the coordinate system in which your problem is stated to the screen pixel coordinates; this work is done by the system. Another feature quite unique is a PICTURE, a kind of graphic subroutine. Thus, the code between a PICTURE header (with name and optional parameters) and END PICTURE defines an object to be drawn. Actual drawing takes place during the picture invocation: DRAW PICTURE with name and parameter values. But wait, only now we get to the real fun: the invocation may be supplied with one or more clauses, defining change in scale, position shift, rotation or slant. This is a very powerful tool and easier to use than to write about. A necessary degree of mouse control and tracking is provided, as well (checking the position and button status). The sound control is only rudimentary (for the sake of portability, among others), but very easy. The PLAY comand takes a string, specifying the notes (and their values), as e.g. "B2EGB4". Alternatively, with use of the SOUND command, the frequency and length of the sound can be explicitly specified. The sound can be played while other instructions are being executed. FUNCTIONS, SUBROUTINES, MODULES As I've stated above, syntax does not alone make a good language. In painless design, coding and maintenance of large programs, modular structure is what makes the difference. True BASIC allows for writing user-defined functions and procedures. And by this I mean real ones, not a poor substitute frequently met in many "street BASICs" (to use the derogatory terminology of Messrs. Kurtz and Kemeny). ST - 3 - ST CURRENT NOTES SEPTEMBER 1987 External procedures and functions are introduced, placed below the program's END directive or even in separate files, so that they constitute independent entities and can be invoked from different programs. Their local variables cannot be accessed from outside; all information is passed to a function, or to and from a procedure, via its parameters, which can be simple variables or arrays. If necessary, variables in non-external subroutines or functions can be also isolated from outside by declaring them as LOCAL. Procedures and functions may be kept separately in (source or compiled) library files. And now I'm getting close to the beef: modules. Briefly, a module is a set of subroutines and functions (plus initialization code, which will be executed just once). Some of them may be hidden from the outer world. Similarly with variables: some of them may be hidden inside individual procedures or functions, same shared between them, and some explicitly made accessible to the other modules. You are in full control. You may not need this feature. Not now. But sooner or later almost everybody who programs will. Modular structure makes a difference between hacking and programming. TRUE BASIC ENVIRONMENT True BASIC is something between an interpreted and compiled language. Invoking the RUN command will cause a quick translation of your source program into some kind of intermediate code, which only then will be executed. Syntax errors are detected at the translation stage. This way the user has the ease of interactive editing, running and debugging, but also the speed of a compiled language. Files can be also compiled separately and stored in compiled form, but this does NOT result in executable standalone programs (as in case of Pascal or C). The system uses three windows: edit, command and output. Mercifully, the windows are designed much better than in ST BASIC, thus being a help, rather than a hindrance. The GEM-based editor is slow, but convenient to use. You may use the mouse, but only if you wish: every option is accessible from the keyboard. For typing in longer programs any ASCII editor may also be used. The system commands are also dual: menuand keyboard-driven. In addition to on-line help, a couple of powerful extensions were added here. First, SCRIPT files. Enter SCRIPT-filename and the file will be interpreted as a series of True BASIC system commands. Second, DO files. These (written themselves in True BASIC) take your current program file as input and do to it whatever you've requested. In other words, your BASIC system may be to some extent customized (carefully!) by yourself. Some DO files are included for adding and removing line numbers and for line re-numbering. Another one does program reformatting: indentation, capitalization of keywords etc. The source code is ST - 4 - ST CURRENT NOTES SEPTEMBER 1987 supplied, as well, so you may (carefully, again!) customize them to your liking. The sky is the limit. ST IMPLEMENTATION The True BASIC for the ST comes on a single one-sided diskette. It contains, in addition to the BASIC compiler/editor itself, a folder with DO files, another with HELP files (you may add anything there, undocumented but works!), a folder of example programs, and yet another one with some extra True BASIC libraries. The libraries are no big deal, as with the excellent modular features of True BASIC you will be able to create your own libraries easily. On the other hand, the libraries are (with one exception) in the source form, so that they may be used for learning the ropes. One library, however, deserves special attention. It contains the ST-specific, low-level bindings to VDI, AES, DOS, BIOS and XBIOS all the raw and unharnessed power of the ST. These are provided with use of the Chinese restaurant approach: calling by numbers (Combination number four, please...), after previously setting up appropriate global arrays. Nine different PEEK and POKE routines are supplied to make it feasible. This approach was used in the original ST Basic; many of the published examples should even work here. Still, using GEM from True BASIC is a pain. Luckily, for most uses you will not need it, as you may do graphics without any explicit reference to GEM. The situation can be, however, easily remedied. For each particular GEM use you only need to POKE your way through once, enclosing the resulting spaghetti (or lo mein) code into a high-level library procedure. On the other hand True BASIC, Inc. is selling "The Developer's Toolkit" a library of highlevel GEM VDI and AES procedures for GEM windows, menus, alerts, etc. My friendly Atari dealer does not have it yet, but let us hope. DOCUMENTATION The documentation consists of two readable and well-arranged volumes: a True BASIC Reference Manual (published by Addison-Wesley in 1985 and machine-independent) and the True BASIC Atari ST Guide, fresh from the oven. Together more than 400 pages of well-written text, although the former noticeably better than the latter. The ST Guide contains, in addition to the Atari-specific information, the updates to the language standard first of all the concept of a module, which seems to be an addition to the original True BASIC (and a very welcome one). It would be nicer to have all machine-independent information in one volume, and only Atari-oriented one in the other, but let us not be too picky. ST - 5 - ST CURRENT NOTES SEPTEMBER 1987 PERFORMANCE I've played with the Atari True BASIC for just five evenings now, having written in it a part of a statistical library package with some graphic utilities. All things seem to work as documented (with a single exception: the STARTUP.TRU file is not automatically executed upon entering True BASIC, but this is a very minor flaw). This is a vast improvement from the times of "great compilers with not too many bugs". Still, I need a month or two more to be more convinced. In the case of BASIC, compiled or not, I wouldn't pay much attention to the program execution speed (unless it is really slow). Nevertheless, I ran a simple benchmark to compare the True BASIC, GFA BASIC, and ST BASIC: * Evaluating of EXP(SIN(SQR(x))) with x ranging from 1 to 200 (in radians): ST 0.93 sec, GFA 0.60 sec, True 2.40 sec; * Primitive bubble sort of these 200 numbers: ST 103 sec(!), GFA 17.4 sec, True 11.4 sec. The relatively slower performance of True BASIC math libraries may be, partly at least, justified by the 14-digit number storage accuracy, as compared with 11-digit accuracy in the case of the two other BASICs (incidentally, the fine performance of the interpreted ST BASIC in case of built-in functions is nothing strange: they are binary code, anyway). Too Good a BASIC To Be True? Let's face it. This is the first BASIC I am recommending to my friends (the CN readers included). It lists for $100, and sells much cheaper: my dealer sells it for considerably less. The language standard is excellent, documentation very good, seems to work flawlessly too good to be true; so where is the hitch? Price. True BASIC itself is not expensive. But in order to create stand-alone programs (which anybody could run directly from the desktop) you'll have to buy the real compiler/linker (which lists separately for another $100 and does not yet seem available). The GEM library lists for an extra $50, so the total expense at list price would be $250. This still may not be too much for something well-designed and working nicely but beware! The True BASIC standalone compiler comes only with a noncommercial license agreement. You will not be able to sell your programs without paying True BASIC, Inc. their share. If this does not deter you, then there is nothing to think about: go out and buy it. But don't forget to turn off the stove. ST - 6 - ST implemented on m