Evaluation of constant statements

[MarkMLl]

there are 3 folllowups here. But i'd chose one: your comparison with unpacking/structural assignment just indirectly reinforced my own gut feeling, that "Absolute" design was intentionally made alien to Pascal and packed with unneeded burdens to its use, to make that dangerous feature be used as rare as possible.

In practice it was almost always used to access PC video memory: I can't remember whether non PC-DOS Turbo Pascal had it, other systems typically either had serial terminals or video using e.g. a 7220 chip.

Noted your comment about Wirth liking keywords, but I can't think of any cases in (let's call it) J&W Pascal where he used a keyword as a qualifier (i.e. like "packed" or "absolute"). So what we're looking at here is features introduced by either UCSD or Borland, and perpetuated by FPC... in most cases tolerably.

I'd also say- for historical reasons- that early ALGOL compilers were not averse to introducing keywords and having extremely complex syntax to e.g. describe a file. These days we'd put the details in a library, but to a very large extent this predates the library concept and even a fairly minor I/O change required that the core compiler developers be involved.

MarkMLl

[440bx]

there are 3 folllowups here. But i'd chose one: your comparison with unpacking/structural assignment just indirectly reinforced my own gut feeling, that "Absolute" design was intentionally made alien to Pascal and packed with unneeded burdens to its use, to make that dangerous feature be used as rare as possible.

You've made quite a salad.  You mix "absolute" with multiple variable initialization then you complain that absolute should map positionally to the initialization values. 

First, there is no multiple variable initialization in FPC and, "absolute" has nothing to do with it.

Second, as far as "absolute" being a dangerous feature, in some cases, it is dangerously convenient not to mention very easy to use, IOW, no burden at all.

Also, if you claim that something is dangerous, "absolute" in this case, it would good for you to provide one or more examples that compile.  I'm curious, what makes "absolute" alien to Pascal ?  ... is it because it wasn't born in Winterthur ?

[nanobit]

About the {$J} directive default:
Typed constants are mostly wanted for constants {$J-} only, which is the default in Delphi, but not in FPC. In FPC, typed "constants" are writable by default {$J+} although most users want only constants.

[Arioch]

In practice it was almost always used to access PC video memory:

"absolute"?
Would be a poor way to do it .

1) i don't think it was allowed to specify immediate address aith abosolute. You had a "mem" pseudo-array for it. And it even had a syntax borrowed form intel assembler, mem[ x : y] rather than mem[x, y]

2) plane-based design of DOS-time graphics would make accessing static array of bytes - even if it could be positioned at video memory - not very helpful. The correspondence of bit slice to pixel was depending on way too many factors, and not the whole part of pixel was exposed to the memory addressing. On top of it, different strarting offsets of video memory could be possible. And while standard BIOS did not use it, "scroller" games were changing the offset circular queue like, because copying video memory would be prohibitively slow.

so, i do not think TP absolute syntax provided for immediate address literals. I think linkubg asm-=made OBJ-files woud provide, but would useless for practical purposes.

But similarly, i won't bother to download tp3 or tp5 and check it.

I can't remember whether non PC-DOS Turbo Pascal had it, other systems typically either had serial terminals or video using e.g. a 7220 chip.

One soviet school PDP-11 clone had especially exotic design.

It had two CPUs, each with their own memory. 8 MHz (10 cycles for register/register command, so  800K ops/sec) for main, and 4 or 6 MHz peripheral.
PPU was wired to "port" addresses of CPU and emulated most of the devices including videocard.
I am still of the fence if such a design should be called ingenious or desperate.

Both had "dashboard terminal", a special limited octal numbers only debugger (no asm or disasm), which emulated hardware toggles of mainframe PDP-11, but PPU's one had VERY reduced video mode (and since it was PPU itself that emulated videocard - it was a miracle it even worked at all).

> Noted your comment about Wirth liking keywords,

