On 2008-05-08, Scott Moore <samiam@[EMAIL PROTECTED]
> wrote:
>> 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.
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 sup****ted 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 sup****t (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 sup****t), that
IMHO doesn't necessarily mean no string sup****t 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
> establi****ng 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.
|
