Path: utzoo!attcan!uunet!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think Pascal Wishes...?
Message-ID: <12599@hoptoad.uucp>
Date: 1 Oct 90 07:50:08 GMT
References: <4251@husc6.harvard.edu>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Electronics for Imaging, San Bruno CA
Lines: 85

In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger
>feature requests? Annoyances? Any sort of commentary?

Thanks for asking.  I find myself wrestling for all too many hours a
week with environmental issues that have nothing to do with our code.
Most of my suggestions bear on the issues of reliability and general
programmer-friendliness rather than new features.

THINK Pascal is friendly in some ways.  In other ways it expresses a
false economy which focuses too heavily on raw compile-link-run
turnaround time.  If it takes a programmer an hour to remedy a glitch
in the environment which results from the high-speed turnaround, then
things are actually much slower.  If it takes a programmer four hours
to find a bug which a more error-checking compiler would have turned
up at compile time, then once again, the gain in actual programming
speed is negative.

(1)  Incorruptible project files.  Completely refresh the heap from the
project file after every run.  Make sure the resource map and all other
data structures are never written back to the file after having been
open concurrently with software execution.  Checksum or CRC all
critical resources and data structures to allow an algorithmic check
for corruption if it creeps through.

(2) Compatibility with 32-bit Quickdraw.  Breakpoints crash into the
machine debugger (MacsBug) with 32-bit Quickdraw in 32-bit mode if the
FPU code generation is activted.  Crashes are less frequent with the
FPU code generation disabled, but clicking on a LightsBug variable
in 32-bit mode causes a psychedelic monochrome animation sequence,
followed about thirty seconds later by the realization that nothing
else happened in all that time -- the variable did not open.

(3) MacApp compatibility.  Any change to TWindow.IRes will cause a
fairly reliable crash and project file corruption when run under the
environment.  I reported this months ago and nothing has been done.
now it not only causes my floating windows code to crash when run under
the debugging environment, it does the same with the new official
MacApp floating windows code.  Later, I attempted to add a flag telling
TWindow not to EraseRect on a DrawContents, a very minimal change, and
I got a permanently trashed project file every time I ran it.  (By
"permanently trashed" I mean Remove Objects did not suffice to undo the
corruption.)  The symptoms were very similar to those under both
versions of the floating windows code, and the only common factor was
that a (clearly harmless, flag-setting) change was made to
TWindow.IRes.

(4) Syntax compatibility with MPW Pascal.  This will eliminate most of
the problems with MacApp.  Recently an automatic bug fix correction
script was made available by Apple; it could not be applied to THINK
Pascal MacApp because of the laborious code conversion process.  Add
the $I directive, compatible assumptions about type residency in units
and unit dependencies, and any other syntactic features which exist in
MPW Pascal.

(5) Speed up the debugger.  I'm sure part of the blame rests on the
MacApp debugger, but using both LightsBug and the MacApp debugger, code
execution time is excruciatingly long -- sometimes an order of
magnitude slower.  This is another false economy.

(6) Add an optional optimizer phase.  MPW Pascal produces register
optimized code that is both significantly faster (10%+) and smaller
(because all the stack-relative offsets disappear from most code).
Making it optional means it need not slow down the ordinary compile-
link-run cycle.  Note:  If the system becomes compatible with MPW
Pascal, then this is less important, since MPW can be used as a
production code building phase.

(7) Improve RAM usage.  Run the code either as a separate MultiFinder
process or using MultiFinder temporary memory.  Having to allocate RAM
permanently to the application when megabytes of it are only useful
during execution of the user code has a severely negative impact on the
usefulness of MultiFinder.  It becomes difficult to use THINK Pascal
together with other programmer tools such as ResEdit, HyperCard (for
documentation) and MPW (for resource and/or project management).

(8) Check for unsafe VAR parameters, unsafe WITH statements, and
uninitialized variable accesses.  A few seconds per file are well worth
the hours of debugging time it sometimes takes to find these errors.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Satanic is merely the name they give to the behavior of those who would
 disrupt the orderly way in which men want to live."
    -- Gabrielle, THE VAMPIRE LESTAT, Anne Rice