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

Groups > comp.programming > #12486 > unrolled thread

Reading command line in Pascal

Back to article view | Back to comp.programming

Contents

  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

#12486 — Reading command line in Pascal

How, in standard Pascal (ISO/IEC 7185:1990), does one read the command line?
-- 
Just as 'beautiful' points the way for aesthetics and 'good' for ethics,
so do words like 'true' for logic.  All sciences have truth as their
goal; but logic is also concerned with it in a quite different way:
logic has much the same relation to truth as physics has to weight or
heat.                               Frege in 'Thoughts' (Der Gedanke)

[toc] | [next] | [standalone]

#12487

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.
In implementations of Pascal (like Turbo Pascal) there can be functions
(like  paramStr and paramCount). If there are then one uses those functions.

[toc] | [prev] | [next] | [standalone]

#12488

Öö 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!

> In implementations of Pascal (like Turbo Pascal) there can be functions
> (like  paramStr and paramCount). If there are then one uses those functions.
> 

Thank you.

-- 
Just as 'beautiful' points the way for aesthetics and 'good' for ethics,
so do words like 'true' for logic.  All sciences have truth as their
goal; but logic is also concerned with it in a quite different way:
logic has much the same relation to truth as physics has to weight or
heat.                               Frege in 'Thoughts' (Der Gedanke)

[toc] | [prev] | [next] | [standalone]

#12489

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.

(In all my Pascal programming, I haven't needed command line parameters
in more than one or two programs.)

> 
>> In implementations of Pascal (like Turbo Pascal) there can be functions
>> (like  paramStr and paramCount). If there are then one uses those
>> functions.
>>
> 
> Thank you.
> 

[toc] | [prev] | [next] | [standalone]

#12492

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#12493

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.
 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.

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.

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.

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.

[toc] | [prev] | [next] | [standalone]

#12494

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.

>   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. 
Wirth's Pascal was greatly portable, but very incomplete. C was 
extremely non-portable, but complete, at least under UNIX.

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

> 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.

> 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.

> 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].

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#12495

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).

[toc] | [prev] | [next] | [standalone]

#12526

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.

If a language can be implemented in anyway the implementer chooses, 
there is no point having a standard.

>   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.
> 
> 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.
> 
> 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.
> 
> 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.
> 


-- 
Just as 'beautiful' points the way for aesthetics and 'good' for ethics,
so do words like 'true' for logic.  All sciences have truth as their
goal; but logic is also concerned with it in a quite different way:
logic has much the same relation to truth as physics has to weight or
heat.                               Frege in 'Thoughts' (Der Gedanke)

[toc] | [prev] | [next] | [standalone]

#12525

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)

In the original With version a source program had to consist of just one 
file, so no programming "in the large" was possible.  That's not just 
silly, it's utterly stupid.
> 
> Thus it is rather a lesser kind of silliness: not to provide a standard 
> library to access the program environment.
> 


-- 
Just as 'beautiful' points the way for aesthetics and 'good' for ethics,
so do words like 'true' for logic.  All sciences have truth as their
goal; but logic is also concerned with it in a quite different way:
logic has much the same relation to truth as physics has to weight or
heat.                               Frege in 'Thoughts' (Der Gedanke)

[toc] | [prev] | [next] | [standalone]

#12528

Peter wrote:
> 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)
> 
> In the original With version a source program had to consist of just one 

Wirth sorry.

> file, so no programming "in the large" was possible.  That's not just 
> silly, it's utterly stupid.
>>
>> Thus it is rather a lesser kind of silliness: not to provide a 
>> standard library to access the program environment.
>>
> 
> 


-- 
Just as 'beautiful' points the way for aesthetics and 'good' for ethics,
so do words like 'true' for logic.  All sciences have truth as their
goal; but logic is also concerned with it in a quite different way:
logic has much the same relation to truth as physics has to weight or
heat.                               Frege in 'Thoughts' (Der Gedanke)

