kim@analog.UUCP (Kim Helliwell ) (11/01/84)
The review of MacIntosh Pascal by Dennis Brothers in the recent A+ magazine
prompted me to go ahead and get Pascal. What follows here are my own
impressions (and gripes), a mini-review.
Disclaimer: The following is written on my lunch hour, off the top of my
head, and without access to the manuals or Brother's review. Therefore, any
errors of fact should be attributed to me. The following represents my own
opinion solely.
MacIntosh Pascal, the long-awaited MacPascal, is finally available off the
dealer's shelf. It is an interpreted version of Pascal with a large number
of very useful extensions. It appears (from the documentation) to conform
quite well with the ANSI standard, and also conforms closely with Lisa
Pascal. Some of the extensions are: REAL string types, Lazy I/O (which
overcomes the read-locking problem when input is expected from the keyboard),
quite extensive built-in support of the MacIntosh ROM, and so on.
Note: REAL string types--by that I mean one does not need to be concerned
with the length of a string a priori (other than providing a maximum length),
and the true length is available via a function call. Also, several string
and substring manipulation functions are included.
GOOD THINGS:
Debugging: The built-in debugging environment is *very classy*. Breakpoints
can be set by using the mouse to place stop sign icons next to the lines in the
program listing window at which stops are desired. An Observe window lets you
type in the name of any variable (or any expression, really), and have those
expressions updated at every breakpoint. By choosing go-go from the run
menu, the breakpoints become tracepoints (or watchpoints, depending on your
terminology) and the observe window is updated at every breakpoint, but
execution continues without intervention. You can step thru the program,
and the observe window is updated every step. Finally, if you choose step-step,
the stepping and updating occurs without user intervention. A hand icon
points to the line being executed and moves through the program as execution
proceeds. The program may be stopped at any point by choosing halt from the
menu.
There is also an "Instant" window which allows any valid pascal statement to
be typed in and executed *any time*. This is also a good debugging aid.
Toolbox support: There is extensive built-in support for Quickdraw procedures
and functions (My impression is that every Quickdraw procedure is there, but
there are some caveats given about the use of some of them). The SANE
environment is fully supported. There are a smattering of built-in procedures
supporting event manager and window manager routines and the sound driver is
well supported.
Beyond that, there are a procedure and three functions which allow ANY of the
ROM calls to be executed. The user supplies the trap number and the
arguments, and that's all! All you need to know are the trap numbers, and
how to use the calls without blowing up the system.
One sample program supplied is a text editor, which shows by example how
to substitute your own menu bar for the Pascal one (and get the Pascal one
back when you're through!), how to manipulate windows, how to handle a
TE edit record, and how to handle mouse events. It is quite good in some
respects.
Error reporting: This is reasonably good. The error messages are clear, and
a "thumbs down" icon points to the offending line. The down side is you only
get to see one error at a time, so correcting a program for the first time
could be tedious.
Editing: The program listing has its own window, and all the normal Mac
editing features are available for editing the listing. In addition to
double-clicking to get a word, you can triple-click to get a whole line, which
is sometimes handy.
BAD THINGS:
Speed: In a word, SLOOOOWWWWWW. Brothers in his review rates it about as
fast as MS BASIC. I think it comes in a bit slower, because Pascal apparently
pre-scans the code EVERY time you start your program to catch what would
be considered compile-time errors in a compiler environment. This can be
irritating in an extensive debugging session.
Memory: Here we hit the low, I think. The manuals very carefully avoid mention
of how much memory you actually have to work with. The "About Pascal" display
tells you in percentages how much you have used, but there is nowhere that I
have seen that gives a hard figure here. There is apparently no way to
increase memory by sacrificing stack or system space, as there is with MS BASIC.
And the amount of memory seems smaller than the 29+K you could eke out of
MS BASIC. Maybe the stink some people raised about the shortage of memory
in MS BASIC caused the people at Think to avoid allowing easy access to
hard numbers . . .
As an example, the text editor example mentioned above is marginal for the
memory in a 128K machine. With the listing window up, the program takes
90% of the memory. The largest file you can edit with it is (apparently)
5K. My attempts to make small additions to the program (three or four lines,
at most) cause Pascal to run out of memory.
The worst of it is, when you do run out, the recovery is to exit back to
the Finder! Saving your edits does not help, because sometimes the act
of saving is what triggers the out of memory error!
When the listing window is closed, the same program take 50% of the available
memory. Probably this is what allows it to run in the first place. If
the data area is about 8K (including 5K for the text area), and that represents
40% of the available memory, then the available memory is about 20K. Not too
great. And this probably represents a generous upper limit.
If you really want to go the whole nine yards and do a full Mac environment
application, you will need a 512K machine, no question.
COPY PROTECTION: Think Technologies deserves some real hoots in this area.
The package is copy protected up to ying-yang. It is not even one of those
schemes in which the program can be copied and run as long as a master disk
is inserted once per bootup--you have to use the master disk as supplied.
(Maybe Microsoft is not such a villain in this area, after all!). Several
copy schemes are employed--at least three that I know of, and maybe four.
A couple are easy-the copy-protect bit is set, and some necessary files are
hidden. Beyond that, there is most likely a bad sector scheme, and maybe
Apple also has a copy protect bit for a whole disk, as well.
Dennis Brothers told me that it is the most thoroughly protected piece of
software he has ever seen, but that he has cracked it. (He won a bet
from Think for doing it, too!) But he can't let the rest of us in on
the secret, unfortunately.
If you are one of those constitutionally unable to contemplate buying
protected software, this one is not for you. On the other hand, if you
like the challenge of cracking protection schemes, you might enjoy the
puzzle this one affords.
Brief Aside: I am not a lawyer, but my understanding is that there are
specific provisions in the copyright law which allow purchasers of software
to make backup copies of the software to protect their investment. Thus,
vendors who protect software in the manner described above are, in effect,
denying their customers a right specifically given by law. Unfortunately,
the reality of the situation is that there is little point in suing the
vendor over this denial of rights. But I sure would like to see a bit
more attention paid to the laws governing these issues, ON THE PART OF THE
SOFTWARE VENDORS, as well as on the part of the purchaser.
OVERALL: Overall I rate the product about 8 on a scale of 10. One way or
the other I can live with the copy protection. The memory problem will be
solved when I get my memory upgrade. The speed problem should be addressed
eventually when Think brings out the package which upgrades this Pascal to
a full development system. This is PROMISED for first quarter next year, so
at least sometime next year it should become available. The good features
outweigh all the bad by a fairly decent margin. And the language sure beats
MS BASIC!!
(Mr.) Kim Helliwell
{menlo70,hplabs}!analog!kimbill@utastro.UUCP (William H. Jefferys) (11/05/84)
I think the available memory is larger than the review gives. I was
able to run a "do nothing" program that just declared just under 30K
of characters and then stored something in each element. This was
with the windows normally open. However, the a given "large" program
will sometimes run and sometimes not, so I think there may be some
fancy garbage collection going on that isn't the same every time...
--
"When evolution is outlawed, only outlaws will evolve"
Bill Jefferys 8-%
Astronomy Dept, University of Texas, Austin TX 78712 (USnail)
{allegra,ihnp4}!{ut-sally,noao}!utastro!bill (uucp)
bill%utastro.UTEXAS@ut-sally.ARPA (ARPANET)