dlbaer@helm.UUCP (Dennis L. Baer) (05/03/87)
This is being posted in this group in the assumption that this group is gatewayed to the arpanet in which the ibm digest is also part of the arpanet. Russ Nelson in a letter dated April 21, 1987 said some things about SPL that were uncomplementary. He complained that SPL was a pre- processor. SPL is not a preprocessor because the Structured Programming Language does not resemble BASIC in its format or in its philosophy. A preprocessor is a program that processes a program that is a superset of a language or target and then produces that target or language. A translator is a processor that translates one language to another. The source language is SPL and the object language is BASIC how can one explain this more plainly? If Mr. Nelson had read the press release more carefully, like in the first paragraph, he would have known that the Structured Programming Language is implemented as a translator. This has advantages. BASIC is portable to many machines that have BASIC compilers. Beleieve it or not but Compiled BASIC is faster than Turbo PASCAL in many instances. The SPL processor creates an uncomplicated BASIC program that can be compiled on many more BASIC compilers than if a person wrote his/her initial program in Quick BASIC or Turbo BASIC, or True BASIC. Besides it allows owners of all these compilers to compile translated SPL programs. As I said that even BASIC compilers on MACINTOSH, AMIGA, ATARI ST, and CP/M can take translated SPL programs and compile them. Try writing structured code in QuickBASIC, Turbo BASIC, and True BASIC and porting them to CP/M, or other machines even as the TI 99/4? SPL cooperates with many BASIC compilers. The nice thing about translating to BASIC is that you can patch the resulting BASIC program and link it with others or combine the source codes before compiling. SPL has better I/O, STRING handling, FOR loops, IF THEN ELSE constructs than PASCAL and you have variable declarations that you don't have in Quick BASIC or Turbo BASIC but then again I am recommending that a person buy Quick BASIC to cooperate with SPL. Your old BASIC programs do not become obsolete when you work with SPL. If you used PASCAL you would have to have your BASIC programs retranslated. With SPL you do not. Since SPL translates to BASIC, SPL programs can become 640k with either the use of Quick BASIC, in its linked compiled BASIC programs or with Turbo BASIC which allows an individual module that can be greater than 64k. PASCAL limits you to 64k program and 64k data. So you may not like the idea of SPL being translated to BASIC, Mr. Russell but others will find it interesting, advantageous, and flexible, especailly there are translators that convert BASIC to C, and BASIC to FORTRAN. SPL has many potential target languages. SPL creates an uncomplicated BASIC program. Try it for yourself. Mr. Russell complains even though as shareware HE DID NOT HAVE TO PAY ONE RED CENT FOR THE SOFTWARE. All he lost was some TIME. I have found that some people hate SPL but a lot of others DO LIKE IT VERY MUCH. I thank the net and the digest for letting me defend my software. All the information in the press release was factual and NOT HYPE! I look forward to hearing from those who require software support for SPL and from those who use it and want to tell me about their applications. Respectfully, Dennis Baer 25 MIller Road Farmingdale,NY 11735 516 694 5872 ....!ihnp4!iguana!polyob!polyof!helm!dlbaer
jpn@teddy.UUCP (John P. Nelson) (05/05/87)
In article <224@helm.UUCP> dlbaer@helm.UUCP (Dennis L. Baer) writes: > Russ Nelson in a letter dated April 21, 1987 said some things >about SPL that were uncomplementary. He complained that SPL was a pre- >processor. SPL is not a preprocessor because the Structured Programming >Language does not resemble BASIC in its format or in its philosophy. I am not the same "Nelson" that posted the original complaint, but I have to agree with Russ. I downloaded SPR (It was about a year ago? I can't recall if I got it from USENET or COMPUSERVE) but anyway it was on a sight unseen basis (an ARC style archive) - All I had to judge the package was a glowing description (You know - "new language", "structured programming", etc.) that did not mention BASIC anywhere. I was VERY disappointed to realize that SPR was a BASIC preprocessor (after unarc'ing and printing the manual). Let's not pick nits here, either. SPR is a BASIC preprocessor in the same sense that "ratfor" is a fortran preprocessor. Sure, the enhanced languages are different to some extent, but the programmer must be aware of the UNDERLYING language, as well. It is not a true "translator" in my mind because of how closely tied the base and enhanced languages are.
guido@mcvax.cwi.nl (Guido van Rossum) (05/06/87)
Regarding the difference between translators and preprocessors: I haven't tried SPL (not SPR, Jonh!) so I don't know which it is, but I do have a criterion to distinguish translators from preprocessors: A translator does *full* lexical and syntactical analysis, while a preprocessor leaves part of this kind of checking to the processor (compiler/interpreter/...) of its output language. For example, the C++ front/end by Bjarne Stroustrup is a translator, because it finds all bugs in the C++ source. The "C preprocessor" is what its name says, a preprocessor. (Let's not pick nits; there may always be bugs in translators that can make it produce output which causes errors in the next phase; but this can happen even to a C compiler: on some systems, code segments > 32K can generate assembler or linker warnings, and on most systems linker warnings are the only way to detect unsatisfied external references.) The SPL implementation at hand could be either, but I would like to believe its author who says that SPL is a translator (and whose vehement reply seemed to indicate that he knows the difference). One problem could be with the documentation: if it relies on the user's knowledge of BASIC instead explaining all the syntactical and semantical details of the language in their own right, it is probably guilty of starting the translator/preprocessor controversy. Another problem could be with semantical restrictions imposed by the underlying BASIC system; I presume SPL's string operations are translated into the corresponding BASIC string operations, and this means there are all kinds of nasty limitations such as a maximum string length of 255 bytes or the requirement of frequent garbage collections. But as I say, I don't know, as I haven't inspected SPL. Quite a different point is the question whether SPL as a *language* differs sufficiently from BASIC to deserve all the hype it receives. When I glanced through the documentation about a year ago, I said to myself: Gasp! a dialect of Algol-60 with BASIC string handling and a few other goodies added. It's good that the users of BASIC get access to a more structured language; but it's bad that this is the structure of the sixties. C'mon folks, programming language design has evolved quite a bit beyond that in the past 20 years! I wish Dennis Baer had spent his time in writing a true microcomputer implementation of something like Icon, or our own ABC, for that matter. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or (from ARPAnet) guido%cwi.nl@seismo.css.gov
scott@tg.UUCP (Scott Barman) (05/09/87)
In article <7374@boring.mcvax.cwi.nl> guido@cwi.nl (Guido van Rossum) writes: > A translator does *full* lexical and syntactical analysis, while a > preprocessor leaves part of this kind of checking to the processor > (compiler/interpreter/...) of its output language. This sounds pretty much what Ratfor does, especially the versions from the Software Tools Users Group. If this is true, then why is Ratfor still called a preprocessor? Scott Barman {philabs, pyrnj}!tg!scott or {bellcore, pyuxe}!pyl2!scott
guido@mcvax.cwi.nl (Guido van Rossum) (05/12/87)
In article <7374@boring.mcvax.cwi.nl> I wrote: >> A translator does *full* lexical and syntactical analysis, while a >> preprocessor leaves part of this kind of checking to the processor >> (compiler/interpreter/...) of its output language. In article <193@tg.UUCP> scott@tg.UUCP (Scott Barman) writes: >This sounds pretty much what Ratfor does, especially the versions from the >Software Tools Users Group. If this is true, then why is Ratfor still called >a preprocessor? Ratfor (at least the version that comes with 4.3BSD Unix) doesn't care very much about the contents of simple statements. It checks for matching parentheses, but not much more, leaving lots of error checking to the f77 compiler. You can feed it with complete nonsense without getting any errors from ratfor. Thus, this ratfor is definitely a preprocessor, not a complete translator. I don't know about the version of the Software Tools Users Group; does it check the syntax of F77 I/O statements, for example? Maybe it is still called a preprocessor because it grew out of one (the original from Bell Labs). -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or (from ARPAnet) guido%cwi.nl@seismo.css.gov