[comp.lang.pascal] Compilers and Interpreters

brad@looking.UUCP (Brad Templeton) (12/21/86)

In article <2647@hcrvax.UUCP> bob@hcrvax.UUCP (Bob Kyryliuk) writes:
>Since the ISO/ANSI Pascal Standards (as well as Jensen & Wirth) leave
>a number of fundamental items to be incorporated as extensions, and
>since many current compilers and interpreters implement these
>extensions in different ways I have a question on the practicality
>of the above suggestion. [of using interpreter with a compiler]
>
>Does the use of the ALICE environment require the programmer to
>"port" his programs (from ALICE to the compiler he is really going
>to use to run his application) every time he wants to test his
>application on his compiler, and then "re-port" his program back
>(from his compiler's syntax to ALICE) every time he wants to do
>"development"?

Many people attempting to write portable programs try to stick close
to ISO standard Pascal.  This isn't great, but if you ever want your
program to leave the machine it's on, you have to do it.

Another level up is to use ISO Pascal plus various extra built-in or
library routines.  While an interpreter like Alice won't have all
the library routines of all compilers, a lot of them can be quickly
written and hidden away so that the compiler doesn't see the definitions
of them.
>
>> ALICE can
>> also be used in conjunction with Pascal compilers like OSS Pascal.
>
>If you had a Turbo Pascal Compiler and ALICE on the same machine,
>incompatible interpreters and compilers would not be a problem since
>ALICE is claimed to have the Turbo Pascal extensions (plus perhaps
>others).  However, the most common pascal compiler for the ST
>appears to be OSS Pascal (correct me if I'm wrong), which has a
>different set of extensions from Turbo Pascal. I would assume that
>Brad's mention of using ALICE "in conjunction" with OSS Pascal to
>mean that there is compatibility only as far as perhaps standard
>Pascal, which has numerous deficiencies as mentioned earlier.

Actually, Turbo Pascal borrows from UCSD Pascal, and OSS Pascal borrows
from both.  Now these thing aren't exact at the low levels, so you can't
just expect to take a program written with one compiler and run it on
another (or on an interpreter) but it is the case that well written
programs developed with both systems in mind can make use of many of the
extensions.

This is usually the case with different systems that try for a level of
compatibility.  Programs written with portability use only the high
level features.  Use of special low-level information is asking for it.

While OSS Pascal is probably most popular on the ST, it has sold under
5,000 copies and is nothing in the Pascal world compared to the
400,000 (?) copies claimed for Borland's Pascal.

Of course, I am not too sure about Borland's "standard", as Turbo Pascal
on the Macintosh is actually quite different from Turbo Pascal on the PC.
They took the (perhaps correct) attitude that most customers would be
Mac users after Pascal, and not PC Turbo customers moving to the Mac.
>
>Although in an educational environment, an interpreter may be good
>enough for student programming, in the commercial world of hundred
>thousand line applications, the bottom line is execution performance
>and a compiler is often essential.

Quite true, and Alice, like any interpreter system, isn't meant to run
100,000 line programs.  (In fact, the majority of compiler systems I have
seen for micros are incapable of this.  Most C compilers I have seen are
unable to handle large programs that were not written for them in the
first place.)  About 99% of all programs written are short jobs, a couple
of thousand lines at the most.  Furthermore most GEM programs are
"event bound" and can be run by an interpreter fairly well.  But I am not
going to go around claiming that an interpreter is a good solution for
all problems.  But for many it's the fastest, and certainly the most fun.

At the price we're selling it for, we think a lot of people might want
to buy Alice just as a "play around with GEM" system, even if they
don't turn their applications into polished, high-speed finished products.
>Bob Kyryliuk, Software Products Manager, HCR Corporation


-- 
Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473