Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Again...

65 views
Skip to first unread message

Mike Zimnov

unread,
Feb 9, 2023, 2:20:11 PM2/9/23
to
PL/1 was offended again. Well, what are you going to do!

I'm leafing through a solid book "Compilers: principles, technologies and tools". Second edition. Alfred V. Aho, Monica S. Lam, Ravi Seti, Jeffrey D. Ullman 2007.

Fortran, Cobol, Lisp and C are mentioned more often. But here on page 117 I read: "For example, some languages like PL/I do not treat keywords as reserved; that is, you can use identifiers with same name as a keyword like DECLARE. If the lexical analyzer is presented with text of a PL/I program that begins DECLARE (ARG1, ARG2,… it cannot be sure whether DECLARE is a keyword, and ARG1 and so on are variables being declared, or whether DECLARE is a procedure name with its arguments. For this reason, modern languages tend to reserve their keywords."

This is a mention in vain of a language whose syntax has been unambiguous since the very beginning (1963), since the entire source text (with the exception of the label and one nuance of assignment) always has the same structure of all elements: keyword, body, semicolon. If you suddenly named a procedure (or function) with the name DECLARE, then it will either be inside the expression or called by the CALL operator. Thus, the lexical analyzer has no difficulties. And in the example in the book, this is a description, and the call will be CALL DECLARE(ARG1,... You can call the procedure CALL and its call will then be CALL CALL. Having parsed the first CALL as a keyword, the compiler already interprets the following tokens (including CALL) as identifiers. It's a shame the authors don't know this, since they remembered PL/1.

P.S. By making my CALL optional, I made life a little more difficult for the compiler. But in practice, nothing terrible happened. The text is normally parsed. The only difference is that the error of an undescribed variable turned into a message "this is not a procedure".

John W Kennedy

unread,
Feb 9, 2023, 7:19:16 PM2/9/23
to
If CALL is optional, how is this interpreted?

PUT: PROCEDURE(STRING);
DECLARE STRING CHARACTER(*);
...
END PUT;
PUT ('HELLO WORLD!');

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

Mike Zimnov

unread,
Feb 10, 2023, 6:26:25 AM2/10/23
to
пятница, 10 февраля 2023 г. в 03:19:16 UTC+3, John W Kennedy:
You're right, of course. In case of collisions (as in the example), the keyword "CALL" becomes mandatory again.

Anecdote:

Patient: Doc, when I do this, it hurts me!

DOCTOR: And you don't do that!



1 test a 000000:basic procedure;
2 c 000000
3 c 000000 PUT: PROCEDURE(STRING);
000000 TEST:
000000 B88C9B4002, eax,37788556
000005 E800000000 call ?to begin
4 e 00000A DECLARE A STRING CHARACTER(*);
00000A EB0B jmps @1
00000C PUT:
00000C 488B1B mov q rbx,[rbx]
00000F 48891DF8010000 mov q STRING,rbx
000016 C3 ret
000017 @1:
5 c 000017 PUT AN END TO;
6 c 000017 PUT ('HELLO, WORLD!');
000017 B932000000 mov ecx,offset @2
00001C E800000000 call ?SYSPS
000021 BEE4000000 mov q rsi,offset @000000E4h
000026 B00C mov al,12
000028 E800000000 call ?SLCTP
00002D E800000000 call ?QIOOP ; built- in PUT
000032 @2:
7 c 000032 ENTERING A CALL ('HELLO, WORLD!');
000032 BEE4000000 mov q rsi,offset @000000E4h
000037 8D7E14 mov q rdi,offset @000000F8h
00003A B0FE mov al,254
00003C B10C mov cl,12
00003E E800000000 call ?SMCCM
000043 BBF0000000 mov q rbx,offset @000000F0h
000048 E8BFFFFFFF PUT call ; PUT procedure
8 a 00004D final test;
00004D E800000000 call ?STOPX

Robin Vowels

unread,
Apr 15, 2023, 9:48:33 PM4/15/23
to
On Friday, February 10, 2023 at 6:20:11 AM UTC+11, Mike Zimnov wrote:
> PL/1 was offended again. Well, what are you going to do!
>
> I'm leafing through a solid book "Compilers: principles, technologies and tools". Second edition. Alfred V. Aho, Monica S. Lam, Ravi Seti, Jeffrey D. Ullman 2007.
>
> Fortran, Cobol, Lisp and C are mentioned more often. But here on page 117 I read: "For example, some languages like PL/I do not treat keywords as reserved; that is, you can use identifiers with same name as a keyword like DECLARE. If the lexical analyzer is presented with text of a PL/I program that begins DECLARE (ARG1, ARG2,… it cannot be sure whether DECLARE is a keyword, and ARG1 and so on are variables being declared, or whether DECLARE is a procedure name with its arguments. For this reason, modern languages tend to reserve their keywords."

What? There's no ambiguity. It's an inadequate explanation.
DECLARE in the above context cannot be a procedure name.
In any case, at the end of the list is a semicolon, a comma, or attributes.
That is sufficient to determine that the keyword is being used.

Peter Flass

unread,
Apr 17, 2023, 8:11:07 PM4/17/23
to
Robin Vowels <robin....@gmail.com> wrote:
> On Friday, February 10, 2023 at 6:20:11 AM UTC+11, Mike Zimnov wrote:
>> PL/1 was offended again. Well, what are you going to do!
>>
>> I'm leafing through a solid book "Compilers: principles, technologies
>> and tools". Second edition. Alfred V. Aho, Monica S. Lam, Ravi Seti,
>> Jeffrey D. Ullman 2007.
>>
>> Fortran, Cobol, Lisp and C are mentioned more often. But here on page
>> 117 I read: "For example, some languages like PL/I do not treat keywords
>> as reserved; that is, you can use identifiers with same name as a
>> keyword like DECLARE. If the lexical analyzer is presented with text of
>> a PL/I program that begins DECLARE (ARG1, ARG2,… it cannot be sure
>> whether DECLARE is a keyword, and ARG1 and so on are variables being
>> declared, or whether DECLARE is a procedure name with its arguments. For
>> this reason, modern languages tend to reserve their keywords."

Or DECLARE is a subscripted variable, declared later.

>
> What? There's no ambiguity. It's an inadequate explanation.
> DECLARE in the above context cannot be a procedure name.
> In any case, at the end of the list is a semicolon, a comma, or attributes.
> That is sufficient to determine that the keyword is being used.
>

It’s just a matter of how many tokens you have to look ahead to
disambiguate.

--
Pete

John W Kennedy

unread,
Apr 18, 2023, 4:05:11 PM4/18/23
to
No-reserved-word syntax has other problems. Clunkier punctuation for
one, and the annoying CALL keyword. COBOL, on the other hand, has so
damn many reserved words that many shops simply forbid employing as user
names the entire technical vocabularies of IT and accounting, lest words
become keywords in the next COBOL.

Peter Flass

unread,
Apr 19, 2023, 2:53:36 PM4/19/23
to
We always used to prefix the names. We’d use, for example, EM-NAME for a
field from the employee master, WS-XXX for working- storage fields, etc.

--
Pete

John W Kennedy

unread,
Apr 19, 2023, 7:09:03 PM4/19/23
to
Apple’s Swift has an elegant solution. If you wrap a word in backticks,
it temporarily becomes not-a-keyword.

var `var`: Int = 0 // Declares an integer variable named “var”.

Vary useful if you can’t change the variable name, such as when you’re
using an automatic XML creating/reading engine.

Peter Flass

unread,
Apr 19, 2023, 8:55:16 PM4/19/23
to
The opposite of the old ALGOL compilers, then.

--
Pete

John W Kennedy

unread,
Apr 20, 2023, 3:19:06 PM4/20/23
to
And a hell of a lot less cluttered.
0 new messages