Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #12495
| 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
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