5 ms·

So parens are just a quoted list? Seems a little unnecessary but I wasn’t alive so I guess I don’t know.

by mruts 8y ago

lisper 8y ago
> So parens are just a quoted list? Seems a little unnecessary It's a very useful distinction. In regular Lisp, lists are the only data type that is not self-evaluating. This leads to confusion because the serialization of a list can mean different things depending on context. Consider: (eval (add 1 2)) (eval '(add 1 2)) Those forms both produce the same result when evaluated. It happens by two very different execution paths, but this is not immediately apparent when you run this code. So a beginner may well be surprised to learn that the following: (eval x) (eval 'x) may or may not produce the same result. So it's genuinely helpful to have two types of lists, one of which is self-evaluating, and the other which isn't, and to have syntax that distinguishes the two. Another example: all of these produce the same result: (eval (add 1 2)) (eval (eval (add 1 2))) (eval (eval (eval (add 1 2)))) and so on. But this is true only because (+ 1 2) evaluates to 3 which is self-evaluating. Contrast that with, say: (eval (cons 1 2)) which immediately produces an error. Trying to figure out why "add" "works" and cons doesn't and how to "fix" this can be very frustrating for a beginner.
- kmill 8y ago
  In MDL, (1 <+ 2 3> 4) -> (1 5 4) '(1 <+ 2 3> 4) -> (1 <+ 2 3> 4) '<1 <+ 2 3> 4) -> <1 <+ 2 3> 4> <1 <+ 2 3> 4> -> an error (probably that 5 is not structured) Parens give list literals like in most modern languages. An interesting thing about MDL is that both FORM and LIST have the same "PRIMTYPE" so all the usual lisp-like list manipulations apply to both. A strange thing is the way these are implemented: pretty much every object (with fixed-size allocation) has a NEXT pointer, and a FORM or a LIST is an object that has a pointer (possibly null) to the first object. Taking the tail of a list entails allocating a new LIST object that points to the second element. You may wonder: how can an element be part of two lists at the same time? Well, you copy the object since it's in a 36-bit word. (Objects that do not fit in such a word are put in lists using a special DEFER object that points to it.)
  - taradinoc 8y ago
    This is described in glorious high-definition ASCII art in Appendix 1 of The MDL Programming Language: https://github.com/taradinoc/mdl-docs/blob/master/docs/appendix-1-a-look-inside.markdown https://github.com/taradinoc/mdl-docs/blob/master/docs/appen...
  - kazinator 8y ago
    I don't agree with your assessment; parens are not giving a list literal since (1 <+ 2 3> 4) has been reduced to (1 5 4). Calculation cannot take place in a literal, by definition. What this is doing is binding the parentheses to a list constructor. I.e. (1 2 3) is really something like <list 1 2 3>. It's more like a quasiliteral (like Lisp's backquote). Unfortunately, the fact that the printed representation of a list is the same as the code which calculates it makes things somewhat "muddled", pun intended. What if we have this: '(1 2 3 (4 5 6)). What is (4 5 6) here? It can't be the list (4 5 6), because (4 5 6) is code that constructs that list. Using the same printed rep for both is a very bad idea.
    - kmill 8y ago
      I meant list literal in the Python-like sense, so apologies for the confusion there. In MDL, parens and angle brackets denote LISTs and FORMs, respectively. These are both objects with the same PRIMTYPE (a linked list) but are tagged differently. The evaluator evaluates these objects differently from each other: a LIST has each of its elements evaluated, with the results put in a new LIST. It truly is distinct from a FORM that has the same effect. Distinctions like this were designed to make the corresponding parts of Lisp (like what you mentioned) less confusing. Indeed, in your quote example, that (4 5 6) is a LIST, not a FORM, avoiding the very bad idea. Quasiquotation pretty much doesn't need to exist because of the ! sequence "operator" for splicing lists into lists and forms.
      - taradinoc 8y ago
        >Quasiquotation pretty much doesn't need to exist because of the ! sequence "operator" for splicing lists into lists and forms. Hmm... I guess I don't know everything quasiquoting is used for in Lisp, but in MDL and ZIL, segments don't really solve the problem that quasiquoting does when it comes to writing macros. That is, I usually want to use macros to generate code according to a template: <PRSI? ,FOO> should become <==? ,PRSI ,FOO> The way to write that macro is to call FORM to build the form: <DEFMAC PRSI? (X) <FORM ==? ',PRSI .X>> But if it's a complex block of code, and the blanks I want to fill in are deeply nested, the template quickly becomes unreadable, because every structure turns into a form, and every form turns into a call to FORM.

So parens are just a quoted list? Seems a little unnecessary but I wasn’t alive so I guess I don’t know.

by mruts 8y ago

So parens are just a quoted list? Seems a little unnecessary but I wasn’t alive so I guess I don’t know.

> So parens are just a quoted list? Seems a little unnecessary It's a very useful distinction. In regular Lisp, lists are the only data type that is not self-evaluating. This leads to confusion because the serialization of a list can mean different things depending on context. Consider: (eval (add 1 2)) (eval '(add 1 2)) Those forms both produce the same result when evaluated. It happens by two very different execution paths, but this is not immediately apparent when you run this code. So a beginner may well be surprised to learn that the following: (eval x) (eval 'x) may or may not produce the same result. So it's genuinely helpful to have two types of lists, one of which is self-evaluating, and the other which isn't, and to have syntax that distinguishes the two. Another example: all of these produce the same result: (eval (add 1 2)) (eval (eval (add 1 2))) (eval (eval (eval (add 1 2)))) and so on. But this is true only because (+ 1 2) evaluates to 3 which is self-evaluating. Contrast that with, say: (eval (cons 1 2)) which immediately produces an error. Trying to figure out why "add" "works" and cons doesn't and how to "fix" this can be very frustrating for a beginner.

kmill 8y ago
In MDL, (1 <+ 2 3> 4) -> (1 5 4) '(1 <+ 2 3> 4) -> (1 <+ 2 3> 4) '<1 <+ 2 3> 4) -> <1 <+ 2 3> 4> <1 <+ 2 3> 4> -> an error (probably that 5 is not structured) Parens give list literals like in most modern languages. An interesting thing about MDL is that both FORM and LIST have the same "PRIMTYPE" so all the usual lisp-like list manipulations apply to both. A strange thing is the way these are implemented: pretty much every object (with fixed-size allocation) has a NEXT pointer, and a FORM or a LIST is an object that has a pointer (possibly null) to the first object. Taking the tail of a list entails allocating a new LIST object that points to the second element. You may wonder: how can an element be part of two lists at the same time? Well, you copy the object since it's in a 36-bit word. (Objects that do not fit in such a word are put in lists using a special DEFER object that points to it.)
- taradinoc 8y ago
  This is described in glorious high-definition ASCII art in Appendix 1 of The MDL Programming Language: https://github.com/taradinoc/mdl-docs/blob/master/docs/appendix-1-a-look-inside.markdown https://github.com/taradinoc/mdl-docs/blob/master/docs/appen...
