On 2020-09-04 18:36, Paul Gilmartin wrote:
On Fri, 4 Sep 2020 20:38:29 +0000, Robert Prins wrote:
On 2020-09-04 17:01, Paul Gilmartin wrote:
I see everything twice:
On Fri, 4 Sep 2020 19:05:32 +0000, Robert Prins wrote:
On Fri, 4 Sep 2020 19:06:49 +0000, Robert Prins wrote:
Yes, problems posting. Should be OK now.
Your setting your system clock to Europe/Vilnius but calling it UTC
remains an irritant to those who want to read threads in chronological
sequence. I suppose you relish your plies' floating to the top of the
list for a couple hours.
Completely oblivious of that, and definitely not to keep myself in the picture.
The simple fact is that I hate it that 'doze displays timestamps different in
different time zones. So my TZ is UTC.
However as a Pascal partisan, you should love(?) the NOLAXQUAL compiler option,
one of the options (when used) that takes away one of the best features of PL/I,
which is that as long as the compiler can uniquely find a variable in its symbol
table, you do not have to fully qualify it. Wit the the NOLAXQUAL compiler
option you will have to use myvar.thislevel.array.struct.variant.plorkestein,
even if "plorkestein" is the only variable in the program with that name, which
is one of the worst features of Pascal.
Can't be as bad as the lack of static initialization.
Borland introduced Typed Constants (that aren't constants at all), and that is
now part and parcel of every Pascal compiler, including Delphi.
And somewhat mitigated by the WITH statement.
See
<https://stackoverflow.com/questions/71419/why-should-i-not-use-with-in-delphi>
and
<https://stackoverflow.com/questions/514482/is-delphi-with-keyword-a-bad-practice>
I understand that PL/I tolerates fairly arbitrary permutation of
qualifiers as long there's a unique valid depermutation. I.e.
struct.array[I] and strict[I].array are alternatives. An invitation
to obscure coding.
None of the shops I ever worked in had rules for this, I usually put the
subscripts at the level they should be.
C is bad enough for making array[I]
equivalent to I[array].
We confronted a cadre of PL/I partisans who strenuously objected
to the NOLAXQUAL-ness of IEEE Pascal. They reacted by providing
a standard header containing a WITH to expose the penultimate
level of every structure. And we scrambled to revise our code
generator to fix the resulting base register exhaustion.
An optimizing compiler, and none of the Pascal ones seem to fall into that
category, should do this automagically.
I once wrote a Pascal program to convert RTF to SCRIPT/VS. A
co-worker enthusiastically grabbed it, only to be dismayed that I
had relied heavily on the IEEE standard file buffer that was
unsupported by the Turbo he used. Borland boasted of the
misfeature.
You mean you used "get" and/or "put"? I've never ever used those, but Borland,
Virtual and Free Pascal can set up buffers for files (standard 128 bytes) and in
one of the programs I wrote to process my hitchhike data, I'm actually almost
completely bypassing Pascal's read(ln)/write(ln) and doing everything by direct
access of the file buffers, reading and writing them via BlockRead/Write. Works
like a charm, and fast!
Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
