5 ms·

They both remove the need for screwball operator precedence, but the lisp s-expression do it by putting everything in parentheses(or perhaps everything in funct

by somat 2y ago

They both remove the need for screwball operator precedence, but the lisp s-expression do it by putting everything in parentheses(or perhaps everything in function notation is the better way to put it) and RPN does it by making the stack an integral part of the mental model needed to understand it.

adrian_b 2y ago
The parentheses are needed in LISP only because many functions have a variable number of operands, so that parentheses are needed to show where is the end of the list of operands. In a language where all functions had a fixed number of operands, prefix notation (or function invocation in general) could be used without any parentheses. Parentheses are also required for postfix notation when functions with variable number of operands are accepted (e.g. the sum of an arbitrary number of operands).
- kazinator 2y ago
  The parentheses are needed in Lisp because the input is data and not code. There are no "functions" and "arguments" in the data; that's a particular interpretation imposed on the data. We wouldn't want the data notation to have an implicit shape which depends on the programming language semantics of the symbols which appear in it, like their arity.
  - adrian_b 2y ago
    Code is a special kind of data, i.e. the kind of data that can be the input of an interpreter or compiler. A LISP program is not (arbitrary) data, i.e. it does not contain arbitrary lists. Giving data, i.e. an arbitrary list to any LISP interpreter or compiler will just result in an error message and a translation failure. A LISP program contains only invocations of functions or macros (besides special forms) and each invocation has an associated list of arguments. While the classic LISP convention is to write the function/macro name after the opening parenthesis, this notation is equivalent with writing first the name of the function/macro followed by a list of arguments enclosed in parentheses. Conceptually, data in LISP, which consists of lists of values, should have used a different kind of brackets for delimiting a list. Because of the limitations of the character sets available in old computers, the round parentheses have a dual role in LISP, as delimiters for lists that are data and as delimiters for the lists of arguments used by function/macro invocations. The two roles are differentiated by the use of the QUOTE special form, which is just a workaround for not using two different kinds of brackets, which would more clearly differentiate LISP data and LISP code. If all the LISP functions or macros had a fixed number of arguments, then the LISP code, i.e. the invocations of functions or macros, could have been written without parentheses. In that case, the LISP data, i.e. lists, could have been delimited by round parentheses without using the QUOTE special form, which would not have been necessary.
    - _19qg 2y ago
      LISP is short of "List Processor". It was developed as a language & system for processing lists. The programming language LISP was supposed to have M-Expressions (M -> Meta) for code and S-Expressions for data. For example a call to append two lists would have looked like this: append[listvar;(PARIS BERLIN NEWYORK TOKYO)] The arguments are enclosed in square brackets. The second argument is written as an S-Expression. S-Expressions were the data notation and were enclosed in parentheses. Symbols were upper case. The names of operators and variables were lower case. The append call then looked like this: (APPEND LISTVAR (QUOTE (PARIS BERLIN NEWYORK TOKYO))) A conditional would have been: [eq[car[l];0] → cons[(ZERO);cdr[l]]; T → x] Which in S-expression only syntax is: (COND ((EQ (CAR L)) (CONS (QUOTE (ZERO)) (CDR L))) (T X)) As you can see the conditional would have a special infix syntax. > Because of the limitations of the character sets available in old computers, the round parentheses have a dual role in LISP, as delimiters for lists that are data and as delimiters for the lists of arguments used by function/macro invocations. No, the syntax above wasn't actually implemented at first. The M-Expression/S-Expression combination was hand translated into S-Expressions, since the Interpreter and Compiler took lists as input. The reason why the syntax is like this is not a lack of characters or so. The reason is because the language early on worked on code as list data and not on code as text. The input and output was then of list data. The famous "Read Eval Print Loop" reads data, evaluates it and prints the result in data format. It was thought that a later version of LISP had the M-Expression/S-expression syntax as surface syntax. But that did not get any traction, because the S-expressions would be visible in the programming tools anyway: debugger, code inspector, code stepper. Thus it was more convenient to stay in the s-expression syntax, than to convert S-Expressions both from and into M-Expressions/S-Expressions. For example a stepper for LISP code might look like this. :s is the single step command: CL-USER 8 > (step (plus (minus 10 20) (plus 20 30))) (PLUS (MINUS 10 20) (PLUS 20 30)) -> :s (MINUS 10 20) -> :s 10 -> :S 10 20 -> :S 20 (- A B) -> :s A -> :S 10 B -> :s 20 -10 -10 (PLUS 20 30) -> and so on. The interpreter internally sees Lisp code as lists and just prints the lists while it steps the code... If we wanted M-Expressions, then the things would needed to be converted everywhere/everytime, which is much less elegant than leaving everything in one notation. LISP 2 was an effort to modernize LISP and to switch to a different syntax.
kazinator 2y ago
RPN also means that the programming notation is only that. It doesn't give us a data notation, other than a flat sequence of words. This is why Lisp and Forth are not really comparable. In Lisp, you can write made-up words that don't have any previous definition (let alone operator arity), and clump them into whatever nesting you want. As long as you don't try to pass that through the standard evaluator, it's fine.

by somat 2y ago

adrian_b 2y ago

The parentheses are needed in LISP only because many functions have a variable number of operands, so that parentheses are needed to show where is the end of the list of operands. In a language where all functions had a fixed number of operands, prefix notation (or function invocation in general) could be used without any parentheses. Parentheses are also required for postfix notation when functions with variable number of operands are accepted (e.g. the sum of an arbitrary number of operands).

kazinator 2y ago
The parentheses are needed in Lisp because the input is data and not code. There are no "functions" and "arguments" in the data; that's a particular interpretation imposed on the data. We wouldn't want the data notation to have an implicit shape which depends on the programming language semantics of the symbols which appear in it, like their arity.
- adrian_b 2y ago
  Code is a special kind of data, i.e. the kind of data that can be the input of an interpreter or compiler. A LISP program is not (arbitrary) data, i.e. it does not contain arbitrary lists. Giving data, i.e. an arbitrary list to any LISP interpreter or compiler will just result in an error message and a translation failure. A LISP program contains only invocations of functions or macros (besides special forms) and each invocation has an associated list of arguments. While the classic LISP convention is to write the function/macro name after the opening parenthesis, this notation is equivalent with writing first the name of the function/macro followed by a list of arguments enclosed in parentheses. Conceptually, data in LISP, which consists of lists of values, should have used a different kind of brackets for delimiting a list. Because of the limitations of the character sets available in old computers, the round parentheses have a dual role in LISP, as delimiters for lists that are data and as delimiters for the lists of arguments used by function/macro invocations. The two roles are differentiated by the use of the QUOTE special form, which is just a workaround for not using two different kinds of brackets, which would more clearly differentiate LISP data and LISP code. If all the LISP functions or macros had a fixed number of arguments, then the LISP code, i.e. the invocations of functions or macros, could have been written without parentheses. In that case, the LISP data, i.e. lists, could have been delimited by round parentheses without using the QUOTE special form, which would not have been necessary.
  - _19qg 2y ago
    LISP is short of "List Processor". It was developed as a language & system for processing lists. The programming language LISP was supposed to have M-Expressions (M -> Meta) for code and S-Expressions for data. For example a call to append two lists would have looked like this: append[listvar;(PARIS BERLIN NEWYORK TOKYO)] The arguments are enclosed in square brackets. The second argument is written as an S-Expression. S-Expressions were the data notation and were enclosed in parentheses. Symbols were upper case. The names of operators and variables were lower case. The append call then looked like this: (APPEND LISTVAR (QUOTE (PARIS BERLIN NEWYORK TOKYO))) A conditional would have been: [eq[car[l];0] → cons[(ZERO);cdr[l]]; T → x] Which in S-expression only syntax is: (COND ((EQ (CAR L)) (CONS (QUOTE (ZERO)) (CDR L))) (T X)) As you can see the conditional would have a special infix syntax. > Because of the limitations of the character sets available in old computers, the round parentheses have a dual role in LISP, as delimiters for lists that are data and as delimiters for the lists of arguments used by function/macro invocations. No, the syntax above wasn't actually implemented at first. The M-Expression/S-Expression combination was hand translated into S-Expressions, since the Interpreter and Compiler took lists as input. The reason why the syntax is like this is not a lack of characters or so. The reason is because the language early on worked on code as list data and not on code as text. The input and output was then of list data. The famous "Read Eval Print Loop" reads data, evaluates it and prints the result in data format. It was thought that a later version of LISP had the M-Expression/S-expression syntax as surface syntax. But that did not get any traction, because the S-expressions would be visible in the programming tools anyway: debugger, code inspector, code stepper. Thus it was more convenient to stay in the s-expression syntax, than to convert S-Expressions both from and into M-Expressions/S-Expressions. For example a stepper for LISP code might look like this. :s is the single step command: CL-USER 8 > (step (plus (minus 10 20) (plus 20 30))) (PLUS (MINUS 10 20) (PLUS 20 30)) -> :s (MINUS 10 20) -> :s 10 -> :S 10 20 -> :S 20 (- A B) -> :s A -> :S 10 B -> :s 20 -10 -10 (PLUS 20 30) -> and so on. The interpreter internally sees Lisp code as lists and just prints the lists while it steps the code... If we wanted M-Expressions, then the things would needed to be converted everywhere/everytime, which is much less elegant than leaving everything in one notation. LISP 2 was an effort to modernize LISP and to switch to a different syntax.

kazinator 2y ago

RPN also means that the programming notation is only that. It doesn't give us a data notation, other than a flat sequence of words. This is why Lisp and Forth are not really comparable. In Lisp, you can write made-up words that don't have any previous definition (let alone operator arity), and clump them into whatever nesting you want. As long as you don't try to pass that through the standard evaluator, it's fine.