PL/1 was offended again. Well, what are you going to do!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
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
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,
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 "thisis not a procedure".
On 2/9/23 2:19 PM, Mike Zimnov wrote: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
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
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 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:
this is not a procedure".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 "
If CALL is optional, how is this interpreted?You're right, of course. In case of collisions (as in the example), the keyword "CALL" becomes mandatory again.
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!
PL/1 was offended again. Well, what are you going to do!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
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
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.
Robin Vowels <robin.vowels@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.
On 4/17/23 8:11 PM, Peter Flass wrote:
Robin Vowels <robin.vowels@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.
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.
John W Kennedy <john.w.kennedy@gmail.com> wrote:
On 4/17/23 8:11 PM, Peter Flass wrote:
Robin Vowels <robin.vowels@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.
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.
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.
On 4/19/23 2:53 PM, Peter Flass wrote:
John W Kennedy <john.w.kennedy@gmail.com> wrote:
On 4/17/23 8:11 PM, Peter Flass wrote:
Robin Vowels <robin.vowels@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.
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.
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.
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.
John W Kennedy <john.w.kennedy@gmail.com> wrote:
On 4/19/23 2:53 PM, Peter Flass wrote:
John W Kennedy <john.w.kennedy@gmail.com> wrote:
On 4/17/23 8:11 PM, Peter Flass wrote:
Robin Vowels <robin.vowels@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.
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.
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.
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.
The opposite of the old ALGOL compilers, then.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 77:40:36 |
| Calls: | 6,695 |
| Files: | 12,228 |
| Messages: | 5,347,482 |