4 ms·

>>because you're trying to explain lisp using lisp. There is no other way to explain it. Simply put: (1 2 3 4) Is a list (add-all 1 2 3 4) Is also

by kamaal 9y ago

>>because you're trying to explain lisp using lisp. There is no other way to explain it. Simply put: (1 2 3 4) Is a list (add-all 1 2 3 4) Is also a list (add-all 1 2 (add-all 3 4)) Is also a list In the above example the nested list is data to the main list. And there is all there is to it. In the last example, code just went in as data to another list(code as data). Which is also code.

joshuamorton 9y ago
This is a terrible example. I see no reason what you just gave isnt isomorphic to sum(1,2,sum(3,4)) Which is not "code as data". There's no reason for me to believe that the data isn't evaluated before being passed to the outer list.
- kamaal 9y ago
  True, but. sum(1,2,sum(3,4)) isn't a list. so sum() isn't a list member and things passed to it aren't list either. Lisp code is more consistent.
  - joshuamorton 9y ago
    No, it's equally consistent. In lisp, everything is a list. In the example I just gave, everything is a scalar. Like I said, this is a very bad justification for lisp.
    - kamaal 9y ago
      Everything isn't a scalar in the example you mentioned. sum() is a function and other things are numbers. In lisp there is only rule, everything is a list and the first element of the list is a operation to the remainder of the list. This is basically the whole language.
      - joshuamorton 9y ago
        >In lisp there is only rule, everything is a list Well no. `print` is not a list. `4` is not a list. `(print 4)` is a list containing the scalars `print` and `4`. The mechanics of lisp then say "apply the thing in the first position to the remainder of the list", but that's just notation. In python, `sum` is a function that can apply to a splatted sequence of scalars (note that it can also apply to a list, but this is different), so `sum(1,2,3,4,5)` works. It returns a scalar value. In lisp, `+` is a function that can apply to a list. It returns a scalar. `(+ 1 2 3)` resolves to `6`, not `(6)`. This is no different than python (or C actually, for this example). I understand lisp, I understand why "code is data" is a powerful tool. Your example is a bad one, it does not demonstrate why "code is data" is a powerful tool, because it does not actually demonstrate that code is data.
        kamaal 9y ago
        You seem to be suggesting (sum 1 2 3 4 5) and sum(1, 2, 3, 4, 5) are the same because they both return 15. That's just one way of looking at things. And that is true only if, that one is the only way of looking at things. Structurally (sum 1 2 3 4 5) and sum(1 2 3 4 5) are NOT similar. They are not even close, in fact they represent opposite schools of thought. There is a reason we are insisting on everything being list and them being uniform that way. That's because eventually we can use structures to modify themselves(recursion and macros). Which is why Lisp's (sum 1 2 3 4 5) and Python's sum(1 ,2, 3, 4, 5) can't be judged on what they return alone, they have to judged on the structure they represent. There is a interesting macro in Clojure named '-->'. This basically helps: (task3 (task2 (task1 work))) to be (--> work task1 task2 task3) These sort of transformations are not easy with sum(1,2,3,4,5) kind of syntax or even possible in many cases.
        joshuamorton 9y ago
        task3(task2(task1(work))) can, with the function apply(data, *funs): return reduce(lambda d, f: f(d), [data] + funs) be rewritten as apply(work, task1, task2, task3) Its possible in exactly the same set of cases, namely those where each task takes a single argument/is provided as a partial. I expect that `->` is implemented in clojure in much the same way (and [1] implies that, modulo some scaffolding and error checking, it is, although with a recursive, inlined impl of reduce) [1]: https://github.com/clojure/clojure/blob/08e592f4decbaa08de570ded9ac169785b1608f9/src/clj/clojure/core.clj#L1669 https://github.com/clojure/clojure/blob/08e592f4decbaa08de57...
- kbp 9y ago
  > I see no reason what you just gave isnt isomorphic to > sum(1,2,sum(3,4)) > Which is not "code as data" Says who? In Prolog it would be. Whether or not some syntax is a data structure literal depends entirely on the syntax of your language. Your example is isomorphic if you make the corresponding change to your language's data structure literals.
  - joshuamorton 9y ago
    Well but that's my point. The given example doesn't take advantage of any code as data features. It's entirely user transparent whether code is data or not. As a motivating example for why one should use lisp, or what lisp brings to the table, it's very poor, because it is wholly unmotivating and doesn't appear to demonstrate anything unique.