[toc] | [prev] | [next] | [standalone]

#12527

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

C manages.

> 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.
> 
> (In all my Pascal programming, I haven't needed command line parameters
> in more than one or two programs.)
> 
>>
>>> In implementations of Pascal (like Turbo Pascal) there can be functions
>>> (like  paramStr and paramCount). If there are then one uses those
>>> functions.
>>>
>>
>> Thank you.
>>
> 


-- 
Just as 'beautiful' points the way for aesthetics and 'good' for ethics,
so do words like 'true' for logic.  All sciences have truth as their
goal; but logic is also concerned with it in a quite different way:
logic has much the same relation to truth as physics has to weight or
heat.                               Frege in 'Thoughts' (Der Gedanke)

[toc] | [prev] | [next] | [standalone]

#12537

On 29.04.2021 18:55, Peter wrote:
> 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
> 
> C manages.

Unfortunately, C does not manage.

That's not entirely the C standard's fault, because it provides the 
ability, just in a way (`char` based string arguments of `main`) that 
until June 2019, and perhaps also after, was impractical in Windows.

All extant C implementations in Windows fail to encode the `main` 
arguments as UTF-8, so these arguments cannot faithfully represent a 
command line with e.g. filenames with international characters.

That doesn't mean that the logic of your response is incorrect, nor the 
intended meaning: it /can/ be done.

You just have an incorrect perception of the state of C.

