Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!brutus.cs.uiuc.edu!psuvax1!news From: schwartz@psuvax1.cs.psu.edu (Scott Schwartz) Newsgroups: comp.lang.pascal Subject: Re: Runtime dimensioning and Pascal Message-ID: <1989Nov12.040036.10887@psuvax1.cs.psu.edu> Date: 12 Nov 89 04:00:36 GMT References: <6354@merlin.usc.edu> <9686@vax1.cc.lehigh.edu> <804@maytag.waterloo.edu> <6422@merlin.usc.edu> Sender: news@psuvax1.cs.psu.edu Organization: Pennsylvania State University, computer science Lines: 27 In-Reply-To: ajayshah@aludra.usc.edu's message of 11 Nov 89 23:19:09 GMT In article <6422@merlin.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: >In article <9686@vax1.cc.lehigh.edu> LUKRW@vax1.cc.lehigh.edu writes: > I do wish Borland would "get with the program" and stop >ignoring the standard. Extensions are nice, but compatibility beats On this issue, I'm squarely on the side of Borland. Standard Pascal is a reasonably crippled creature: no hooks for seperate compilation, no breakouts from strong typing, stupid file handling, etc. The fact of the matter is that the ISO standard specifies that language extensions are permitted. In other words, the seperate compilation stuff, breakouts from strong typing, etc, etc, are all ok. The problem is that Borland, for no sensible reason, omitted lots of required functionality. If you are so excited by features, then ask yourself why Borland omitted conformant arrays, procedure parameters, and the elegant i/o model that the standard requires. In my humble opinion, the reason they left these things out is pretty clear to anyone who read the documentation that came with the early versions of the compiler: they wanted a quick and easy implementation for the CP/M systems that were popular at the time. Anything the compiler writer didn't understand, didn't want to spend time on, or didn't feel like using simply got left out. -- Scott Schwartz "More mips; cheaper mips; never too many." -- John Mashey