by kamaal 9y ago

joshuamorton 9y ago

This is a terrible example. I see no reason what you just gave isnt isomorphic to sum(1,2,sum(3,4)) Which is not "code as data". There's no reason for me to believe that the data isn't evaluated before being passed to the outer list.

kamaal 9y ago
True, but. sum(1,2,sum(3,4)) isn't a list. so sum() isn't a list member and things passed to it aren't list either. Lisp code is more consistent.
- joshuamorton 9y ago
  No, it's equally consistent. In lisp, everything is a list. In the example I just gave, everything is a scalar. Like I said, this is a very bad justification for lisp.
  - kamaal 9y ago
    Everything isn't a scalar in the example you mentioned. sum() is a function and other things are numbers. In lisp there is only rule, everything is a list and the first element of the list is a operation to the remainder of the list. This is basically the whole language.
    - joshuamorton 9y ago
      >In lisp there is only rule, everything is a list Well no. `print` is not a list. `4` is not a list. `(print 4)` is a list containing the scalars `print` and `4`. The mechanics of lisp then say "apply the thing in the first position to the remainder of the list", but that's just notation. In python, `sum` is a function that can apply to a splatted sequence of scalars (note that it can also apply to a list, but this is different), so `sum(1,2,3,4,5)` works. It returns a scalar value. In lisp, `+` is a function that can apply to a list. It returns a scalar. `(+ 1 2 3)` resolves to `6`, not `(6)`. This is no different than python (or C actually, for this example). I understand lisp, I understand why "code is data" is a powerful tool. Your example is a bad one, it does not demonstrate why "code is data" is a powerful tool, because it does not actually demonstrate that code is data.
      - kamaal 9y ago
        You seem to be suggesting (sum 1 2 3 4 5) and sum(1, 2, 3, 4, 5) are the same because they both return 15. That's just one way of looking at things. And that is true only if, that one is the only way of looking at things. Structurally (sum 1 2 3 4 5) and sum(1 2 3 4 5) are NOT similar. They are not even close, in fact they represent opposite schools of thought. There is a reason we are insisting on everything being list and them being uniform that way. That's because eventually we can use structures to modify themselves(recursion and macros). Which is why Lisp's (sum 1 2 3 4 5) and Python's sum(1 ,2, 3, 4, 5) can't be judged on what they return alone, they have to judged on the structure they represent. There is a interesting macro in Clojure named '-->'. This basically helps: (task3 (task2 (task1 work))) to be (--> work task1 task2 task3) These sort of transformations are not easy with sum(1,2,3,4,5) kind of syntax or even possible in many cases.
        joshuamorton 9y ago
        task3(task2(task1(work))) can, with the function apply(data, *funs): return reduce(lambda d, f: f(d), [data] + funs) be rewritten as apply(work, task1, task2, task3) Its possible in exactly the same set of cases, namely those where each task takes a single argument/is provided as a partial. I expect that `->` is implemented in clojure in much the same way (and [1] implies that, modulo some scaffolding and error checking, it is, although with a recursive, inlined impl of reduce) [1]: https://github.com/clojure/clojure/blob/08e592f4decbaa08de570ded9ac169785b1608f9/src/clj/clojure/core.clj#L1669 https://github.com/clojure/clojure/blob/08e592f4decbaa08de57...
kbp 9y ago
> I see no reason what you just gave isnt isomorphic to > sum(1,2,sum(3,4)) > Which is not "code as data" Says who? In Prolog it would be. Whether or not some syntax is a data structure literal depends entirely on the syntax of your language. Your example is isomorphic if you make the corresponding change to your language's data structure literals.
- joshuamorton 9y ago
  Well but that's my point. The given example doesn't take advantage of any code as data features. It's entirely user transparent whether code is data or not. As a motivating example for why one should use lisp, or what lisp brings to the table, it's very poor, because it is wholly unmotivating and doesn't appear to demonstrate anything unique.