If the first Pascal standard (disclaimer: I'm unfamiliar with it) had 
standardized command line access just as C, then most likely Pascal 
would have been in the same pit of backward compatible silliness as C.

So in a way it was good that the Pascal standard did not address that issue.


> [snip]

- Alf

[toc] | [prev] | [next] | [standalone]

#12541

On 2021-05-05, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
> On 29.04.2021 18:55, Peter wrote:
>> 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
>> 
>> C manages.
>
> Unfortunately, C does not manage.
>
> That's not entirely the C standard's fault, because it provides the 
> ability, just in a way (`char` based string arguments of `main`) that 
> until June 2019, and perhaps also after, was impractical in Windows.
>
> All extant C implementations in Windows fail to encode the `main` 
> arguments as UTF-8, so these arguments cannot faithfully represent a 
> command line with e.g. filenames with international characters.
>
> That doesn't mean that the logic of your response is incorrect, nor the 
> intended meaning: it /can/ be done.
>
> You just have an incorrect perception of the state of C.
>
> If the first Pascal standard (disclaimer: I'm unfamiliar with it) had 
> standardized command line access just as C, then most likely Pascal 
> would have been in the same pit of backward compatible silliness as C.
>
> So in a way it was good that the Pascal standard did not address that issue.

Windows is broken, it's not C standards fault. 
>
>
>> [snip]
>
> - Alf


-- 
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#12542

On 2021-05-06 10:46, Melzzzzz wrote:
> On 2021-05-05, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
>> On 29.04.2021 18:55, Peter wrote:
>>> 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
>>>
>>> C manages.
>>
>> Unfortunately, C does not manage.
>>
>> That's not entirely the C standard's fault, because it provides the
>> ability, just in a way (`char` based string arguments of `main`) that
>> until June 2019, and perhaps also after, was impractical in Windows.
>>
>> All extant C implementations in Windows fail to encode the `main`
>> arguments as UTF-8, so these arguments cannot faithfully represent a
>> command line with e.g. filenames with international characters.
>>
>> That doesn't mean that the logic of your response is incorrect, nor the
>> intended meaning: it /can/ be done.
>>
>> You just have an incorrect perception of the state of C.
>>
>> If the first Pascal standard (disclaimer: I'm unfamiliar with it) had
>> standardized command line access just as C, then most likely Pascal
>> would have been in the same pit of backward compatible silliness as C.
>>
>> So in a way it was good that the Pascal standard did not address that issue.
> 
> Windows is broken, it's not C standards fault.

It is debatable (Windows has a POSIX layer, BTW).

But, let you need to parse the command line (or lines) in a certain way, 
you could do that in Windows, but out of luck in UNIX.

And as we all are programming rather in Whitespace (:-)), how would you 
design a Whitespace command line calculator?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#12543

On 2021-05-06, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2021-05-06 10:46, Melzzzzz wrote:
>> On 2021-05-05, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
>>> On 29.04.2021 18:55, Peter wrote:
>>>> 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
>>>>
>>>> C manages.
>>>
>>> Unfortunately, C does not manage.
>>>
>>> That's not entirely the C standard's fault, because it provides the
>>> ability, just in a way (`char` based string arguments of `main`) that
>>> until June 2019, and perhaps also after, was impractical in Windows.
>>>
>>> All extant C implementations in Windows fail to encode the `main`
>>> arguments as UTF-8, so these arguments cannot faithfully represent a
>>> command line with e.g. filenames with international characters.
>>>
>>> That doesn't mean that the logic of your response is incorrect, nor the
>>> intended meaning: it /can/ be done.
>>>
>>> You just have an incorrect perception of the state of C.
>>>
>>> If the first Pascal standard (disclaimer: I'm unfamiliar with it) had
>>> standardized command line access just as C, then most likely Pascal
>>> would have been in the same pit of backward compatible silliness as C.
>>>
>>> So in a way it was good that the Pascal standard did not address that issue.
>> 
>> Windows is broken, it's not C standards fault.
>
> It is debatable (Windows has a POSIX layer, BTW).
>
> But, let you need to parse the command line (or lines) in a certain way, 
> you could do that in Windows, but out of luck in UNIX.
>
> And as we all are programming rather in Whitespace (:-)), how would you 
> design a Whitespace command line calculator?

Well, C sepparates words by whitespace in command line.
>


-- 
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#13548

💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕💕

Melzzzzz kirjutas neljapäev, 6. mai 2021 kl 13:06:37 UTC+3:
> On 2021-05-06, Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote: 
> > On 2021-05-06 10:46, Melzzzzz wrote: 
> >> On 2021-05-05, Alf P. Steinbach <alf.p.stein...@gmail.com> wrote: 
> >>> On 29.04.2021 18:55, Peter wrote: 
> >>>> 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 
> >>>> 
> >>>> C manages. 
> >>> 
> >>> Unfortunately, C does not manage. 
> >>> 
> >>> That's not entirely the C standard's fault, because it provides the 
> >>> ability, just in a way (`char` based string arguments of `main`) that 
> >>> until June 2019, and perhaps also after, was impractical in Windows. 
> >>> 
> >>> All extant C implementations in Windows fail to encode the `main` 
> >>> arguments as UTF-8, so these arguments cannot faithfully represent a 
> >>> command line with e.g. filenames with international characters. 
> >>> 
> >>> That doesn't mean that the logic of your response is incorrect, nor the 
> >>> intended meaning: it /can/ be done. 
> >>> 
> >>> You just have an incorrect perception of the state of C. 
> >>> 
> >>> If the first Pascal standard (disclaimer: I'm unfamiliar with it) had 
> >>> standardized command line access just as C, then most likely Pascal 
> >>> would have been in the same pit of backward compatible silliness as C. 
> >>> 
> >>> So in a way it was good that the Pascal standard did not address that issue. 
> >> 
> >> Windows is broken, it's not C standards fault. 
> > 
> > It is debatable (Windows has a POSIX layer, BTW). 
> > 
> > But, let you need to parse the command line (or lines) in a certain way, 
> > you could do that in Windows, but out of luck in UNIX. 
> > 
> > And as we all are programming rather in Whitespace (:-)), how would you 
> > design a Whitespace command line calculator?
> Well, C sepparates words by whitespace in command line.
> > 
> 
> 
> -- 
> current job title: senior software engineer 
> skills: x86 aasembler,c++,c,rust,go,nim,haskell... 
> 
> press any key to continue or any other to quit...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web