info-mac@uw-beaver (info-mac) (10/10/84)
From: Stuart Reges <REGES@SU-SCORE.ARPA>
In response to David Spector's glowing comments about MacPascal, I'd like to
talk a little about limitations of the software. I've been using MacPascal for
several months now and have sent bugs/suggestions to Think. Some problems have
been fixed and some have not.
The biggest objection I have currently is commenting. Some people like to do
comments like this:
(* Stuart Reges
Assignment #1
10/3/84 *)
MacPascal does not support multi-line comments (one of the many non-standard
"features" that should be pointed out in the section on differences between ANSI
and Mac Pascal).
David is correct in pointing out that when you hit the return key while typing a
comment, it closes the comment on the current line and opens a new one on the
next line. David thinks this is a feature. I would agree, if you could turn it
off. If you decide you want things your way anyway and go back and delete those
extra comment characters, MacPascal chokes. So you have to settle for comments
like these:
(* Stuart Reges *)
(* Assignment #1 *)
(* 10/3/84 *)
Well, that's okay. If you can do it. But you can't. Remember that the program
window is in a proportional font. You can't line up the comment close
characters easily because some characters are wider than others. I would
personally like to line these up on tab stops, but MacPascal has no tab stops.
How am I going to easily make this kind of comment:
CONST max = 100; (* maximum score *)
TYPE range = 1..max; (* range of legal scores *)
VAR count : INTEGER; (* loop counter *)
number : range; (* next number *)
sum : REAL; (* running sum *)
I have yet to see a well-documented MacPascal program. The demo programs would
get about 0.5 out of 20 points for commenting if they were turned into my
class (we always give at least 0.5).
There is no good solution to this that I can find. You can edit the program
using the text editor or using MacWrite, but then if you feed it into MacPascal
again to be executed, it is reformatted. This will encourage students to write
the program without comments, then use MacWrite to add comments, and then never
use the program again. That's not what I'm trying to teach in my course.
The TEXT window uses a fixed width font (that's at least one win). This,
however, causes problems when you try to do something like this in the program
window, since the program window uses a proportional font:
WRITELN ('Name Department Salary');
WRITELN ('---- ---------- ------');
These will look different in the program window than they do in the TEXT window.
This also leads to problems with comments where you want to say:
(* The output of the program is formatted in columns, like this: *)
(* *)
(* Name Department Salary *)
(* ---- ---------- ------ *)
Introductory students need to be told and told and told, "COMMENT YOUR
PROGRAMS." Before we would use something like MacPascal in our introductory
courses we would want to make it sure it encourages rather than discourages good
commenting.
There are other problems with MacPascal. Don't believe the documentation. For
example, anonymous types defined within RECORD scopes are not handled properly.
This program is legitimate but doesn't work:
PROGRAM Fun;
VAR p: record
sex: (male, female);
end;
BEGIN
p.sex := male
END.
Because the word "male" is defined within the scope of the RECORD, the main
program doesn't know about it. It tells me that the word "male" is undefined.
I mentioned this to Think and they told me their Pascal is "variant in this
respect." I think that's a new way of saying "It's got a bug."
This implementation is also far from being complete. No passing of procedural
or functional parameters, DISPOSE marks the space as unusable but never
reassigns it (and this on a machine where memory limitations seem to be the
biggest issue!), variant records can only be nested one deep, etc.
These remarks all pertain to MacPascal 1.0 sold to us by Apple. If there is a
better version on the way, I'd love to hear about it. This one has problems,
though. I plan to use it in lecture but not yet subject my students to it.
Another question that hasn't been addressed about this product is how it
performs on a fat Mac. I plan to try it out myself when I find the time. I
will report results here if somebody doesn't beat me to it. I plan to try three
different programs that are "big" by virtue of their length, their dynamic use
of memory, and the time required to execute. In our advanced programming
courses we assign all three kinds of problems (actually, our problems usually
have all three attributes).
-------