Current Notes April 1987 P R O S P E R O P A S C A L Does O.S.S. Need to Worry ??? Review by Andrei Wrotniak Most of us when talking about a Pascal compiler on the ST mean, of course, the OSS Personal Pascal. I've been using it extensively for almost a year at work and at home, and I understand why it became a virtual standard for the Atari ST. The OSS Personal Pascal has quite a few bugs and some annoying features, but you can live with these. The manual itself is worth the price of the package as an easy introduction to GEM programming: the only one not referring you to the awful DRI documentation in the Atari's $300 Developer's kit. I first saw the Prospero Pascal on a friend's machine -- double clicking on the compiler icon revealed, that what was supposed to be a *.PRG program was rather a *.TTP or *.TOS-like one. The desktop filled with text writing over the nice gray background we are so accustomed to -- and that was it. I didn't like it from the very start. The reasons are simple. On the ST a PAS.PRG name suggests a GEM application which this compiler is not. This is not nitpicking. The Prospero Software people claim to be professional language specialists, and they should be able to avoid such confusion. Can you have confidence in a company which sells you an advanced product without even providing a decent user interface for it? I didn't like it. I didn't want it. So when Joe Waters asked if I'd write a review of the Prospero Pascal for the Current Notes, I said, "Yes, with pleasure, but expect me to be rather more frank than polite". Here we are, two months after, with all the good and bad impressions -- and unavoidable comparisons with the OSS Personal Pascal. I. USER INTERFACE As I have already remarked, this feature is practically nonexistent in Prospero Pascal. This is a grave marketing error, because a good user interface sells the product more effectively than expensive advertising, and a bad one can deter a potential user/buyer from taking a closer look. The easiest way to get the compiler started is to rename it to PAS.TTP and run it, entering the source file name on the TTP dialog box together with one-letter abbreviations of compiler options. The latter I always find annoying, especially when working with more than one compiler. Remembering these magic letters (A for range check, or G for log file output, etc.) may not, however, be necessary: press [RETURN] without entering anything, and the compiler will prompt you for all option settings. Writing a simple, OSS-like shell for Prospero Pascal is not difficult: mine (written, of course, in Prospero Pascal itself) ____________________________________________________________________ ST - 1 - ST Current Notes April 1987 almost works, and one day I'm going to finish it. Why didn't somebody from Prospero (knowing their GEM interface much better than I) do it? OSS supplies their own editor. Prospero recommends using any ASCII editor of your choice -- I use the STEDT (which is a version of XEMACS with keys bound in a quasi-VAX/VMS EDT fashion). It is quite good (and public domain!), easy to use, has multi-windowing -- as a matter of fact I've disconnected the OSS editor from their compiler shell and hooked in the STEDT instead. On the other hand, Prospero includes a library manager in their package -- and this is quite an advantage, especially for large projects. Ironically, here OSS recommends using the DRI librarian (and spending $300 to get it!). II. DOCUMENTATION The compiler comes with a large manual, which may serve as a Pascal reference, though most important are the descriptions of the extensions to the language standard, and of the system operation. The extensions and other implementation-specific features should, I believe, be described instead in a single section for the users familiar with standard Pascal -- to spare them the need to read the whole book. The instructions on how to run the compiler and linker are complete, but not too clear. They are in Part III of the manual, and you may be lucky enough to find them -- the initial table of contents lists only Part I. Unfortunately, the Atari-specific GEM library documentation is not included: a listing of subroutine names and parameters (without even comments) plus three pages of text (mostly referring you to sections of Developer's Kit manuals) cannot be called documentation. The procedure and parameter names correspond, luckily, to the Alcyon C ones, so if you have experience with GEM programming from other languages (even from the OSS Pascal with its own high- level routines), you may still be OK. Requiring a Pascal programmer to spend an extra $300 for a C compiler with necessary documentation does not seem reasonable. As a bare minimum you would need the Abacus and Sybex GEM reference books. By comparison, the OSS Pascal manual does not require any additional material; without wasting much space it explains not only the procedure calls, but also the basic principles of the GEM operation. A big point for OSS. With this -- quite important -- exception, the Prospero manual is good, no-nonsense and complete. III. GEM INTERFACE To complete my list of complaints, let's mention the Atari ST system calls in Prospero Pascal. ____________________________________________________________________ ST - 2 - ST Current Notes April 1987 As I've already said, the procedure and parameter names correspond to ones in Alcyon C -- a principle applied in many other compilers, as well. In this respect, Prospero Pascal is no worse than most of the language implementations for the ST, and things seem to work well, if not in the most convenient way. Luckily, with the excellent modular facilities of Prospero Pascal (see below), one may invest some time and effort into writing a library of frequently used higher-level routines. Still, I would prefer Prospero to do at least some of this work for me, as is the case in OSS Pascal. Try to check the status of a dialog button from both compilers, and you will see the difference! But the superior GEM interface in Personal Pascal is the main reason I am not moving over to Prospero. This, however, may not be a deciding factor for those of you who are already familiar with GEM calls in the Alcyon C standard, or for those who want to use the language without accessing the GEM and graphic features. Anyway, another quite important plus for OSS. IV. LANGUAGE IMPLEMENTATION This is a very good implementation of the ISO Level 0 Pascal (no dynamic arrays as parameters -- in the conformant or any other version). All features of the standard are included, and many useful extensions are provided (they may be switched off by setting a compiler option). Some of the more important are listed below: (1) LONGREAL type with about 16 decimal digits of precision (standard REAL type gives about 7 digits). For many numerical applications this is a real advantage over OSS Pascal (claiming 11 decimal digits of precision, but providing only 7 or less in standard function results). (2) OTHERWISE clause in the CASE statement (as in OSS). (3) STRING type of dynamically assigned length (only the maximum length has to be declared) up to 31767 characters -- OSS Pascal handles up to 255. (4) String-handling procedures: Length, Copy, Delete, Insert, Pos, Str (integer-to-string conversion) -- the OSS is missing only the last one. (5) Addr(x) -- returns the address of variable x (x may be also any structure, e.g. a record). (6) Move(from, to, length) -- a procedure for assignment without type checking (on a bit-by-bit basis). [Some extensions relating to program modularization will also be discussed in the next section -- read on!]. A nice set of file-handling procedures is provided, as well. Two of them deserve your special attention: (a) Append -- open an existing file ____________________________________________________________________ ST - 3 - ST Current Notes April 1987 for writing just before the end-of-file mark -- very useful! (b) RamFile -- open a work text file in RAM. One strange omission is an absence of 2-byte INTEGER type (a 4-byte length is standard here). Declaring a subtype is not quite the same thing -- for example, the parameter and function result return is still performed on the 4-byte basis. This is, however, a minor flaw, and -- generally -- Prospero Pascal here makes a slightly better impression than OSS. V. MODULAR PROGRAM STRUCTURE AND LIBRARIES The absence of independent module (or segment) compilation in the Standard Pascal is one thing which makes it practically useless for serious applications. Luckily, most implementations (with a notable exception of Turbo Pascal) include this feature as an extension to the standard, so you may compile modules separately, or -- using a library manager -- include them into libraries. And here is where Prospero Pascal shines. Not only does it allow you to compile modules (packages of procedures) separately, but also includes two extremely valuable features absent in OSS Pascal: (1) COMMON objects (not unlike these from common blocks in FORTRAN, though identified by name rather than by position). Declaring a variable (or structure) as COMMON has two important effects: (a) makes it accessible from any other module, where it was also declared as COMMON; and (b) makes it immortal -- i.e. its contents will be preserved until the program termination (so it may carry information between successive calls of the same procedure). (2) Objects global at the module level. [This feature is undocumented in the Prospero manual, but I use it without any problems -- as yet]. If a module contains more than one procedure, a variable declared at the module level (i.e.before procedures themselves, as "normal" global ones in the main program) will be accessible from all procedures in the module. Thus, it may be used to carry information from a procedure to a procedure -- without being declared as COMMON. In principle, passing the data as COMMON would do here, too, but this requires keeping track of reserved names, and the objects would not be as well protected from being modified. The feature (2) above is exactly like the one in Modula-2, and I miss it badly in the OSS Pascal. The latter allows you to declare global objects in modules, but in a clumsy way: if you use any global variable (or structure) in a module, you have to declare therein all variables from the main program. This would, of course, destroy the re-usability of modules, taking away almost all advantages of the modular approach to program construction. As noted, an additional advantage of the Prospero Pascal is the library manager, enclosed in the package. If you create a library, only the procedures your program needs will be linked to it, whereas with a non-library module they will be included as a whole, even with procedures your program does not refer to. Thus in the area of ____________________________________________________________________ ST - 4 - ST Current Notes April 1987 modularization Prospero has definite advantages over OSS. VI. PRL -- A NUISANCE OR A BETTER MOUSETRAP? Before running any of the programs in the Prospero Pascal package, or before running any program written in it, you should run PRL.PRG -- a program installing the memory-resident Prospero runtime Library. You need to do it just once (e.g. from the AUTO folder), but still -- it may be a nuisance. The only advantage of this solution might be (in addition to shorter total loading time for multiple program runs) more efficient usage of computer memory -- but only in case of more than one program residing there at the same time -- as e.g. a "regular" program plus a couple of desktop accessories (I still can't write them in Prospero Pascal, anyway). All of them would have to be written in Prospero Pascal (or Prospero Fortran, using the same runtime library), which does not happen often. On the other hand, the resulting programs are not really stand-alone applications: if you sell them, or give them away, the PRL has to go along. What? To give away (or sell!) somebody else's copyrighted software? The "PLEASE READ ME OR YOU DIE" note in my Prospero Pascal package says explicitly that the licensee (this means yours humbly) can use the proprietary material (this means the goodies) on a single computer under a non-exclusive, non-transferable license from the licensor (this means Prospero), and -- with exception of his own backups -- will not copy or permit the copying of ANY of the proprietary material (i.e. the goodies again, including the infamous PRL). More, the Software may even include -- they warn me -- a self-destruction mechanism (blowing me up, or what?). If I remember well, somebody reported talking to Prospero representatives on this subject, and they said OK, PRL is free. Was it not a misunderstanding? They have been selling their ST products for a year or more -- enough time to include at least a piece of paper with each package, explaining what is what. Wouldn't it be better than threatening me with a self-destruction mechanism? VII. THE BOTTOM LINE After a closer look, the Prospero compiler turned out to be a solid tool -- at least as my limited experience indicates -- of professional quality. Removing the PRL oddity, improving the Atari-specific documentation, and -- maybe -- adding some higher-level GEM routines would make it a very nice package, indeed. If you are looking for an ST Pascal compiler, my advice (putting aside the difference in price: OSS Pascal is two times less expensive) would depend on the kind of programming you are going to do: * For number crunching, programs not making use of GEM, and large programs (say, more than 5-10 thousand lines), where modularization and libraries ____________________________________________________________________ ST - 5 - ST Current Notes April 1987 are useful, I would recommend Prospero Pascal; * For programs accessing GEM features (including desk accessories), OSS Pascal is a much better choice. This may change: my review is based on Prospero's version 1.14mmg (and OSS v.1.11). Since last November, OSS has been promising they will issue a significant upgrade. I hope they will come out with a major improvement, if they want to keep their lion's share of the ST Pascal market. Hopefully, Prospero will not sleep, either. ____________________________________________________________________ ST - 6 - ST $300 Developer's kit. I firs