- kazinator 8y ago
  I don't agree with your assessment; parens are not giving a list literal since (1 <+ 2 3> 4) has been reduced to (1 5 4). Calculation cannot take place in a literal, by definition. What this is doing is binding the parentheses to a list constructor. I.e. (1 2 3) is really something like <list 1 2 3>. It's more like a quasiliteral (like Lisp's backquote). Unfortunately, the fact that the printed representation of a list is the same as the code which calculates it makes things somewhat "muddled", pun intended. What if we have this: '(1 2 3 (4 5 6)). What is (4 5 6) here? It can't be the list (4 5 6), because (4 5 6) is code that constructs that list. Using the same printed rep for both is a very bad idea.
  - kmill 8y ago
    I meant list literal in the Python-like sense, so apologies for the confusion there. In MDL, parens and angle brackets denote LISTs and FORMs, respectively. These are both objects with the same PRIMTYPE (a linked list) but are tagged differently. The evaluator evaluates these objects differently from each other: a LIST has each of its elements evaluated, with the results put in a new LIST. It truly is distinct from a FORM that has the same effect. Distinctions like this were designed to make the corresponding parts of Lisp (like what you mentioned) less confusing. Indeed, in your quote example, that (4 5 6) is a LIST, not a FORM, avoiding the very bad idea. Quasiquotation pretty much doesn't need to exist because of the ! sequence "operator" for splicing lists into lists and forms.
    - taradinoc 8y ago
      >Quasiquotation pretty much doesn't need to exist because of the ! sequence "operator" for splicing lists into lists and forms. Hmm... I guess I don't know everything quasiquoting is used for in Lisp, but in MDL and ZIL, segments don't really solve the problem that quasiquoting does when it comes to writing macros. That is, I usually want to use macros to generate code according to a template: <PRSI? ,FOO> should become <==? ,PRSI ,FOO> The way to write that macro is to call FORM to build the form: <DEFMAC PRSI? (X) <FORM ==? ',PRSI .X>> But if it's a complex block of code, and the blanks I want to fill in are deeply nested, the template quickly becomes unreadable, because every structure turns into a form, and every form turns into a call to FORM.