From: jimf@centerline.com (Jim Frost)
Subject: Re: Kernighen's "Why Pascal is not my favorite language"
Organization: CenterLine Software, Inc.
Distribution: usa
Date: Tue, 28 Jul 1992 17:28:49 GMT

cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
>Well, anybody that uses Pascal these days uses something that at least
>RESEMBLES Turbo Pascal...

>(1) Array typing:  I think that the OOP extensions have mitigated this...

Actually you could get around it by treating things as addresses and
then pointing an array type with one element at the address.  In Turbo
Pascal this is done through either the @ operator or (in older
versions) the addr() function.  You can compose a pointer to a random
address with the mem[] and memw[] arrays.  With pointer construction
and decomposition operators you can get the work done even if it's not
very convenient all the time.

I wrote low-level network drivers in TP 4.0 and 5.0 and a bunch of
programming interfaces to OS extensions; this would have been
impossible without the address manipulation functions.

The OOP extentions did eliminate a lot of clumsiness in this respect,
but you could get the job done in earlier versions of the product --
it just took some extra work.

>(2) No Static variables:  Still a problem, last time I worked with TP...

TP has what are called "typed constants" which are actually statics;
this eliminates the scoping problems too.  These have been around
since at least v3.0.

>(4) Separate Compilation:  TP fixes this up, at least in part...

The module definitions in TP 4.0 went a long way towards making it
possible to write large systems.  I wrote about a dozen library
modules full of useful tools and then built a whole pile of
applications on top of them.  This would have been inconvenient at
best without modules, particularly in terms of compilation speed.

The best thing about TP modules is that you can define initialization
sections which are called before the first call to anything in that
module.  That's kind of a pain in most other languages.

>(5) Order of Operations:  Unchanged.

That's partially true, but TP allows you to turn "parallel" evaluation
of conditionals off.  This eliminates a lot of conditional clumsiness
with things like:

	if (p <> nil) and (p^.foo = 2) then begin ... end

I believe they call this "short-circuit evaluation" and it's the
default in later versions of TP.

>(6) Case statement has no "default":  Don't know...

There's an "else" clause that provides this capability in TP.

>(7) Lacks standard file i/o: Solved...

True, including error handling through an error-result function
(IOResult or some such, I've forgotten).  It's not the most convenient
thing in the world but it does work.

>(8) File inclusion ("#include" or substitutes):  Fixed...

Yea, that's been around since at least TP 3.0.  It's the only reason
you could build a decent system in the first place.  TP 4.0 added
conditional compilation and things like that and improved the
environment dramatically.

One of the other things that Kernighan spoke about was the limitations
imposed by one-entry-one-exit mentality; you often want to exit
prematurely on an error condition.  While standard Pascal provides no
way to do this, TP provides `exit' (semantically equivalent to C's
`return') and halt(x) (equivalent to C's exit()).

Having used a Pascal that had some useful extensions I can say
straight out that the language can be damned useful -- so long as
those extensions are there.  Borland has done a great job extending
the language.

Pascal, even Turbo Pascal, still isn't my favorite language.  It fixes
the things that make it impossible to get work done in Standard
Pascal, but it's still clumsy for a lot of tasks.

jim frost
jimf@centerline.com