Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #12495

Re: Reading command line in Pascal

Path csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From David Brown <david.brown@hesbynett.no>
Newsgroups comp.programming
Subject Re: Reading command line in Pascal
Date Mon, 26 Apr 2021 10:46:25 +0200
Organization A noiseless patient Spider
Lines 157
Message-ID <s65ul2$mcb$1@dont-email.me> (permalink)
References <s63oc3$v7a$1@gioia.aioe.org> <58b57a04-588e-4a77-afd2-34ef4ef27775n@googlegroups.com> <s63uj0$1nih$1@gioia.aioe.org> <s6438e$r1e$1@dont-email.me> <s65kc1$mbc$1@gioia.aioe.org> <s65mre$6b4$1@dont-email.me> <s65t5j$h4c$1@gioia.aioe.org>
Mime-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 8bit
Injection-Date Mon, 26 Apr 2021 08:46:26 -0000 (UTC)
Injection-Info reader02.eternal-september.org; posting-host="4978fc2c584a63425cf3e714c4ce222e"; logging-data="22923"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8cSLCgahrpQBq+Q9OdBUt+ZyhlH9Fgr0="
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
Cancel-Lock sha1:kg2y8LX5YlQbrjaYS15uypJD13U=
In-Reply-To <s65t5j$h4c$1@gioia.aioe.org>
Content-Language en-GB
Xref csiph.com comp.programming:12495

Show key headers only | View raw