No-no-no. Not keywords, but *reducing* keywords. I think he was public about his achievment of reducing keywords dictionary Pascal -> Modula -> Oberon. Though CP, if my memory is ok, started gaining new keywords, not deleting old ones.

> (let's call it) J&W Pascal

I checked their report, BTW, few hours before, to make sure Wirth did not had "typed constant" in no flavour, so it was TP's (orr USCD's? never saw it, only heard a name) sole invention.

And if TP's strings were good invention (J&W's string were vague dream not spec), that one was probably not.

That said, if Pascal put in industrial use was at all a good event. It is so  "worse is better"  in retrospect... But what heppenned - hapenned.

> These days we'd put the details in a library, but to a very large extent this predates the library concept and even a fairly minor I/O change required that the core compiler developers be involved.

Not sure the uniform concept of bytes and files even existed back then. Early internet RFC share a fair deal describing communications of computers with different byte lengths. Which, frankly, make today problems of endianess kinda laughable in comparison.

All the major OSes today more or less follow C/UNIX concept of files and file paths, so unifrom I/O access became plausible.
Personally, i never dealt with non-interactive coputers, that Pascal was created for. The very idea that files are listed in "program" keyword was driving me to stupor. How can i know then what files are being worked on? How would i provide user a choice? The first computers i saw were 16-bit with natural an reasonable fast support for byte types. Old computers could not address bytes and had not enough power to abuse their queer-width words to process only bytes in them. Old computers could not just say "this home dir is where you have files with your quota" - data was going from different devices, whatever sysops would make work and free from other programs. When your program woudl have it's 5 minutes in some random slot in the night.

This i retroactively understand, but back then this literally drove me to stupor. If i could not specify the file - i could not reason about program further on. Yes, yeah, abstraction, specification by some external mean, i kind of understood it, but since i only had experiece, however limited, with interactive and personal (at least for half an hour) computers - my guts revolted. Interesting that even USCD already changed this aspect of Pascal, albeit differently than TP would.

In a sense it probably was the same as with user interface later. It took a time until both user experience crystallized to some universal concepts, and computing power grew enough to bear penalties of abstraction. I still remember how unbearably slow TP6 and TP7 were after TP5. And those were not even graphic... I guess 20 years before it was the same with storage I/O - no reliable universal concepts and not enough computing power to mantain them.

>  from 6- to 7-bit character representation and things like braces were not always available

Ammm, it was about writeable consts - but is not relevant! Would you talk about "^" for pointers, or about '(." and "(*" brackets - would be relevant (but also would show this was not much of a practical problem). But now you are tempting me... to make some patches actually using (. brackets, i am sure FPC would swallow them fine. FPC devs? not sure...

However both "writeable const" and "initialized var" do not use any character that was not already present in the language. So would be a keyword like "own" - no exotic character owuld be needed.

[PascalDragon]

Technically, of course that's possible (after all the compiler can do that with typed constants),

No, I don't think that would work: the variable would be initialised to the given value every time the function was entered, rather than persisting over function invocations.

The only realistic way would be to define a macro "staticvar" (or similar) to expand to "const".

Assuming the initialization is part of the variable declaration (which you can do in FPC) then yes it would work, because the compiler can make it work. If the initialization is part of the function body (like Delphi code does) then you're right, that wouldn't work.

but again we don't want multiple ways to achieve the same thing especially if there is no significant benefit of one over the other.

Oh come on, Sven, you can do better than that as a justification can't you?

That is the stance of use FPC developers.

The core team is always going on about things not being "in the spirit of Pascal", but can you show me anywhere that Wirth is on record saying that inconstant constants are a good idea?

This is not about the “Spirit of Pascal”, but about language design in general. Yes, I fully agree that the writable typed constant thing is not good (TM), but neither is “many roads lead to Rome”. And while we could introduce a new syntax for mode ObjFPC the old syntax would still need to be available in that mode due to backwards compatibility. And this situation is something that we simply do not want.

