Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!spar!ellis
From: ellis@spar.UUCP (Michael Ellis)
Newsgroups: net.lang.pascal,net.lang.c
Subject: Re: PASCAL as a system's programming language
Message-ID: <24@spar.UUCP>
Date: Thu, 10-Jan-85 09:35:40 EST
Article-I.D.: spar.24
Posted: Thu Jan 10 09:35:40 1985
Date-Received: Sat, 12-Jan-85 06:28:47 EST
References: <252@harvard.ARPA> <193@ihu1m.UUCP>
Reply-To: ellis@spar.UUCP (Michael Ellis)
Organization: Schlumberger Palo Alto Research, CA
Lines: 29
Xref: watmath net.lang.pascal:176 net.lang.c:3813

From Ken Perlow:
>--
>Actually, all PASCAL needs to be a superior systems language to C is a
>casting operator, assuming the compiler knows how to optimize
>programming constructs like sequential array references.

My experience implementing a filesystem in PASCAL was surprisingly
positive given the bias I held toward C at the time. The only deviation
from Jensen-Wirth's standard required to transform PASCAL from a toy
into a credible language is separately compilable modules.

Casting operators can then be written in PASCAL as functions which blindly
return whatever is passed to them (the assumption here is that type-checking
is ineffective across compilations). Such functions also serve the purpose
of C's `&' operator.

One still must code assembly routines in order to escape PASCAL's detestable
(that word is too mild!) I/O `philosophy'; again, separately compilable
modules provide this avenue.

The features of PASCAL I miss most when programming in `C' are:

1) The debugging power of PASCAL's subrange types.
2) Notational consistency, especially with structures, arrays and pointers.

It's unfortunate that C is irrevocably brain-damaged by the lack of
coherence and clarity as regards item (2). 

-michael ellis