[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pascal for IIgs...
----------
In article <379add70.7547247@news.newsguy.com>, pg@sff.net (Paul Guertin)
wrote:
>> 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.
>
>C has a goto statement, too, and unlike in standard Pascal, the labels
>are not limited to numbers (but most real-world Pascals do not follow
>the standard in that respect). I like "break" because its meaning is
>obvious. It's a restricted kind of goto that I tend to use a lot.
>
>I use goto from time to time, but mostly to get out of inner loops
>when an error happens.
>
The use of named labels for C's goto statement is nice. What's nice about
Pascal is the fact that they actually work for the one undeniably reasonable
purpose you need a goto statement for: error handling. C's goto statement is
limited to the current subroutine. Pascal's is not! I can jump from a
subroutine to any externally nested subroutine, or right back to the main
program. It's difficult to implement, but one of the coolest features of
Pascal.
>> 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.
>
>Pascal's sets tend to be very limited. I don't remember offhand what
>the standard specifies, but on the implementation I last used, they
>were limited to 64 elements. That's easily done in C with bit masking.
Standard Pascal requires that a set handle "set of char." That generally
means at least 128 bits. Most good implementations of Pascal allow much
larger sets. ORCA/Pascal is limited to 512K element sets, for example.
A bit mask is fine, but it's not a set. One of the reasons why all of my
compilers are written in Pascal (including ORCA/C) is that parsers and
exception handlers are so much easier to write with sets and the Pascal IN
operator. You cannot get the same simplicity and logical flow from C; I
know, I've tried.
>Functions within functions are nice theoretically, but in practice I
>have never found them useful. I just put all related functions together
>in a file and use static variables to hide what should be hidden.
I have. I use them a lot. And separate files are absolutely no substitute.
>> >Pascal does not even have a string type
>> 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.
>
>But with Pascal, the extensions came after the standard, not before.
At one point or another, that could have been said about C, too. While
standards play a role in establishing what is minimally acceptable for a
language, language implementers do add to minimal implementations. What they
add does become accepted as normal in a language, and those features in turn
are eventually incorporated into standards. That's how ANSI C became a
standard, in fact. Criticizing Pascal for not having strings misses the
point, since every major implementation I've seen on a microcomputer has
strings, and supports the same minimum set of commands.
Mike Westerfield