In your example, the sensible thing would be to declare something along the lines of:

Code: Pascal  [Select][+][-]

1. c : array[0..3] of byte absolute a;

You did not read what you quoted, did you?  Okay, i repeat yet again.

Quote: They should be declared in one declaration, as they must share the datatype.

They can still share the data type if you declare them separately:

Code: Pascal  [Select][+][-]

1. var
2.   c: array [0..3] of byte absolute a;
3.   d: array [0..3] of byte absolute b;
4.  

That works because equal arrays are considered assignment compatible. Or you can move the array declaration to a separate type declaration.

>  from 6- to 7-bit character representation and things like braces were not always available

Ammm, it was about writeable consts - but is not relevant! Would you talk about "^" for pointers, or about '(." and "(*" brackets - would be relevant (but also would show this was not much of a practical problem). But now you are tempting me... to make some patches actually using (. brackets, i am sure FPC would swallow them fine. FPC devs? not sure...

FPC already handles them (though (* and *) only work mixed with { and } in ISO mode)

Code: Pascal  [Select][+][-]

1. program talternatives;
2.  
3. var
4.   t: array(.0..20.) of LongInt;
5. begin
6.   t(.0.) := 21;
7.   t(.10] := 42;
8.   t[5.) := 4;
9. end.

[MarkMLl]

"absolute"?
Would be a poor way to do it .

There's no "would" about it: it /was/.

2) plane-based design of DOS-time graphics would make accessing static array of bytes - even if it could be positioned at video memory - not very helpful. The correspondence of bit slice to pixel was depending on way too many factors, and not the whole part of pixel was exposed to the memory addressing. On top of it, different strarting offsets of video memory could be possible. And while standard BIOS did not use it, "scroller" games were changing the offset circular queue like, because copying video memory would be prohibitively slow.

Text, not graphics. Non-PC programming needed escape sequences etc., but on a PC (i.e. PC-DOS as distinct from MS-DOS etc.) there was a word array at 0xb800 or 0xb000.

> Noted your comment about Wirth liking keywords,

No-no-no. Not keywords, but *reducing* keywords. I think he was public about his achievment of reducing keywords dictionary Pascal -> Modula -> Oberon. Though CP, if my memory is ok, started gaining new keywords, not deleting old ones.
...

>  from 6- to 7-bit character representation and things like braces were not always available

Ammm, it was about writeable consts - but is not relevant! Would you talk about "^" for pointers, or about '(." and "(*" brackets - would be relevant (but also would show this was not much of a practical problem). But now you are tempting me... to make some patches actually using (. brackets, i am sure FPC would swallow them fine. FPC devs? not sure...

I was taking that in the context of Wirth preferring keywords over short tokens, and I did make the point that I think he generally avoided qualifiers. However, I'd also suggest that most of the qualifiers we're used to were inappropriate when viewed in the context of the sort of machines that Wirth was working with, which included (at least) one machine where the application programmer had to specify certain things as physical addresses but these could not be guaranteed to be constant (for even a few milliseconds) due to the virtual memory manager.

Incidentally, I'd suggest not using (. etc. since while they might appear to be the same as C digraphs they're really not- at least in FPC.

> These days we'd put the details in a library, but to a very large extent this predates the library concept and even a fairly minor I/O change required that the core compiler developers be involved.

Not sure the uniform concept of bytes and files even existed back then. Early internet RFC share a fair deal describing communications of computers with different byte lengths. Which, frankly, make today problems of endianess kinda laughable in comparison.