On 26/04/2021 10:21, Dmitry A. Kazakov wrote:
> On 2021-04-26 08:33, David Brown wrote:
>> On 26/04/2021 07:50, Dmitry A. Kazakov wrote:
>>> On 2021-04-25 17:52, David Brown wrote:
>>>> On 25/04/2021 16:33, Peter wrote:
>>>>> Öö Tiib wrote:
>>>>>> On Sunday, 25 April 2021 at 15:47:04 UTC+3, Peter wrote:
>>>>>>> How, in standard Pascal (ISO/IEC 7185:1990), does one read the
>>>>>>> command line?
>>>>>>
>>>>>> One does not as that standard does not have concept of command line.
>>>>>
>>>>> Yet another example of the language's silliness!
>>>>
>>>> It is not an "example of silliness".  It is simply not something
>>>> covered
>>>> in the standard, because different Pascal implementations need
>>>> significantly different ways of getting command line information (and
>>>> there are plenty of Pascal implementations for which "command line"
>>>> doesn't even make sense).  A language standard is never intended to
>>>> cover everything about particular implementations, or cover everything
>>>> that is needed for all coding in the language.
>>>
>>> That would be a great SILLINESS, as the language must be capable of
>>> abstraction an implementation.
>>>
>>> I do not remember Pascal well, but I think it was not that silly. (Maybe
>>> the original Wirth's one was)
>>>
>>> Thus it is rather a lesser kind of silliness: not to provide a standard
>>> library to access the program environment.
>>>
>>
>> Again, this is confusing language standards and language implementation.
> 
> To clarify:
> 
> #1. A language design concept of having modules with a defined interface.
> 
> IF the language has modules THEN the client is dependent on the module
> specification only and the concrete implementation of becomes irrelevant.
> 
> #2. Provided #1 the language standard library can contain a module to
> access the process environment.
> 
> Not having #1 is a great silliness. Not having #2 is a lesser silliness.

Originally, Pascal was not specified with modules of any kind.  It was
not "silliness" - it reflected typical sizes of programs of the time.

> 
>>   And it is dependent on the language, its aims, and its portability.
>> Based on my memory of the history, Pascal was designed to be a language
>> that was useful, but easy to learn - which meant keeping it small.  It
>> was intended that Pascal implementations could be made on a very wide
>> variety of systems - but not that Pascal programs should be portable
>> between such systems.  Parts of Pascal /code/ could be portable, but it
>> was more important that the knowledge and understanding was portable.
> 
> That would not preclude either #1 or #2.
> 
> I think you conflate code portability with language completeness.

No language is "complete".

> Wirth's Pascal was greatly portable, but very incomplete. 

Certainly Pascal was originally a small language with relatively few
features.  And yes, it was intended to be able to implement it on many
systems (the language was portable, in that sense - programs written in
Pascal were not).

> C was
> extremely non-portable, but complete, at least under UNIX.

That's an odd statement.  If you mean the language is not portable, it
would be nonsense - no language (including Pascal) comes close to being
supported by as many different systems.  If you mean programs written in
C are not portable, it would be partially nonsense - people can, and do,
write programs, libraries and other code in highly portable C that is
used on widely different systems.  C also supports writing
system-specific code, and lots of C code is /not/ portable.  But
particularly in the *nix world, the portability of C is why you can (and
do) run the same programs on x86 Linux and Raspberry Pi's as you did 30
years ago on SPARCs with Solaris and dozens of other Posix systems on
dozens of different processors.

You can do that despite C not being remotely "complete" - very, very few
programs are written that rely solely on the language and library
features described in the C standards.

(But there's no doubt that the C standards cover more than the Pascal
standards here, and you can get away with fewer implementation-specific
features and libraries than you need for Pascal.)


> 
> Pascal incompleteness led to countless substandard implementations
> stuffing the holes. Programs relying on substandard extensions weren't
> non-portable, they were no Pascal.
> 

They were Pascal, but not portable.

>> Compare this to C, where the intention was that real programs could be
>> written in C and compiled directly on a range of systems (as well as
>> supporting system-specific programs).  Thus the C standard had to cover
>> a good deal more than the Pascal standard.
> 
> C failed miserably on both.

C is far and away the biggest language for portable programs (and
libraries) that are portable to different systems, and far and away the
biggest language for low-level, high performance code that is system
specific.  It turned out to be surprisingly good for both uses - to the
extent that 50 years later, no single language surpasses its use in
either situation.

(It is certainly not a perfect language, and you can argue that there
now are better choices than C in most programming situations.)

> 
>> Or at a greater extreme, Java defines things in far more detail with the
>> aim of "right once, run everywhere" - meaning it is only useable on a
>> smaller subset of systems, but programs are more portable.
> 
> Java moved implementation down to the byte code, a very crude approach,
> they tried to correct it later.

Using a byte-coded virtual machine was not "crude", nor has anyone
"tried to correct it".  There have been some Java compilers targeting
assembly rather than byte code, and there are many JIT virtual machines,
if that is what you mean.  The benefits of byte coding and virtual
machines have been shown again and again, and so they are used for many
languages (despite their obvious disadvantages).

> 
>> There is no question of "silliness" here - it's just a matter of the
>> level of detail that you specify in the standard, and what you leave up
>> to particular implementations.
> 
> It is not a level of detail, it is functionality (access to the
> environment) provided or not.
> 
> A detail would be providing individual command line arguments, but not
> the whole command line [easy under Windows, problematic under UNIX].
> 

Some systems don't have command lines.  Some systems don't have file
systems, at least not with the kind of functionality needed to implement
the C standard library.  Pascal gets its portability by saying these
things are just not part of the language standard.  C gets it by saying
you either have to have an OS (and standard library) that provides these
features, or you have a "freestanding" implementation and pretty much
nothing is guaranteed to be provided (not even character input/output).

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Reading command line in Pascal Peter <peterxpercival@hotmail.com> - 2021-04-25 13:47 +0100
  Re: Reading command line in Pascal Öö Tiib <ootiib@hot.ee> - 2021-04-25 07:23 -0700
    Re: Reading command line in Pascal Peter <peterxpercival@hotmail.com> - 2021-04-25 15:33 +0100
      Re: Reading command line in Pascal David Brown <david.brown@hesbynett.no> - 2021-04-25 17:52 +0200
        Re: Reading command line in Pascal "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-04-26 07:50 +0200
          Re: Reading command line in Pascal David Brown <david.brown@hesbynett.no> - 2021-04-26 08:33 +0200
            Re: Reading command line in Pascal "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-04-26 10:21 +0200
              Re: Reading command line in Pascal David Brown <david.brown@hesbynett.no> - 2021-04-26 10:46 +0200
            Re: Reading command line in Pascal Peter <peterxpercival@hotmail.com> - 2021-04-29 17:54 +0100
          Re: Reading command line in Pascal Peter <peterxpercival@hotmail.com> - 2021-04-29 17:52 +0100
            Re: Reading command line in Pascal Peter <peterxpercival@hotmail.com> - 2021-04-29 18:44 +0100
        Re: Reading command line in Pascal Peter <peterxpercival@hotmail.com> - 2021-04-29 17:55 +0100
          Re: Reading command line in Pascal "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2021-05-05 20:20 +0200
            Re: Reading command line in Pascal Melzzzzz <Melzzzzz@zzzzz.com> - 2021-05-06 08:46 +0000
              Re: Reading command line in Pascal "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-05-06 11:55 +0200
                Re: Reading command line in Pascal Melzzzzz <Melzzzzz@zzzzz.com> - 2021-05-06 10:06 +0000
                Re: Reading command line in Pascal An iM <uavyuayve@hotmail.com> - 2021-08-27 11:27 -0700

csiph-web