Pic to Clip
Volume Number: 1
Issue Number: 11
Column Tag: Pascal Procedures
The Amazing Pic to Clip Utility 
By Alan Wootton, President, Top-Notch Productions, MacTutor
ContributingEditor
Miscellaneous Month
This month there will not be a main topic, instead I have a collection of goodies
that I have been saving up. We will talk a little about some books, about the compiler
search I am conducting, revisit printing, and cover two more short topics.
Before I begin, I would like to talk a little philosophy. I wish to bare my soul on
what Pascal means to me. There has been some talk about "fluff" in this publication,
and this makes me wonder about Pascal. Is Pascal a Real Programmers language? Or
is Pascal for Quiche Eaters (see Feirstein, B., "Real Men don't Eat Quiche", New York,
Pocket Books, 1982.)? It was once thought that Real Programmers used Fortran.
Today it would be C (and always assembly). In that perspective Pascal is indeed for
Quiche Eaters, and there are undoubtedly millions of Quiche Eating Pascal
programmers. Let us not forget however, that the ROM was originally in Pascal,
MacPaint still is. These are not programs created by Quiche Eaters. It was a Real
Programmer who, in a fit of rebellion, created LinlineF and Generic. It was a Real
Programmer who mangled Niklaus Wirth's (the world renown Quiche Eater who
created Pascal) specification by allowing for the beautiful expression
ptr:=pointer(ord(ptr)+$100). There is hope for Pascal.
Let us review what a high level language is for. In the dawn of time there were
only front panels with switches. Later, the Assembler was invented; the idea being to
cater to the laziness of Real Programmers. This was acceptable because every
conceivable possibility was still available. After that someone noticed that much of a
programmers work was making sure that parameters were passed correctly between
procedures, and that the stack was not messed up. The high level language was invented
to ease the drudgery of these tasks. Now those who used Fortran ,the first HLL, weren't
trying to get away from assembler so much as they were being lazy (one of the higher
instincts of Real Programmers). And for those things not allowed in the HLL, assembly
code could be linked in. All went well, except for the increasing numbers of Quiche
Eaters who jumped straight into Fortran, bypassing knowledge of assembly language.
Here is where the trouble begins.
By this time programming had become Real Big Business and certain managerial
types were troubled over the fact that their Quiche Eating programmers couldn't
decipher the strange things the Real Programmers were now doing in Fortran (list
processing, records, pointers, string manipulation, etc.). The word was passed around
that Fortran must be upgraded to allow for these strange new constructs. Along comes
Wirth to save the day, and the Quiche Eaters gain new momentum. What we had now
was a deluge of programmers, working in a toy operating system, who had little or no
knowledge of how a computer really works. Real Programmers were in danger of
becoming extinct. But, let us not forget that the true purpose of a HLL is as a shortcut
to machine code for lazy Real Programmers. Eventually, as Pascal became popular
extension were made to the language so that Real Programmers could use it. Still,
Pascal was increasingly distant from the workings of the maching it ran on (Basic and
microcomputers fuel this trend). This accounts for the popularity of Forth, a language
that wallows in the chacteristics of its processor and is infinitly extendable and
unreadable (perfect for a Real Programmer).
The 68000 changes all this. The 68000 is designed with an instruction set that
provides for the efficient implementation of most HLL statements. On the Mac you can
trace machine code and see it follow, line by line, the structure of a Pascal program (I
do this all the time). At last the Real Programmers have a language that raises
laziness to a high art. And MacPascal is at the top of the heap. One jots down the code
he (she) wants, and it is immediately checked for syntax, semantic form, and is even
emulated to check for logical errors. It can then be automatically and effortlessly
converted into machine code. Or can it?
The Real Programmers at Apple are a snotty bunch (supposedly the worst were
canned, but I don't believe it). They think that all the Real Programmers in the world
work for Apple, or Microsoft, or IBM (blue suits), or NASA (rocket jocks), or the
National Security Agency (spooks), and that there is no need to provide a compiler for
the Quiche Eating public. You see they all have compilers on their Lisas (so do I, but I
hate it). Therefore, Mr. Jobs allowed Apple to shoot itself in the foot and there is still
no compiler. Now I will admit that MacPascal is perfect for the
Real-Programmer-growing-up and for the Quiche Eaters too. But, the Real
Programmers cannot exist for long on MacPascal and UCSD Pascal. They need a native
code compiler or they will all switch to the excellent C systems available for the IBM
PC (interpreter, preprocessor, compiler, optimiser, runtime profiler, assembler,
libraries, source code debuggers, all integrated into one system). It would be a shame
if the Mac died for lack of Real Programmers.
For me this is the real purpose of Pascal; a lazy way to write machine code. Like
a spelling checker or a business letter generator, Pascal is a way to save time, not an
excuse to not learn to spell or write. One can use MacPascal to diddle with the system,
knowing full well that his efforts can be smoothly integrated into the natural Mac way
of programming. This arguement should explain why an interpreted language, or a
psuedo code system won't do. Not to mention the fact that without native code you can
never make desk accessories, window definition functions, control definition functions,
INIT resources, etc. More importantly, if you compile your procedures into
resources (the standard method), you can call them from inside MacPascal. For an
example of this see my article on printing (August Vol.1 No.9) where the PDEF
resources are called in just this manner. This way when your MacPascal program gets
too long you just compile parts of it until it is more managable. If it weren't for
MacPascal I would switch to C in a second.
The Great Compiler Hunt
First of all, Apple intends to port the excellent Lisa compiler over to the Mac
(without the dumb OS it now uses). The problem is that they don't have the good sense
to just do it; they are going to re-write the whole MDS system. I was told it would not
see pre-release until December. My personal prediction is that we will all grow old
first and then we will have to buy the new Mac and the new hard disk, to the tune of
about $5000.
[Note: MacTutor is pushing for a ".REL" file standard that would allow linking of
object code files from a variety of programming languages. We are on record as
supporting the MDS ".REL" file format as that standard with proposed extensions
submitted by Bill Duvall's new linker, which is compatible with the MDS system as
well as his own C system. MacFortran from Microsoft is also very close to being
compatable with this standard, and hence Bill's new linker. We encourage Apple and
other proposed compilers to support the MDS ".REL" file format for object code files so
that all languages can be linked with one common linker. We hope that Apple in
developing the Lisa compiler for Pascal on the Mac will consider conforming to this
standard. What we don't need is for Apple (and others) to give us yet another
incompatible object code file format (ie, don't dump the MDS system Apple!) More on
this in upcomming issues. -Ed.]
Tom Leonard of TML systems, Melbourne, FL. (a Real Programmer for sure) is
writing a Pascal compiler to go with the MDS system (by Bill Duvall, another Real