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