Re: Pascal for IIgs...

[pg@sff.net (Paul Guertin)]

"Mike Westerfield" <MikeW50@aol.com> wrote:

> Ironically, when properly implemented, the Pascal GOTO statement
> actually handles this much better, more powerfully, and often more clearly
> than C's break and continue.

C has a goto statement, too, and unlike in standard Pascal, the labels
are not limited to numbers (but most real-world Pascals do not follow
the standard in that respect). I like "break" because its meaning is
obvious. It's a restricted kind of goto that I tend to use a lot.

I use goto from time to time, but mostly to get out of inner loops
when an error happens.

> On the other hand, C lacks sets, strong typing,
> it's unions are a poor shadow of variant records, it doesn't allow functions
> within functions, and so on. The _many_ lacks of C don't make up for these
> two statements.

Pascal's sets tend to be very limited. I don't remember offhand what
the standard specifies, but on the implementation I last used, they
were limited to 64 elements. That's easily done in C with bit masking.

Functions within functions are nice theoretically, but in practice I
have never found them useful. I just put all related functions together
in a file and use static variables to hide what should be hidden.

The lack of strong typing has never bothered me. I do use prototypes
and lint, of course.

Pascal's variant records are slick.

> I'm surprised you didn't mention the close relationship between arrays and
> pointers and C's preprocessor, though.

That's only because I was thinking of Pascal's bad points, not C's good
points. :-) I agree that the "arrays-as-pointers" idea is nice and elegant;
unfortunately, beginners tend to be confused by books that explain it
inadequately. (Tips for everyone reading this who wants to learn C: buy
the White Book, read the comp.lang.c FAQ, avoid Herbert Schildt and
anything with the words "in 21 days" in its title. Oh, and read "C Traps
and Pitfalls" by Koenig.)

> Type casting
> is another very useful feature of C that is missing from Standard Pascal,
> although every implementation on the Apple IIGS, Macintosh and Windows
> platform I can think of has type casting.

And well they should. Type casting is a necessity for systems programming,
and it can be very helpful in mundane programs (but like any powerful tool,
it can be dangerous if misused).

> >Pascal does not even have a string type
> More or less true. Long before ANSI C, though, C compilers had standardized
> on a set of extensions that, for the most part, defined what ANSI C would
> become. The same is true of strings and Pascal.

But with Pascal, the extensions came after the standard, not before.

(And I think that the difference between K&R C and ANSI C is not as
great as between standard Pascal and a version of Pascal meant for
serious software development.)

> Frankly, whether int is a 2 or 4 byte entity (or
> something else entirely) causes more problems for porting C programs than
> strings do for porting Pascal programs.

For poorly written programs, yes. Unfortunately, C does not prevent you
from writing bad code, and there is a lot of bad C around (but that's
also due to the fact that there's a lot of C around, and Sturgeon's law
applies.)

Paul Guertin
pg@sff.net