They existed, but it was unwise to assume portability. However my point was that even something like OPEN() which by our standards would appear to be a library routine was actually handled by the compiler: I think that separate compilation was at least popularised by the IBM S/360 but proper cross-module type checking etc. really started off with Modula-2 (and is possibly Wirth's greatest contribution to the industry).

All the major OSes today more or less follow C/UNIX concept of files and file paths, so unifrom I/O access became plausible.
Personally, i never dealt with non-interactive coputers, that Pascal was created for. The very idea that files are listed in "program" keyword was driving me to stupor. How can i know then what files are being worked on? How would i provide user a choice? The first computers i saw were 16-bit with natural an reasonable fast support for byte types. Old computers could not address bytes and had not enough power to abuse their queer-width words to process only bytes in them. Old computers could not just say "this home dir is where you have files with your quota" - data was going from different devices, whatever sysops would make work and free from other programs. When your program woudl have it's 5 minutes in some random slot in the night.

This i retroactively understand, but back then this literally drove me to stupor. If i could not specify the file - i could not reason about program further on. Yes, yeah, abstraction, specification by some external mean, i kind of understood it, but since i only had experiece, however limited, with interactive and personal (at least for half an hour) computers - my guts revolted. Interesting that even USCD already changed this aspect of Pascal, albeit differently than TP would.

PROGRAM specified what handles were pre-opened, so you were passing text streams to the program in exactly the same way that you would pass other types of parameter to a function. The operations of reading and writing files were, generally speaking, standardised since the internal representation- i.e. once they were visible to the program- was assumed to be that of a variable-length string.

If you wanted to do something outlandish with a binary representation (e.g. to modify the header of a program you had just written so that it ran with superuser rights) you had to assume that that was outside the scope of the "standard" language.

Creating, opening and closing files was very much non-standard since- and I'm going to cherry-pick a couple of examples to simplify an extremely complex area- file naming and layout options were system-specific to an extent that you really can't imagine.

So while implementations typically did have internal facilities to allow a file to be opened by name, more often than not that was left to an external script of some sort which you can consider to be a predecessor of a Windows shortcut or a unix .desktop file; as the industry matured these got to be ridiculously complex but I provide an early example (with an ALGOL program rather than Pascal) for your edification; note that OUTPUT is defined in the control deck while ERROR is defined as device 11 inside the program (and the nasty syntax which does that).

Code: Text  [Select][+][-]

1. ?USER = MARKMLL
2. ?COMPILE HELLO/ALGOL ALGOL
3. ?PROCESS MINUTES = 1
4. ?FILE OUTPUT = MARKMLL/OUTPUT PUNCH
5. ?COMMON = 1
6. ?DATA CARD
7. $CARD LIST SINGLE PRT DEBUGN
8. % ---------------------------------------------------------------------------- %
9. BEGIN
10.  
11. COMMENT  THE MCP HAS AN ARRAY OF PRT DESCRIPTORS, INDEXED BY MIX
12.          NUMBER. EACH PROGRAM HAS ITS R REGISTER SET TO THE CURRENT
13.          ABSOLUTE ADDRESS OF ITS PRT WHILE RUNNING, AND ACCESSES WILL
14.          BE OFFSETS RELATIVE TO THIS. ANY ATTEMPT TO DETERMINE AN
15.          ABSOLUTE ADDRESS AT RUNTIME SHOULD BE TREATED WITH EXTREME
16.          CAUTION, SINCE THINGS WILL MOVE AROUND ACCORDING TO THE
17.          VAGARIES OF VIRTUAL MEMORY;
18.  
19.   INTEGER STREAM PROCEDURE ABSADDR(A);
20.  
21.   BEGIN
22.     SI := A;
23.     ABSADDR := SI
24.   END ABSADDR;
25.  
26. COMMENT  THIS IS THE FIRST VARIABLE AFTER THE PRT, SET USING THE COMMON
27.          CARD OR BY THE IN COMMAND AT THE SPO. IT MAY BE INSPECTED
28.          USING THE SPO%S OT COMMAND, NOTING THAT THESE COMMANDS TAKE
29.          OCTAL ADDRESSES AND THAT THE STRUCTURE OF THIS PROGRAM
30.          SUGGESTS THAT THE OFFSET (RELATIVE TO THE PRT AND THE CPU%S
31.          R REGISTER) IS LIKELY TO BE AROUND 8R26;
32.  
33.   INTEGER BEASTLY;                      % INITIALISED TO 1 BY COMMON CARD      %
34.   REAL T, PI;
35.   FILE IN CARD(1, 10);                  % ONE BUFFER OF 10 WORDS (80 CHARS)    %
36.   FILE OUT OUTPUT(1, 10);
37.   FILE OUT ERROR 11 (1, 10);            % DEFINED AS THE OPERATOR%S SPO DEVICE %
38.  
39. COMMENT  BASIC TEST OF OUTPUT TO CPA AND INPUT FROM CRA (THIS DECK);
40.  
41.   WRITE(OUTPUT, <"HELLO, WORLD!">);     % <> IDENTIFIES FORMAT SPECIFICATION   %
42.   READ(CARD, /, T);                     % / IS FREE-FORMAT, TERMINATED BY ,    %
43.  
44. COMMENT  BASIC TEST OF NUMERIC OPERATORS IN (TRANSLATED) CARD INPUT,
45.          ASSUME THIS USES PAUL KIMPEL%S 7-BIT CODES;
46.  
47.   PI := 3.14159265359;
48.   WRITE(OUTPUT, <"FIRST INTEGER VARIABLE AT", I8, " CONTAINS", I8>,
49.                                         ABSADDR(BEASTLY),  BEASTLY);
50.   WRITE(OUTPUT, <"T:                  ", F16.8>, T);
51.   WRITE(OUTPUT, <"T + PI, PI + T:     ", 2F16.8>, T + PI, PI + T);
52.   WRITE(OUTPUT, <"T - PI, PI - T:     ", 2F16.8>, T - PI, PI - T);
53.   WRITE(OUTPUT, <"T * PI, PI * T:     ", 2F16.8>, T | PI, PI | T); % OR TIMES  %
54.   WRITE(OUTPUT, <"T / PI, PI / T:     ", 2F16.8>, T / PI, PI / T);
55.   WRITE(OUTPUT, <"T DIV PI, PI DIV T: ", 2F16.8>, T DIV PI, PI DIV T);
56.   WRITE(OUTPUT, <"T MOD PI, PI MOD T: ", 2F16.8>, T MOD PI, PI MOD T);
57.   WRITE(OUTPUT, <"T ** PI, PI ** T:   ", 2F16.8>, T * PI, PI * T);
58.   WRITE(OUTPUT, <"T X PI FOR LE EQ NE GE:  ", 4L6>,
59.                                         T { PI, T = PI, T ! PI, T } PI);
60. COMMENT  ----------- NOTE ALGOL STATEMENT LIMIT OF 72 CHARS -----------; 4567890
61. % ---------------------- NOTE CARD LIMIT OF 80 COLUMNS ----------------------- %
62.  
63. COMMENT  WE EXPECT THAT THE FIRST VARIABLE HAS BEEN SET TO 1 BY THE
64.          COMMON CARD. IF THE NEXT LINE IS COMMENTED OUT THEN SHOW
65.          THAT IT IS POSSIBLE TO ASK THE OPERATOR TO PUT A SPECIFIC
66.          VALUE INTO A GLOBAL VARIABLE WHILE THE PROGRAM IS BEING
67.          EXECUTED (CONSIDER THE BILLING IMPLICATIONS BEFORE OVERUSING
68.          THIS, AND BEWARE OF IRRITATING THE OPERATOR WHO%S YOUR BEST
69.          FRIEND AROUND HERE);
70.  
71.   BEASTLY := 0;                  % OVERRIDE OPERATOR INVOLVEMENT        %
72.   IF BEASTLY = 1 THEN BEGIN             % CONTROL CARD SET COMMON VARIABLE OK  %
73.     BEASTLY := 666;                     % INSPECT AT SPO USING E.G. 2 OT 26,   %
74.     IF BEASTLY ! 1 THEN BEGIN           % NOTE OCTAL OFFSET FOR IN AND OT CMDS %
75.       WRITE(ERROR, <"MY COMMON AT PRT+8R26 IS 666, PLEASE SET TO 1">);
76.       WAIT(ABSADDR(BEASTLY), 1);        % SET USING E.G. 2 IN 26=1             %
77.     END IF
78.   END IF % ANYTHING AFTER END IS IGNORED HERE.                                 %
79. END.     % END MUST BE FOLLOWED IMMEDIATELY BY . HERE ------------------------ %
80. ?DATA CARD
81. 4.0,
82. ?END
83.  

You will note from this that that particular flavour was the predecessor of the $ directives used by Pascal and introduced the . immediately after END, it was what Wirth used during his time at Stanford.

Of course these days nobody creates and opens files: it's just a data stream to and from a web server with the details handled by the server coder and administrator.

MarkMLl

[MarkMLl]

That is the stance of use FPC developers.

You collectively then :-)

