3 ms·

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.

by kamaal 9y ago

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...
        kamaal 9y ago
        Sorry but again, using a workaround doesn't mean they are the same. When I mean same, I mean structurally.
        joshuamorton 9y ago
        But they are structurally the same that's my point. I can implement -> practically directly. There is no structural difference that you've demonstrated. That is not idiomatic and common in Python didn't mean that there is some structural difference. Basically the transformations you're describing are doable with regex, which is the opposite of powerful. What you've done is take code is data, which is powerful, and confuse that with "supports varags", which is less powerful, and claim that the second is unique and powerful when it is not unique, and not uniquely powerful.

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.

by 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...
      - kamaal 9y ago
        Sorry but again, using a workaround doesn't mean they are the same. When I mean same, I mean structurally.
        joshuamorton 9y ago
        But they are structurally the same that's my point. I can implement -> practically directly. There is no structural difference that you've demonstrated. That is not idiomatic and common in Python didn't mean that there is some structural difference. Basically the transformations you're describing are doable with regex, which is the opposite of powerful. What you've done is take code is data, which is powerful, and confuse that with "supports varags", which is less powerful, and claim that the second is unique and powerful when it is not unique, and not uniquely powerful.