thomas.mertes@[EMAIL PROTECTED]
wrote:
> On 8 Mai, 18:08, Scott Moore <sam...@[EMAIL PROTECTED]
> wrote:
>> thomas.mer...@[EMAIL PROTECTED]
wrote:
>>> IMHO the number of implementations does not play a role
>>> for ****tability. C has many implementations and the
>>> ****tability problems which exist in Pascal are simply
>>> not present. The problem is that many of the early
>>> proponents of Pascal (and if you look at this discussion
>>> also current proponents) simply do not care about
>>> ****tability. This has to do with the areas where C and
>>> Pascal came from. BTW. There is some classic article
>>> about Pascal and C from Brian W. Kernighan:
>>> http://www.lysator.liu.se/c/bwk-on-pascal.html
>> Pascal has a standard, the ISO 7185 standard. Today there
>> are basically two working dialects of Pascal, Borland's
>> Delphi, and ISO 7185. Virtually all compilers available
>> today obey one or the other, and the compiler GPC implements
>> both.
>
> So there are two Pascal langages instead of one...
Well, to be fair Borland calls their language Delphi. In fact,
if you go to the codegear site (the makers of Delphi), and
search for the term "Pascal", then you will find few references
to it and virtually no claim that delphi is Pascal, or vice
versa.
I am not sure in any case why the existence of another dielect
of Pascal is damming. There are other dialects of C, for
example C++ and Microsoft C as discussed (no, C++ is not quite
compatible with C. Look in the back of a good C++ manual for
a discussion of the differences).
In any case, I believe you are searching hard for an argument
here. There is general Pascal, and most all compilers outside
Delphi are compatible with that. The Pascal standard does not
define standard libraries, as few languages, including C, do.
The standard I/O functions of C are covered by built in
I/O features in Pascal, so thats a push.
Delphi, as with most implementations of Pascal, defines its
own set of libraries and cl*****, and the size of Delphi's
user group makes that a significant base of standard library/
class users, which addresses your complaint of earlier.
>
>> I cannot comment on the ****tability of programs between
>> the Borland series implementations (others here can). The
>> ****tability between conforming ISO 7185 implementations is
>> outstanding.
>
> We already talked about the missing else/otherwise clause
> of the 'case' statement in the standard. I know about the
> solution with an 'if' statement around the 'case' but
> this is not a pretty solution. For some time I used
> programs with 'if' statements around the 'case' and
> else/otherwise clauses under comment so I could comment
> and uncomment to adjust to the Pascal compiler used.
> I had similar code variants for file handling, string
> management and other things. At the end I got tired of
> doing this adjustments and I switched to C.
There's a lot here.
1. else/otherwise.
Although pretty much every implementation of Pascal, and
the ISO 10206 standard for Pascal, defines an else/otherwise
clause (including IP Pascal), I used it for 20 years without
any case statements like that. There are good reasons that
the else/otherwise clause didn't make it into the original
language. A case statement is supposed to map efficiently to
a table lookup, and else/otherwise breaks that association.
In fact, it basically gives the user the idea that case is
a cuisineart that is good for stuffing anything one pleases
into.
I included else into IP Pascal case statements because:
A. Using hashed lookups, the handling of "sparse" case
lists was not expensive, and cases can be internally
redefined as a series of if-then-else statements in
any case.
B. In todays world, a going language has to interface to
a lot of code written in other languages, say C, and
C encourages sparse enumerations despite the lower
efficiency of their use.
As a result, you will find else clauses in my case statements
for IP Pascal interface directly with Windows and similar
operating systems. I never use it with pure Pascal code, for
the simple reason that Pascal dosen't need them, since it has
true consecutive enumeration.
2. File handling. This actually does not vary much at all,
unless you are talking about typeless files. Typeless files
destroy the fundamental idea in Pascal of type security, and
are unnecessary in any case. Unfortunately, C programmers have
been extensively brainwashed into thinking that typeless files
are necessary (along with massive uses of free type convertions
and free pointer coining).
If you are talking about file naming and assocation conventions
(i.e., assign()), then I would say you have a good point. Note
however that GPC, Delphi and IP Pascal all use the convention
of assign(f, name). Its a very good convention for reasons I
won't go into just now.
3. String management. Errr, C does not actually have strings
as a built in concept. They are added via libraries, standard
or otherwise.
I also believe that strings should not be a standard construct
for the language, for the reason that there are too many
variations on what it means to have string data, and a super
general string type tends to create bloated code when used
for every problem that might be solved by a simpler string
handling method. This is the power of C, if you want, say,
strings that are any length with the length of the string
as part of it, then you can make that yourself.
4. Went to C.... I started programming in 1978 in all of
assembly language, Basic, C and Pascal. All of them have
strengths and weaknesses. Today I program pretty much
exclusively in C and Pascal (basic need not be, but pretty
much has become in modern implementations, a toy/beginners
overly generalized language). If it were not for type
security, I would probably switch entirely to C, so I think
I would be the last to try to argue for Pascal as a one-to-one
matchup with C.
I notice I am not the only one who feels like this, even
outside of the Pascal community. Java and C# are designed to
reintroduce type security back into a C like language.
>
>> There is always going to "a ****tability issue" with folks
>> who don't read the standards. Microsoft C products, a very
>> popular implementation of C, have their own special
>> constructs in C that are outside the standard. If you use
>> them, you are not ****table, and Microsoft certainly uses
>> them in their code.
>
> If you use Microsoft extensions/libraries you always
> use ****tability. That is exactly the reason these
> extensions/libraries are desined for.
I'm sorry, I didn't parse the above sentence (?). Are you
saying that use of Microsoft extensions makes you ****table?
How would that occur?
>
>> Finally, if you are interested in getting a series of
>> standard libraries for your language, thats certainly a good
>> goal.
>
> What areas should be covered by standard libraries?
>
>> But again, who has done that? What language? C?
>> The standard for C specifies the standard I/O library,
>> things like printf(), scanf(), etc.
>
> IIRC the functions guaranteed to be present in the C
> library are more numerous than the ones defined in
> standard Pascal. The area covered by the standard C library
> is IMHO also a little bit bigger.
Well, to start I would refer you back to the comment I made
above, which is to the effect that if you don't see any
reason not to use C, then you should be using C. I am a big
fan of the language, I picked up my first C book in 1978, and
was programming C under the first ever Unix on a microcomputer
(Unisoft Unix on the 68000 CPU) by 1980.
In fact, IP Pascal, from 1980 to 1990, was designed to be a
cross between Pascal and C, with procedures and functions
freely definable in library files, C style #includes, etc.
When I ****ted it over to the I80386, however, I had
rediscovered the im****tance of type security, so IP Pascal
today looks less like C and more like Mesa/Modula.
Any any case, the answer to your question about C libraries
vs. Pascal is as follows.
stdio is an external library description of the I/O that is
built into Pascal natively. So that library was not needed
in Pascal. It is certainly true that the formatting functions
used in I/O are useful in string contexts as well (placing
integer converted to ASCII in a string), which is why, for
example, IP Pascal and others have libraries that do that.
error.h etc. was thought by Pascals originator (Wirth) to
be inherently implementation dependent, and indeed the first
(CDC) implementation of Pascal had that. It simply was not
included in standard Pascal.
string.h I believe Wirth considered strings to be up to the
user, for the reason that users would implement different
string types. However, I believe the basis for not including
a standard library for this is the general difficulty of
establi****ng libraries in Pascal et all, due to inability
to (say), use variable length array parameters.
math.h Again, Pascal has this built in where C defines it
as an external library.
stdlib And here again the same reason. This includes things
like malloc() and free() which Pascal has built in.
stdargs There is no parallel for variable argument lists in
Pascal.
setjmp.h Unfortunately, again, this is built into Pascal
where it is external in C. Sorry to sound like a broken
record.
signal.h Agreed, no capability in Pascal. This was pretty
much an operating system function in any case.
time.h No Pascal capability.
limits.h Built into Pascal, a library in C.
So in the main, your complaint about "C has more libraries
than Pascal" appears to be overlooking the fact that Pascal
does not need those libraries, whereas C does. The two
languages implement standard functions in different ways.
>
>> Outside of that,
>> (for example sleep), there are many libraries for C, none
>> of them particularly standard.
>
> Many functions from POSIX can be found also at non UNIX
> operating systems.
And you can have a Posix library that works under Pascal. Further,
last time I checked, Posix is not part of the C standard.
>
> Greetings Thomas Mertes
There have been many complaints about C vs. Pascal over the
years. The article you linked "Pascal is not my favorite...."
is emblematic of them, and boils down to "Pascal is not
good because it is not C".
Honestly, I don't know why there is such a constant need t
compare the two languages. If you like C, use it. If you
like Pascal, but want it to look more like C, then you can
implement a C/Pascal amalgamation. Then, you have a language
that has the type security of C combined with the brevity of
Pascal.
Faced with that language, I would rather use C, but then I
would prefer to use unadulterated Pascal than either, so I
guess that makes me odd.
Scott
|