However I agree with your position applying absolute etc. to lists of variables: it's quite simply impossible to discuss that sort of thing unless at some point in the future tuples are sorted out... and I grant that that's unlikely.

MarkMLl

[Thaddy]

Can you please refrain from 0x and replace it with $ ?
Confusion between C syntax and proper syntax is already a plague.

[MarkMLl]

Can you please refrain from 0x and replace it with $ ?

Only if given permission by whoever it was a few days ago who referred to / as "escape" >:-)

MarkMLl

[BrunoK]

Code: Pascal  [Select][+][-]

1. program talternatives;
2. var
3.   t: array(.0..20.) of LongInt;
4. begin
5.   t(.0.) := 21;
6.   t(.10] := 42;
7.   t[5.) := 4;
8. end.

Berck ... it compiles and run (no Jedi CF for that program) but where is the explanation for this strange syntax of indices.

[dseligo]

Berck ... it compiles and run (no Jedi CF for that program) but where is the explanation for this strange syntax of indices.

In early days of computer there was no square and curly brackets, so instead of '[', ']', '{', '}' this was used:

Code: Pascal  [Select][+][-]

1. [ = (.
2. ] = .)
3. { = (*
4. } = *)

[MarkMLl]

In early days of computer there was no square and curly brackets, so instead of '[', ']', '{', '}' this was used:

