[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pascal for IIgs...
----------
In article <3798e2e7.32860130@news.newsguy.com>, pg@sff.net (Paul Guertin)
wrote:
>The absence of "break" and "return" statements from Pascal often makes
>things a lot more complicated and less obvious than they would need to
>be, usually involving extra boolean variables.
True. Ironically, when properly implemented, the Pascal GOTO statement
actually handles this much better, more powerfully, and often more clearly
than C's break and continue. On the other hand, C lacks sets, strong typing,
it's unions are a poor shadow of variant records, it doesn't allow functions
within functions, and so on. The _many_ lacks of C don't make up for these
two statements.
I'm surprised you didn't mention the close relationship between arrays and
pointers and C's preprocessor, though. I don't see break and continue as
particularly important, but arrays/pointers are genuinely cool and the
preprocessor is truly one of the strongest reasons for using C. Type casting
is another very useful feature of C that is missing from Standard Pascal,
although every implementation on the Apple IIGS, Macintosh and Windows
platform I can think of has type casting.
>Pascal does not even have a string type, which make it quite painful
>to develop actual applications. That is why most so-called Pascal
>compilers do not actually recognize Pascal but an unofficial superset
>of the language.
More or less true. Long before ANSI C, though, C compilers had standardized
on a set of extensions that, for the most part, defined what ANSI C would
become. The same is true of strings and Pascal. While there are strong and
weak designs in individual languages, strings are not much of an issue in
Pascal--there is a generally accepted, standardized (though not ANSI
standard) set of string extensions that every serious microcomputer Pascal
I've seen literally since the Apple ][+ uses. The same is true for units for
separate compilation, which ANSI Pascal doesn't support either. So, while
the string argument may be technically true, it really isn't an issue in
real-world programming. Frankly, whether int is a 2 or 4 byte entity (or
something else entirely) causes more problems for porting C programs than
strings do for porting Pascal programs.
Mike Westerfield