• Again...

    From Mike Zimnov@21:1/5 to All on Thu Feb 9 11:19:55 2023
    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".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John W Kennedy@21:1/5 to Mike Zimnov on Thu Feb 9 19:19:10 2023
    On 2/9/23 2:19 PM, 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."

    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".

    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Zimnov@21:1/5 to All on Fri Feb 10 03:26:24 2023
    пятница, 10 февраля 2023 г. в 03:19:16 UTC+3, John W Kennedy:
    On 2/9/23 2:19 PM, 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."

    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".
    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!
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Mike Zimnov on Sat Apr 15 18:48:32 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Flass@21:1/5 to Robin Vowels on Mon Apr 17 17:11:05 2023
    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.

    --
    Pete

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John W Kennedy@21:1/5 to Peter Flass on Tue Apr 18 16:05:06 2023
    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
    Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
    King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Flass@21:1/5 to John W Kennedy on Wed Apr 19 11:53:34 2023
    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.

    --
    Pete

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John W Kennedy@21:1/5 to Peter Flass on Wed Apr 19 19:08:52 2023
    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
    Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
    King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Flass@21:1/5 to John W Kennedy on Wed Apr 19 17:55:14 2023
    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.

    --
    Pete

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John W Kennedy@21:1/5 to Peter Flass on Thu Apr 20 15:18:54 2023
    On 4/19/23 8:55 PM, Peter Flass wrote:
    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.

    And a hell of a lot less cluttered.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)