Code: Pascal  [Select][+][-]

1. [ = (.
2. ] = .)
3. { = (*
4. } = *)

Careful: that varies enormously by language and manufacturer.

In the early days of computers characters were predominantly 6 bits, and the presence of various characters depended on /which/ six-bit code. As a particular example, /some/ character sets from /some/ manufacturers include the left-arrow glyph that was dropped from ASCII shortly before its finalisation, and the inequality glyphs that have never been in it.

The .) convention etc. became fairly popular when everybody stated buying IBM 026 and 029 cardpunches, since irrespective of the EBCDIC codepage being used the printing mechanism omitted characters we now take for granted.

One thing that was standardised was := as an alternative to the left arrow for ALGOL assignment, and that goes all the way back to IAL in 1958.

MarkMLl

[Arioch]

This i retroactively understand, but back then this literally drove me to stupor. If i could not specify the file

PROGRAM specified what handles were pre-opened, so you were passing text streams to the program in exactly the same way that you would pass other types of parameter to a function.

And that was eactly the abstract theory that did not had flesh.
Imaging a bookish kid, with paper book and notebook (paper) and pencil.
A kid that sometimes snake to higher grades of the school to see how top two classes work on small PDP-11 clones. oemtimes sneaked it to dad job, where he had a miracle, AMD286 with DOS.
But generall could oly look into books.

And those books only dealt with Pascal, not larger picture. They wont talk about JCL or sh-scripts.

So this "someone would provide" to me was equivalent to "flip the coin" and "here be dragons" :-)

