pascal equivalent of python "sleep"
Sean McIlroy
i'm trying to brush up my pascal skills after considerable time away.
in python there's a function "sleep" that essentially means "count
your toes for <number> seconds". how does one say this in pascal?
peace
stm
CBFalconer
By reading the documentation that came with your Pascal system.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Sean McIlroy
freeware compiler: no documentation. sure do 'preciate the effort to
make me feel stupid, tho. thx.
Martin Liddle
<e5f3de37-bd7a-433f...@z24g2000prf.googlegroups.com>,
Sean McIlroy <sean_m...@yahoo.com> writes
>
>freeware compiler: no documentation. sure do 'preciate the effort to
>make me feel stupid, tho. thx.
>
--
Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way,
Staveley, Chesterfield, Derbyshire, S43 3TW.
Web site: <http://www.tynecomp.co.uk>.
thomas...@gmx.at
As you can see from the other answers, there
is no 'sleep' in standard Pascal. Therefore it
depends on your compiler and/or operating system.
The 'sleep' function itself has it's roots in the
C / UNIX world.
With such tings as 'sleep' and many other functionality
your program will depend on your Pascal compiler and
become unportable. This is a sad story. If you want
to write portable programs (which run under various
operating systems and compilers) you will have a hard
time doing it in Pascal. Pascal was my favorite language
for approx. 10 years. Such things as otherwise/else
clauses and file buffer variables not consistent between
different compilers make portability hard.
That I still admire Pascal's concepts can be seen
when you look at Seed7. The statements are in the
Pascal/Modula/Ada tradition. BTW. Seed7 does have a
'time.s7i' library which contains the types 'time' and
'duration' and the 'wait' function (which gets a
'duration' as parameter). So you can just do:
wait(1 . SECONDS);
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Marco van de Voort
(snip)
> With such tings as 'sleep' and many other functionality
> your program will depend on your Pascal compiler and
> become unportable. This is a sad story.
(snip)
> That I still admire Pascal's concepts can be seen
> when you look at Seed7.
It is really fatigueing to plug seed7 as a resolution for inter-compiler
compability if there is only one implementation of seed(n)
thomas...@gmx.at
I did not plug Seed7 as a solution for incompatible
Pascal dialects. The beginning of the mail contains
information about the 'sleep' function and the
paragraph about Pascal and portability can also be
helpful. The last paragraph should just show that
although I am a critic of Pascal I do not hate it.
IMHO the number of implementations does not play a role
for portability. C has many implementations and the
portability 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
portability. 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
You are right that there is currently only one
implementation of Seed7, but this implementation
runs on various operating systems (unix, bsd, linux
windows) on different hardware and with several C
compilers. Additionally this implementation is open
source (GPL) and therefore can be used to port Seed7
to even more places. I tried to reach that level of
portability with Pascal (a predecessor of the current
Seed7 interpreter was implemented in Pascal) and
failed tatally because of the incompatible Pascal
dialects.
A compiler is not the end of the story about
portability, but just the beginning. You need also
portable libraries for various areas. I admit that
many libraries are still missing in Seed7, but at
least something (strings, resizeable arrays, hash tables,
large bitsets, big integers, rationals, complex, time,
duration, portable graphics, reflection) is there.
I guess that at least some of this libraries are not
available in Standard Pascal. And it makes a difference
if a feature is present in some implementation or is
granted to be always present.
The license plays also a role. The best library
does not help when it is not usable with another
compiler or operating system.
Marco van de Voort
>> (snip)
>>
>> > With such tings as 'sleep' and many other functionality
>> > your program will depend on your Pascal compiler and
>> > become unportable. This is a sad story.
>>
>> (snip)
>>
>> > That I still admire Pascal's concepts can be seen
>> > when you look at Seed7.
>>
>> It is really fatigueing to plug seed7 as a resolution for inter-compiler
>> compability if there is only one implementation of seed(n)
>
> I did not plug Seed7 as a solution for incompatible
> Pascal dialects
Then for what did you plug it?
> The beginning of the mail contains
> information about the 'sleep' function and the
> paragraph about Pascal and portability can also be
> helpful.
Was already posted.
> The last paragraph should just show that although I am a critic of Pascal
> I do not hate it.
> IMHO the number of implementations does not play a role
> for portability
No but it is needed for standard purposes. Since there is no need for a
standards without. (ok, maybe for compat between versions, but that is
already a magnitude less important)
> C has many implementations and the
> portability problems which exist in Pascal are simply
> not present.
Then find a sleep() in a strictly conforming C compiler! You won't find it,
it is POSIX, not C. (not to forget that even then there are several, and
various implementations have varying units for the arguments, from ns to
seconds)
> 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
> portability.
That is IMHO revisionism. The early C code was a dirty as Pascal. Still to
this day, most of the C++ code is intrinsically tied to a certain VS
version.
And even for basic stuff Simply because only the more recent POSIX standards unified this kind of
behaviour, and the non (Open Source) Unix state is still doubtful at best.
> 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
Which is IMHO incorrect. And even if there ever was truth about it, it
ceased after the first half of the eighties.
Pascal was simply popular at an earlier state, while C was still tied to
Unix.
> You are right that there is currently only one
> implementation of Seed7, but this implementation
> runs on various operating systems (unix, bsd, linux
> windows) on different hardware and with several C
> compilers.
Windows= Windows 32/64/ce ?
> Additionally this implementation is open
> source (GPL) and therefore can be used to port Seed7
> to even more places. I tried to reach that level of
> portability with Pascal (a predecessor of the current
> Seed7 interpreter was implemented in Pascal) and
> failed tatally because of the incompatible Pascal
> dialects.
Or , actually more a multitarget compiler. Strike out gcc, and see how far you get with C.
Luckily there is now FPC (and even GPC would already target all those)
Scott Moore
> With such tings as 'sleep' and many other functionality
> your program will depend on your Pascal compiler and
> become unportable. This is a sad story. If you want
> to write portable programs (which run under various
> operating systems and compilers) you will have a hard
> time doing it in Pascal. Pascal was my favorite language
> for approx. 10 years. Such things as otherwise/else
> clauses and file buffer variables not consistent between
> different compilers make portability hard.
Whoa there. Is "sleep" a built in function for C/C++?
Ada? Fortran? Java? Any other language?
How is it a problem with Pascal?
Scott Moore
> IMHO the number of implementations does not play a role
> for portability. C has many implementations and the
> portability 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
> portability. 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.
I cannot comment on the portability of programs between
the Borland series implementations (others here can). The
portability between conforming ISO 7185 implementations is
outstanding.
There is always going to "a portability 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 portable, and Microsoft certainly uses
them in their code.
Finally, if you are interested in getting a series of
standard libraries for your language, thats certainly a good
goal. But again, who has done that? What language? C?
The standard for C specifies the standard I/O library,
things like printf(), scanf(), etc. Outside of that,
(for example sleep), there are many libraries for C, none
of them particularly standard.
Scott
thomas...@gmx.at
> On 2008-05-08, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>
> >> (snip)
>
> >> > With such tings as 'sleep' and many other functionality
> >> > your program will depend on your Pascal compiler and
> >> > become unportable. This is a sad story.
>
> >> (snip)
>
> >> > That I still admire Pascal's concepts can be seen
> >> > when you look at Seed7.
>
> >> It is really fatigueing to plug seed7 as a resolution for inter-compiler
> >> compability if there is only one implementation of seed(n)
>
> > I did not plug Seed7 as a solution for incompatible
> > Pascal dialects
>
> Then for what did you plug it?
To give you a chance to complain about it.
> > The beginning of the mail contains
> > information about the 'sleep' function and the
> > paragraph about Pascal and portability can also be
> > helpful.
>
> Was already posted.
The next time I will ask for your permission.
> > The last paragraph should just show that although I am a critic of Pascal
> > I do not hate it.
> > IMHO the number of implementations does not play a role
> > for portability
>
> No but it is needed for standard purposes. Since there is no need for a
> standards without. (ok, maybe for compat between versions, but that is
> already a magnitude less important)
>
> > C has many implementations and the
> > portability problems which exist in Pascal are simply
> > not present.
>
> Then find a sleep() in a strictly conforming C compiler!
Surprise you will not find a function like C in a C compiler.
The C functions are part of a library and not of the compiler.
> You won't find it,
> it is POSIX, not C. (not to forget that even then there are several, and
> various implementations have varying units for the arguments, from ns to
> seconds)
The sleep's that I know use seconds. IIRC there is a 'Sleep'
under windows which should not be confused with 'sleep'.
> > 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
> > portability.
>
> That is IMHO revisionism. The early C code was a dirty as Pascal. Still to
> this day, most of the C++ code is intrinsically tied to a certain VS
> version.
When you say it, it will be so.
> And even for basic stuff Simply because only the more recent POSIX standards unified this kind of
> behaviour, and the non (Open Source) Unix state is still doubtful at best.
>
> > 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
>
> Which is IMHO incorrect. And even if there ever was truth about it, it
> ceased after the first half of the eighties.
You obviously did not read the article.
> Pascal was simply popular at an earlier state, while C was still tied to
> Unix.
>
> > You are right that there is currently only one
> > implementation of Seed7, but this implementation
> > runs on various operating systems (unix, bsd, linux
> > windows) on different hardware and with several C
> > compilers.
>
> Windows= Windows 32/64/ce ?
Just try it.
> > Additionally this implementation is open
> > source (GPL) and therefore can be used to port Seed7
> > to even more places. I tried to reach that level of
> > portability with Pascal (a predecessor of the current
> > Seed7 interpreter was implemented in Pascal) and
> > failed tatally because of the incompatible Pascal
> > dialects.
>
> Or , actually more a multitarget compiler. Strike out gcc, and see how far you get with C.
The Seed7 implementation does not need the gcc.
> Luckily there is now FPC (and even GPC would already target all those)
So you can be happy.
thomas...@gmx.at
> thomas.mer...@gmx.at wrote:
> > IMHO the number of implementations does not play a role
> > for portability. C has many implementations and the
> > portability 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
> > portability. 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...
> I cannot comment on the portability of programs between
> the Borland series implementations (others here can). The
> portability 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 is always going to "a portability 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 portable, and Microsoft certainly uses
> them in their code.
If you use Microsoft extensions/libraries you always
use portability. That is exactly the reason these
extensions/libraries are desined for.
> 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.
> 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.
thomas...@gmx.at
> thomas.mer...@gmx.at wrote:
> > With such tings as 'sleep' and many other functionality
> > your program will depend on your Pascal compiler and
> > become unportable. This is a sad story. If you want
> > to write portable programs (which run under various
> > operating systems and compilers) you will have a hard
> > time doing it in Pascal. Pascal was my favorite language
> > for approx. 10 years. Such things as otherwise/else
> > clauses and file buffer variables not consistent between
> > different compilers make portability hard.
>
> Whoa there. Is "sleep" a built in function for C/C++?
The term "built in function" is not used very much
outside the Pascal world (except for compiler optimisation
where fuctions of a library are replaced with
build in functions (some inline code)).
Marco van de Voort
> 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.
(brr, that's a bold statement. IMHO it doesn't even implement Turbo Pascal
complete. It has some Delphi 2 features, that is about it.)
> I cannot comment on the portability of programs between
> the Borland series implementations (others here can).
Borland internal backward portability is ok, forward requires not
to use newer features.
FPC<->Borland is quite OK, even visual code can be converted easily. Most of
the porting effort is slowly "good habits" with respect to multi-platform.
The crossplatform compability is something different.
> The portability between conforming ISO 7185 implementations is
> outstanding.
Isn't that the same problem as with C? That the guaranteed set of libraries
is so very small?
> There is always going to "a portability 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 portable, and Microsoft certainly uses
> them in their code.
MS is cleaning up, and it is not that the other vendors don't have
own libs and constructs.
MS gets a lot of flak because it is simply the default platform, and the
hordes of programmers on it start programs without any crossplatform
consideration, not even with a minimal modularization or layering to ease
it.
I'm not a MS fanboy, but I recognize the situation because when porting
code from Delphi to FPC one often faces the same problem.
Marco van de Voort
>> >> compability if there is only one implementation of seed(n)
>>
>> > I did not plug Seed7 as a solution for incompatible
>> > Pascal dialects
>>
>> Then for what did you plug it?
>
> To give you a chance to complain about it.
Oh, I thought it was for all your users in this group.
>> Was already posted.
>
> The next time I will ask for your permission.
Please do.
>> > C has many implementations and the
>> > portability problems which exist in Pascal are simply
>> > not present.
>>
>> Then find a sleep() in a strictly conforming C compiler!
>
> Surprise you will not find a function like C in a C compiler.
A conforming C compiler is compiler + its std libraries, as they are
specified by the standard.
> The C functions are part of a library and not of the compiler.
But a subset of content is specified by the standard.
>> You won't find it, it is POSIX, not C. (not to forget that even then
>> there are several, and various implementations have varying units for the
>> arguments, from ns to seconds)
>
> The sleep's that I know use seconds.
> IIRC there is a 'Sleep' under windows which should not be confused with
> 'sleep'.
I haven't been able to find a lowercase sleep() in msdn.
>> > 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
>>
>> Which is IMHO incorrect. And even if there ever was truth about it, it
>> ceased after the first half of the eighties.
>
> You obviously did not read the article.
I've read and discussed it many times. It is often brought up by trolls that
fail to set it in its proper historic setting.
>> > You are right that there is currently only one implementation of Seed7,
>> > but this implementation runs on various operating systems (unix, bsd,
>> > linux windows) on different hardware and with several C compilers.
>>
>> Windows= Windows 32/64/ce ?
>
> Just try it.
If you can't be bothered to specify, I can't be bothered to find, so I
assume win32/x86 only.
Marco van de Voort
> 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.
Maybe. I never counted both, but the difference is not even close as a basis
for C's "portability".
>> 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.
In some form or the other, if you interface or emulate them yes. However it
doesn't matter if you do that from C or Pascal.
thomas...@gmx.at
> On 2008-05-08, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>
> >> >> It is really fatigueing to plug seed7 as a resolution for inter-compiler
> >> >> compability if there is only one implementation of seed(n)
>
> >> > I did not plug Seed7 as a solution for incompatible
> >> > Pascal dialects
>
> >> Then for what did you plug it?
>
> > To give you a chance to complain about it.
>
> Oh, I thought it was for all your users in this group.
>
> >> Was already posted.
>
> > The next time I will ask for your permission.
>
> Please do.
Sorry, I just decided not to do.
> >> > C has many implementations and the
> >> > portability problems which exist in Pascal are simply
> >> > not present.
>
> >> Then find a sleep() in a strictly conforming C compiler!
>
> > Surprise you will not find a function like C in a C compiler.
>
> A conforming C compiler is compiler + its std libraries, as they are
> specified by the standard.
>
> > The C functions are part of a library and not of the compiler.
>
> But a subset of content is specified by the standard.
Yes
> >> You won't find it, it is POSIX, not C. (not to forget that even then
> >> there are several, and various implementations have varying units for the
> >> arguments, from ns to seconds)
>
> > The sleep's that I know use seconds.
> > IIRC there is a 'Sleep' under windows which should not be confused with
> > 'sleep'.
>
> I haven't been able to find a lowercase sleep() in msdn.
Ok, but AFAIK the 'sleep' function - when available - uses
seconds as parameter.
> >> > 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
>
> >> Which is IMHO incorrect. And even if there ever was truth about it, it
> >> ceased after the first half of the eighties.
>
> > You obviously did not read the article.
>
> I've read and discussed it many times. It is often brought up by trolls that
> fail to set it in its proper historic setting.
Well, the article also contains points which are still
valid... But if you think that I am a troll, who just
tries to provoke diskussions, you are at the wrong lane.
> >> > You are right that there is currently only one implementation of Seed7,
> >> > but this implementation runs on various operating systems (unix, bsd,
> >> > linux windows) on different hardware and with several C compilers.
>
> >> Windows= Windows 32/64/ce ?
>
> > Just try it.
>
> If you can't be bothered to specify, I can't be bothered to find, so I
> assume win32/x86 only.
I have not tried windows 64/ce therefore I cannot
tell about that.
thomas...@gmx.at
> On 2008-05-08, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>
> > 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.
>
> Maybe. I never counted both, but the difference is not even close as a basis
> for C's "portability".
That is one opinion, but not my opinion.
I suggest your talk about that with people who know
both languages and their libraries inside out.
> >> 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.
>
> In some form or the other, if you interface or emulate them yes. However it
> doesn't matter if you do that from C or Pascal.
As I explaind already, my critical points about Pascal's
portability start with the language itself (else/otherwise
clause for case statements, file buffer variables, and
other stuff). OTOH in C there are not such issues (as long
as you refrain from using Microsofts (and others) extensions).
IMHO avoiding extensions of the language in C is easy while
in Pascal it is sometimes unavoidable.
Just to show that I do not see C as perfect language.
I have a lot of critical points about C:
- Not very intuitive syntax for declarations
(specially when pointers are involved)
- "interesting" implicit cast logic
- The size of 'int' and 'long' is not specified
in the standard (I know that it can be obtained
but that is something different).
- division operators (/ and %) which allow two
implementations if negative values are involved
(at least according to the C89 standard, I have not
found a C compiler that uses this freedom)
- and much more
Marco van de Voort
>> > is IMHO also a little bit bigger.
>>
>> Maybe. I never counted both, but the difference is not even close as a basis
>> for C's "portability".
>
> That is one opinion, but not my opinion.
> I suggest your talk about that with people who know
> both languages and their libraries inside out.
Well, I base myself on K & R (appendix C of the 2nd edition to be exact). I
count 100 calls tops (and that includes some limit constants). Aside from
basic file I/O (which is the roughly the same subset in Pascal) I count
gettime, system() and signal as the other OS wrapping functions (of which
signal is not implemented on non Unices, or only for runtime internal
exceptions)
I couldn't do the same quickly for pascal, but my guestimate would be 40-50
calls (built-ins inclusive). So it boils all down to gettime, system and
signal?
>> In some form or the other, if you interface or emulate them yes. However it
>> doesn't matter if you do that from C or Pascal.
>
> As I explaind already, my critical points about Pascal's
> portability start with the language itself (else/otherwise
> clause for case statements,
That is a dialect question, not portability. And it is not that strange in C
land either (mixing prototypes with original K&R C, dialects that consider
void * compatible with any pointer, vs the ones that still use char * for
that)
> file buffer variables
What exactly?
> OTOH in C there are not such
> issues (as long as you refrain from using Microsofts (and others)
> extensions).
Well, see above. C hasn't been constant in the history also. The MS
extensions are often just that, pre-standard implementations that deviate
from the final standard.
> IMHO avoiding extensions of the language in C is easy while
> in Pascal it is sometimes unavoidable.
You point to few original sources or own research for that conclusion. You
might be right, but I don't have the information to reach the same
conclusion.
Scott Moore
> On 8 Mai, 18:08, Scott Moore <sam...@moorecad.com> wrote:
>> thomas.mer...@gmx.at wrote:
>>> IMHO the number of implementations does not play a role
>>> for portability. C has many implementations and the
>>> portability 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
>>> portability. 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 classes, 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 portability of programs between
>> the Borland series implementations (others here can). The
>> portability 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 portability 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 portable, and Microsoft certainly uses
>> them in their code.
>
> If you use Microsoft extensions/libraries you always
> use portability. 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 portable?
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 ported it over to the I80386, however, I had
rediscovered the importance 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
establishing 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
Scott Moore
> On 2008-05-08, Scott Moore <sam...@moorecad.com> wrote:
>> 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.
>
> (brr, that's a bold statement. IMHO it doesn't even implement Turbo Pascal
> complete. It has some Delphi 2 features, that is about it.)
I'll bow to your expertise here. The last time I talked to the
GPC group, they were going hog wild for TP compatability.
>
>> I cannot comment on the portability of programs between
>> the Borland series implementations (others here can).
>
> Borland internal backward portability is ok, forward requires not
> to use newer features.
>
> FPC<->Borland is quite OK, even visual code can be converted easily. Most of
> the porting effort is slowly "good habits" with respect to multi-platform.
>
> The crossplatform compability is something different.
Which goes back to the library issue that Mr. Mertes is on about.
>
>> The portability between conforming ISO 7185 implementations is
>> outstanding.
>
> Isn't that the same problem as with C? That the guaranteed set of libraries
> is so very small?
>
>> There is always going to "a portability 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 portable, and Microsoft certainly uses
>> them in their code.
>
> MS is cleaning up, and it is not that the other vendors don't have
> own libs and constructs.
>
> MS gets a lot of flak because it is simply the default platform, and the
> hordes of programmers on it start programs without any crossplatform
> consideration, not even with a minimal modularization or layering to ease
> it.
>
> I'm not a MS fanboy, but I recognize the situation because when porting
> code from Delphi to FPC one often faces the same problem.
>
My biggest issue with Microsoft is that they wrote the Windows header
files using their own custom C extentions, and in many cases they didn't
even need to do that, it was just gratuitous use of their custom
features. That is why IP Pascal's chtoph program has a /microsoft flag.
Scott
CBFalconer
>
... snip ...
>
> IMHO the number of implementations does not play a role for
> portability. C has many implementations and the portability
> 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 portability. 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
The portability problem is not because of various extensions to
Pascal, but largely due to the failure to implement the Pascal
standard in the first place. Borland is the worst cause of this.
Notably they failed to implement f^, get, and put in the i/o area.
There are also many other evil gotchas.
There is no excuse for any Pascal system failing to mee ISO7185.
CBFalconer
> CBFalconer <cbfalco...@yahoo.com> wrote:
>> Sean McIlroy wrote:
>>
>>> i'm trying to brush up my pascal skills after considerable time away.
>>> in python there's a function "sleep" that essentially means "count
>>> your toes for <number> seconds". how does one say this in pascal?
>>
>> By reading the documentation that came with your Pascal system.
>
> make me feel stupid, tho. thx.
The point is that there is no such function as 'sleep' in the
Pascal standard. So where else do you expect to find its
documentation?
CBFalconer
> Scott Moore <sam...@moorecad.com> wrote:
>
... snip ...
>
>> 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...
No. There are Pascals that adhere to the standard (ISO 7185), such
as GPC. There are quasi-Pascals that fail to implement the
standard, and cause trouble, such as Borland.
thomas...@gmx.at
> On 2008-05-08, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>
> >> > standard Pascal. The area covered by the standard C library
> >> > is IMHO also a little bit bigger.
>
> >> Maybe. I never counted both, but the difference is not even close as a basis
> >> for C's "portability".
>
> > That is one opinion, but not my opinion.
> > I suggest your talk about that with people who know
> > both languages and their libraries inside out.
>
> Well, I base myself on K & R (appendix C of the 2nd edition to be exact).
That is a good C reference. For a portable Pascal the ISO 7185
Pascal (available here: http://www.standardpascal.org/iso7185.html)
minus the things that are not available under Borland Pascal/Delphi
must be used (this is descibed as answer to "Is it possible to write
in a Pascal subset that will be acceptable to both ISO 7185 Pascal
and Delphi?" here: http://www.standardpascal.org/pascalfaq.html)
> I count 100 calls tops (and that includes some limit constants). Aside
> from basic file I/O (which is the roughly the same subset in Pascal)
Well not exactly. What about 'remove', 'rename', 'fseek', 'ftell'?
AFAICS ISO 7185 Pascal does not contain something equivalent.
The string functions of string.h are ugly but better than nothing.
In ISO 7185 Pascal I did not find string functions at all (I know
that the type 'string' is common in various Pascal dialects, but
AFAICS there is none in the standard. The include file math.h
contains more trigonometric functions than standard Pascal.
What about rand, malloc, realloc, getenv, bsearch, qsort.
I am sure that there are similar functions available in every
dialect of Pascal, but seemingly not in the standard. The functions
setjmp and longjmp can be used to emulate an exception handling
that is missing in C and standard Pascal. You already mentioned
signal.h and time.h which can also be useful.
> I count gettime, system() and signal as the other OS wrapping
> functions (of which signal is not implemented on non Unices, or
> only for runtime internal exceptions)
At least under windows the signal handling is present.
Additionally many POSIX functions are ported to different
operating systems as well (Ok, they are not granted to be
available, but the probability to find them is not zero
and they usually use a C interface).
> I couldn't do the same quickly for pascal, but my guestimate would be 40-50
> calls (built-ins inclusive). So it boils all down to gettime, system and
> signal?
Not really as shown above.
BTW. A quick look at the Seed7 documentation of the predefined
types (at: http://seed7.sourceforge.net/manual/types.htm)
revealed that they define
100 operators (like + - * / div, rem, mdiv, mod, and, or, not)
84 relations (like < > <= >= = <>)
192 functions (like pred, succ, abs, atan2, compare, hashCode)
79 statements and procedures (like read, write, for)
19 assignment statements ( := )
For this list I examined only the types
boolean, integer, bigInteger, rational, bigRational, float, char,
string, array, hash, set, struct, ptr, enumeration, color, time
duration, file and text.
I did not take into account other stuff like
reflection, graphics, scanner, charsets, directory,
file management and more.
Compared to standard C and standard Pascal the size of the Seed7
library is not bad (But there is still much room for improvement).
> >> In some form or the other, if you interface or emulate them yes. However it
> >> doesn't matter if you do that from C or Pascal.
>
> > As I explaind already, my critical points about Pascal's
> > portability start with the language itself (else/otherwise
> > clause for case statements,
>
> That is a dialect question, not portability. And it is not that strange in C
> land either (mixing prototypes with original K&R C, dialects that consider
> void * compatible with any pointer, vs the ones that still use char * for
> that)
>
> > file buffer variables
>
> What exactly?
I was speaking of f^ and the procedures 'get' and 'put' which are
AFAIK not present under Delphi.
> > OTOH in C there are not such
> > issues (as long as you refrain from using Microsofts (and others)
> > extensions).
>
> Well, see above. C hasn't been constant in the history also. The MS
> extensions are often just that, pre-standard implementations that deviate
> from the final standard.
>
> > IMHO avoiding extensions of the language in C is easy while
> > in Pascal it is sometimes unavoidable.
>
> You point to few original sources or own research for that conclusion. You
> might be right, but I don't have the information to reach the same
> conclusion.
I hope that there are more links to original sources this time.
Florian....@gmail.com
>
> > I couldn't do the same quickly for pascal, but my guestimate would be 40-50
> > calls (built-ins inclusive). So it boils all down to gettime, system and
> > signal?
>
> Not really as shown above.
> BTW. A quick look at the Seed7 documentation of the predefined
There is no ISO standard or whatever standard for Seed7, so I don't
see the point.
Scott Moore
> dialect of Pascal, but seemingly not in the standard. The functions
> setjmp and longjmp can be used to emulate an exception handling
> that is missing in C and standard Pascal. You already mentioned
This is provided by interprocedure gotos in Pascal.
> Not really as shown above.
> BTW. A quick look at the Seed7 documentation of the predefined
> types (at: http://seed7.sourceforge.net/manual/types.htm)
> revealed that they define
>
> 100 operators (like + - * / div, rem, mdiv, mod, and, or, not)
> 84 relations (like < > <= >= = <>)
> 192 functions (like pred, succ, abs, atan2, compare, hashCode)
> 79 statements and procedures (like read, write, for)
> 19 assignment statements ( := )
>
No argument. Pascal loses in any contest of language complexity
and number of declared standard functions. Hands down.
Scott
Marco van de Voort
>> Not really as shown above.
>> BTW. A quick look at the Seed7 documentation of the predefined
>> types (at: http://seed7.sourceforge.net/manual/types.htm)
>> revealed that they define
>>
>> 100 operators (like + - * / div, rem, mdiv, mod, and, or, not)
>> 84 relations (like < > <= >= = <>)
>> 192 functions (like pred, succ, abs, atan2, compare, hashCode)
>> 79 statements and procedures (like read, write, for)
>> 19 assignment statements ( := )
>>
>
> No argument. Pascal loses in any contest of language complexity
> and number of declared standard functions. Hands down.
I think Scott gets the bonus points for this one. Despite it not being true.
Marco van de Voort
>
> The term "built in function" is not used very much
> outside the Pascal world (except for compiler optimisation
> where fuctions of a library are replaced with
> build in functions (some inline code)).
Not really. Even C has them. sizeof() is a built in (pseudo) function in C.
strlen is now also often built-in.
Any function (from a semantic pov) for which you can't pinpoint a routine in
the runtime libraries is a built in.
Marco van de Voort
>> Well, I base myself on K & R (appendix C of the 2nd edition to be exact).
>
> That is a good C reference. For a portable Pascal the ISO 7185
> Pascal (available here: http://www.standardpascal.org/iso7185.html)
> minus the things that are not available under Borland Pascal/Delphi
> must be used (this is descibed as answer to "Is it possible to write
> in a Pascal subset that will be acceptable to both ISO 7185 Pascal
> and Delphi?" here: http://www.standardpascal.org/pascalfaq.html)
I do not agree that these are the same thing. You are comparing intra
standard compability of C to inter standard compability (giving Borland that
credit for arguments state) on Pascal.
>> I count 100 calls tops (and that includes some limit constants). Aside
>> from basic file I/O (which is the roughly the same subset in Pascal)
>
> Well not exactly. What about 'remove', 'rename', 'fseek', 'ftell'?
Simply a result of definition at a different time, when the file concept was
less used. Same with why both don't support GUI, while that is also
considered pretty universal today. Or thread suport, or, or, or.
The point is that you can bicker about C having a handful of functions more
or less, but it is a far, far cry of the number of calls needed to write a
modern app TODAY. And if subset A is 0.1% of the calls, and B 0.2% is
irrelevant.
And I don't have enough time to start a yes/no discussion about every one of
them, so I skip them.
Marco van de Voort
>>> 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.
>>
>> (brr, that's a bold statement. IMHO it doesn't even implement Turbo Pascal
>> complete. It has some Delphi 2 features, that is about it.)
>
> I'll bow to your expertise here. The last time I talked to the
> GPC group, they were going hog wild for TP compatability.
To my knowledge they still don't support a TP (or Macpascal UCSD-like)
compatible string, and require rewrites to schemata or using helper
functions.
Being able to rewrite TP code is not "tp compatible".
I'm also not entirely sure if their isolation of units/modules is 100% and
qualification with unit names. But it is a lot longer ago that I asked that,
contrary to the TP/ucsd string stuff that turns up in the macpascal list
regularly.
(I followed GPC till a few years ago, a friend kept part of a TP/FPC app
working on Solaris/Sparc, what FPC didn't do)
Afaik the delphi support is the most basic minimal "class" concept and some
routines added to the runtime. Note that Delphi compability is pretty hard,
since the minimal subset to compile an existing Delphi codebase is fairly
big.
It is hard to say what the state is, since the maillist doesn't have much updates
over new development and the site is from 2005.
>> FPC<->Borland is quite OK, even visual code can be converted easily. Most of
>> the porting effort is slowly "good habits" with respect to multi-platform.
>>
>> The crossplatform compability is something different.
>
> Which goes back to the library issue that Mr. Mertes is on about.
Yes. But that is with any compiler system that is popular. The hordes don't value
compability, they just heap code together.
>> MS is cleaning up, and it is not that the other vendors don't have
>> own libs and constructs.
>>
>> MS gets a lot of flak because it is simply the default platform, and the
>> hordes of programmers on it start programs without any crossplatform
>> consideration, not even with a minimal modularization or layering to ease
>> it.
>>
>> I'm not a MS fanboy, but I recognize the situation because when porting
>> code from Delphi to FPC one often faces the same problem.
>
> My biggest issue with Microsoft is that they wrote the Windows header
> files using their own custom C extentions, and in many cases they didn't
> even need to do that, it was just gratuitous use of their custom
> features. That is why IP Pascal's chtoph program has a /microsoft flag.
Hmm, I actually are quite fond of MS headers, because they are generally
very clean (their macro usage is simpler and less convoluted than e.g. glibc
headers).
Which extensions exactly? guid and interface related ? I'm biassed there :-)
thomas...@gmx.at
Yes there is no standard for it. I was just curious to
count how many functions are guaranteed to be available
in Seed7 compared to Pascal and C.
Florian....@gmail.com
> On 9 Mai, 19:43, Florian.Klaem...@gmail.com wrote:
>
> > On 9 Mai, 17:24, thomas.mer...@gmx.at wrote:
>
> > > > I couldn't do the same quickly for pascal, but my guestimate would be 40-50
> > > > calls (built-ins inclusive). So it boils all down to gettime, system and
> > > > signal?
>
> > > Not really as shown above.
> > > BTW. A quick look at the Seed7 documentation of the predefined
>
> > There is no ISO standard or whatever standard for Seed7, so I don't
> > see the point.
>
> Yes there is no standard for it. I was just curious to
> count how many functions are guaranteed to be available
> in Seed7 compared to Pascal and C.
A standard is usually the smallest common denominator. So as long
as there is no Seed7 standard, this comparisation is pretty useless. I
could
compare it then also with the Delphi flavour of Pascal which is even
implemented
by 2 compilers.
thomas...@gmx.at
:-)
I would say that the number of available functions is not
necessarily a sign of complexity. The Seed7 interpreter
and the compiler are both much bigger than the P4 and
even the Pascal 6000 compiler. OTOH most of the parsing
in Pascal compilers is usually hard wired in the compiler,
while almost all of the syntax and semantic analysis in
Seed7 is data structure driven and configurable at compile
time (otherwise user defined statements and operators
would just not be possible).
So it is an apples to oranges comparison. Simplicity and
elegance of design aggainst flexibility to define new
constructs in a wide range.
There are similarities as well: All the data structure
driven syntactic and semantic analysis of Seed7 programs
is done with LL(1). That would be exactly in the Pascal
tradition and allows the Seed7 interpreter to analyze
a program (the process necessary to generate an internal
representation which can be interpreted) with approx.
200000 lines per second.
thomas...@gmx.at
> On 2008-05-09, thomas.mer...@gmx.at <thomas.mer...@gmx.at> wrote:
>
> >> Well, I base myself on K & R (appendix C of the 2nd edition to be exact).
>
> > That is a good C reference. For a portable Pascal the ISO 7185
> > Pascal (available here:http://www.standardpascal.org/iso7185.html)
> > minus the things that are not available under Borland Pascal/Delphi
> > must be used (this is descibed as answer to "Is it possible to write
> > in a Pascal subset that will be acceptable to both ISO 7185 Pascal
> > and Delphi?" here:http://www.standardpascal.org/pascalfaq.html)
>
> I do not agree that these are the same thing. You are comparing intra
> standard compability of C to inter standard compability (giving Borland that
> credit for arguments state) on Pascal.
I thought that because of marked share Borland must be
taken into account. It's the view when you come to a
computer with your software and you get told: This is
our Pascal compiler which we use for everything. Can
you use it as well (because it is the only one)?
> >> I count 100 calls tops (and that includes some limit constants). Aside
> >> from basic file I/O (which is the roughly the same subset in Pascal)
>
> > Well not exactly. What about 'remove', 'rename', 'fseek', 'ftell'?
>
> Simply a result of definition at a different time, when the file concept was
> less used. Same with why both don't support GUI, while that is also
> considered pretty universal today. Or thread suport, or, or, or.
Aggree. I have more to add: Database support, networking,
compression, xml, html, and much more. There are many areas
that should be supported in libraries for todays languages.
IMHO libraries get more important while core languages get
less important. I try to take this into account, but writing
libraries for all these areas takes time.
> The point is that you can bicker about C having a handful of functions more
> or less, but it is a far, far cry of the number of calls needed to write a
> modern app TODAY. And if subset A is 0.1% of the calls, and B 0.2% is
> irrelevant.
At the time when I switched from Pascal to C the percentages
where probably different. For todays percentates I would use
higer values, but essencially you are right.
> And I don't have enough time to start a yes/no discussion about every one of
> them, so I skip them.
IMHO it is not necessary to go into details. The big picture
is more important.
Waldek Hebisch
> >>> 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.
> >>
> >> (brr, that's a bold statement. IMHO it doesn't even implement Turbo Pascal
> >> complete. It has some Delphi 2 features, that is about it.)
> >
> > I'll bow to your expertise here. The last time I talked to the
> > GPC group, they were going hog wild for TP compatability.
>
> To my knowledge they still don't support a TP (or Macpascal UCSD-like)
> compatible string, and require rewrites to schemata or using helper
> functions.
>
> Being able to rewrite TP code is not "tp compatible".
>
If you want to take random TP code and just compile it, than this
is unlikely to give desired effect -- you need to "rewrite" code.
But this is not much different than what happens with other
languages (like C). In my experience relatively small changes
were enough to get code working with GPC, so from my point of
view GPC is "compatible enough". OTOH I do not claim that
GPC is "100% tp compatible" -- there are known differences and
for some folks they can matter a lot.
> I'm also not entirely sure if their isolation of units/modules is 100% and
> qualification with unit names. But it is a lot longer ago that I asked that,
> contrary to the TP/ucsd string stuff that turns up in the macpascal list
> regularly.
>
I belive that you mention old, solved problem -- starting form February
2005 GPC properly mangles names in object files so that clashes are
impossible.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Marco van de Voort
>> To my knowledge they still don't support a TP (or Macpascal UCSD-like)
>> compatible string, and require rewrites to schemata or using helper
>> functions.
>>
>> Being able to rewrite TP code is not "tp compatible".
>
> If you want to take random TP code and just compile it, than this
> is unlikely to give desired effect -- you need to "rewrite" code.
I don't mind that, but I expect that to be in the unportable aspects like
16-bitisms and dosisms, not in the basic language support like strings.
> But this is not much different than what happens with other
> languages (like C).
I do not understand this part. Which basic language features are not
supported by newer compilers?
> In my experience relatively small changes were enough to get code working
> with GPC, so from my point of view GPC is "compatible enough". OTOH I do
> not claim that GPC is "100% tp compatible" -- there are known differences
> and for some folks they can matter a lot.
The situation is clear now. That's all what counts. I already hinted already
on a little gap in the info from GPC. Could you give an update what is
happening there?
I see some newer sets of OS X patches, anything else going
on? More Delphi compat meanwhile?
>> I'm also not entirely sure if their isolation of units/modules is 100% and
>> qualification with unit names. But it is a lot longer ago that I asked that,
>> contrary to the TP/ucsd string stuff that turns up in the macpascal list
>> regularly.
>
> I belive that you mention old, solved problem -- starting form February
> 2005 GPC properly mangles names in object files so that clashes are
> impossible.
Clear. I knew it might be old, which is why I also annotated that my opinion
was possibly old.
Marco van de Voort
>
> 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.
It used to call it object pascal till circa D6-D7 afaik. My D4 language
manual has "Object Pascal" on the cover).
After that they renamed it to "the Delphi language". Note that afaik it was
not due to standarization or compability, but rather the "old" association
that managers had with the term "Pascal".
> 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.
Pocket Studio, VP and FPC aren't. Afaik TopSpeed supported neither fully.
> 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.
(in Delphi assign is deprecated, to avoid nameclashes with a assign method
(which afaik is similar in function Java's). Assignfile is the new name)
> 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,
While I agree there are downsides to string support (Delphi having 20
stringtypes or types that convert to strings, and probably adding several
more with the next major version due to new non-COM unicode support), that
IMHO doesn't necessarily mean no string support is a virtue.
An automated type avoids quite some labour, and potential errors for run of
the mill business code.
> 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
> establishing libraries in Pascal et all, due to inability
> to (say), use variable length array parameters.
The array packing systems might also be a reason?
>> 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.
Strictly speaking there are C compilers that can't link to POSIX
functionality because that POSIX functionality is specified for a different
"system" compiler. POSIX only goes for the system C compiler, not per se
also for others.
The other C compilers must wrap and translate, just like Pascal and other
languages, while e.g. Pascal compilers that integrate with the system C
compiler (like GPC) might be able to use way more of the stuff prepared for
the system compiler.