PASCAL as a systems programming langugage

[Thomas M. Breuel]

|>Perhaps the nicest (in the sense of clean) thing about PASCAL
|>is the way it bifurcates the universe of objects into pointers
|>and pointees.
|
|I've always thought that was one of its most *broken* features.
|This bifurcation is ridiculous in the light of such C objects
|as pointers to pointers.

I don't know what you are talking about. PASCAL has a superset of the
data structures available in 'C'. In particular, you can get pointers
to pointers. You can even define a type 'TYPE foo= ^foo;' which is
impossible in 'C'.

|> It is thus easier to debug monster programs
|>with monster data structures than is the case with C.
|
|Exactly contrary to my experience with ~1000 line programs.
|(Not really monsters, but large enough for comparison
|purposes...)

Perhaps that would change if you worked with PASCAL a bit more? You
may find that it indeed is not a bad language for debugging. The
current state of the UN*X kernel (ever looked at namei or ever
wondered where all these unreferenced inodes come from) and the UN*X 
utilities ("My sendmail has a bug!") seem to indicate that 'C' is not
that easy to debug either.

|> Actually,
|>all PASCAL needs to be a superior systems language to C is a
|>casting operator,
|
|No pointer arithmetic?  Or ability to take the address of a static
|object?  ACK!  The ability to have static headers for linked-lists
|in dynamic storage is one of the things I miss most in Pascal. 

Indeed, no pointer arithmetic. Using arrays and indices instead is a
lot more portable and gives the compiler a lot more freedom for
optimisation and adaptation to strange architectures. Basically the same
is true for getting the address of a static object. If you are used to
it, you won't find it any less convenient than pointer arithmetic. You
may also discover that it helps avoid traps and pitfalls.

|>assuming the compiler knows how to optimize
|>programming constructs like sequential array references.
|
|I prefer a minimum of magic (like global optimizations; these
|are an invitation to the compiler to mysteriously break programs).

Working compilers don't break correct programs. I prefer
a maximum of optimisation, and if 'magic' is involved, I couldn't
care less. If you, on the other hand, rely on certain 'features' of
the compiler (e.g. sequential allocation of static data &c), then you
should not complain if you don't get what you expected.

PASCAL is written such that the compiler has a lot of freedom in
optimising the code. 'C' code, on the other hand, is very hard to
optimise, just because 'C' allows you to do funny things like get a
pointer to any variable anywhere &c.

|>I can do without the demented precedence of logical operators,
|>though.
|
|Plus the fact that short-circuit evaluation is not required...

[I'm not even sure that it would be permitted to happen..., I'll have 
to look at Jensen&Wirth]

So what? Why does the whole world have to look like '&&' and '||'?
Use 'IF' instead, it might even come out more readable.

						Thomas.
						breuel at harvard