> file naming and layout options were system-specific to an extent that you really can't imagine.

We all read a story abou Bob(?) the real drum memory hacker :-)

But i also skimmed USCD Pascal manual ysterday, and finally got it while in TP i did not have those get/put file i/o primitive every paper book taught me about. And TP just removed them.

So, yes, Pasclal was created for non-interactive computers :-D

The very idea in USCD Pascal, that when you close the file it gets auto-deleted until you override it - what a wowser.

> there was a word array at 0xb800 or 0xb000

And that makes two different variables already.

Then you would rememberthat every text mode had a number of text pages with different starting addresses.

Then you would remember it was just a BIOS default setup, but AFAIR you could freely change videobuffer offset to ANY address within the range ot facilitate scrolling.

So, not, pointer to array was way to go, not fixed address array. And better ASM routines than TP noes :-)

[Arioch]

Quote: They should be declared in one declaration, as they must share the datatype.

They can still share the data type if you declare them separately:

Code: Pascal  [Select][+][-]

1. var
2.   c: array [0..3] of byte absolute a;
3.   d: array [0..3] of byte absolute b;
4.  

Damn, forum ate what i typed...

Latter was the workaround.

Former seems to be a non-Pascalish extension i did not know about. And AFAIR it does not work in Delphi, at least it certainly does not work with dynamic arrays (stupid after Delphi introduced generic arrays, but still). The whole concept of "asignment compatibility" in my eyes is ugly kludge just like "writeable constant"

And again, i do not call to make "absolute" easier to use (i would 20 years ago, though). Being laden with burdens this discouraging users is fine.

In an "ideal Pascal" not burdened with TP-compatibility that would have been removed. Syntax-wide this would be enough:

Code: Pascal  [Select][+][-]

1. procedure p (const N: string);
2. const K: PInteger = @N; // or  ... = Pointer(@N) for {$T+} if not a special case made
3. begin
4.    ...
5. end;
6.  

=======

And also, topic "absolute" being broken or properly designed has NOTHING in common with "multiple assignment" or "structural ..." or "unpacking ..." nor with "variable initialization" nor with tuples.
This is just a strawman.

As of tuples... you will have it, grudgingly but you will.
After Delphi made array literals, and made them  with the same syntax as set literals, they would eventually go for tuples too, and probably with the same syntax yet again. And you would have to follow.
It's the fate...

[MarkMLl]

And those books only dealt with Pascal, not larger picture. They wont talk about JCL or sh-scripts.

Incompetent authors are somebody else's problem, not mine. TBH though, when dealing with students or customers I sometimes found that splitting even some of Wirth's concepts up were useful: J&W conflates records, dynamic memory and linked lists to a far greater extent than is useful.

> file naming and layout options were system-specific to an extent that you really can't imagine.

We all read a story abou Bob(?) the real drum memory hacker :-)

Drum memory makes it sound like "The story of Mel". However, machines of that type very often used bit-serial logic (which I mentioned a few days ago in the context of Thinking Machines etc.) and if they had any concept of files at all it was based on tape-to-tape operations ("unit-record" in some terminologies).

I'd much rather not go looking for an example of the ALGOL large-system OPEN statement, since it will mean ploughing through Bitsavers for something which has been scanned but not OCRed. Just trust me: you're talking about a dozen or more modifiers (not procedure parameters) specifying every last detail.

Slightly later: http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1038643_B5500_CompatibleAlgol_May69.pdf p126 (7-14). It's the file declaration rather than the OPEN() which sets up (what the manual refers to as) a "label equation" which is in effect a file name, but I think all in all it's a good example of how excessive keyword use etc. can get to be extremely cumbersome.

However, in the case of e.g. a static variable or an alias referring to the (absolute) address of an existing variable I'm not sure that there's anything more appropriate: it's not reasonable to expect a variable's compile/link-time attributes to be controlled using e.g. the .something notation.

MarkMLl