5 ms·

JSON is much more popular than s-expressions, and not just accidentally. Explicit, compact syntax for both lists and key-value pairs is The Right Thing in a lan

JSON is much more popular than s-expressions, and not just accidentally. Explicit, compact syntax for both lists and key-value pairs is The Right Thing in a language like this. { "x": [ { "y": "a", "z": 23, "q": [ 54, 32, 45 ] } ], "r": 43 }

habibur 18y ago
Why can't we keep the indents and drop the parens?
- smallpaul 18y ago
  YAML?
- deleted 18y ago
  [deleted]
- ilkhd2 18y ago
  1.hmm, well, if you try it you'll see that at least in the area of programming languages, after spending some time you'll see that you reinvented s-expressions. 2. can be very interesting to see for example this (sum of every vector-element) in json/yaml... (defn sum-vec [vec] (let [vec-len (count vec)] (loop [idx 0 acc 0] (if (< idx vec-len) (recur (inc idx) (+ acc (vec idx))) acc))))
  - smallpaul 18y ago
    I don't want that in my json/yaml. If I have Javascript then I already have mobile code. If I'm using json in a situation where I don't have a Javascript interpreter, then I probably don't have a Lisp interpreter around either.
    - failrate 18y ago
      A decent JSON parser is also only a day's worth of work or less in just about any language. My experience is that it is as little as and possibly less initial development and maintenance as a custom flat-file format or a really robust csv parser.
- scott_s 18y ago
  It would make data generation more difficult. When you emit any given data, you'd have to know its level of nesting to get the correct number of indents. Using begin and end tokens (whatever they are) makes that much easier. (I actually prefer Python's style of using indentation to indicate blocks, but I recognize generating such code is harder than code with tokens.)
  - abecedarius 18y ago
    You don't have to know the level of nesting; you can add indents afterward just as easily as you can wrap a subexpression in parentheses afterward. def indent(code): return code.replace('\n', '\n ')
    - scott_s 18y ago
      In my current project, I've implemented a source-to-source compiler. In the places where I emit C code, I usually don't have a handle to the scopes above me. I could get one, but it would take more work. The code I generate has no indents and no newlines. Not having to keep track of these makes life simpler. To make my generated code more legible, I just run indent on it.
      - abecedarius 18y ago
        I've written C code emitters too. FWIW, I've found nicely-indented output templates help to keep the source code of the emitter clear (and with no need to get at the enclosing scopes). But the question you raised was whether indentation-only was harder to generate, and I'd say no, because code.replace('\n', '\n ') is as simple as '{' + code + '}', if slightly slower.
        scott_s 18y ago
        And my point was that with the transformations I generate, I don't just say '{' + code + '}'. I'm applying transformations to existing code, not generating all of my own code from scratch. Again, I see no point in making efforts to generate clean looking code when utilities like indent exist.
- rgoddard 18y ago
  {} means object [] means array So you would not be able to just drop them, since they mean two different things.
  - sharkbrainguy 18y ago
    for associative arrays foo: bar, for non-associative foo, bar, surely this is unambiguous? x: y: "a", z: "23", q: 54, 32, 45 , r: 43
anamax 18y ago
JSON is a subset of s-expressions. (Yes, s-expressions provide explicit and compact representations for mappings. They also handle other kinds of objects.) The other difference is that there are JSON parsers and generators for more languages and they're not programmable.
- smallpaul 18y ago
  Don't tell me. Show me. Please translate the example into s-expressions.
  - anamax 18y ago
    I'm confused why you don't see this as obvious. (There are several possible ways to represent mappings. I picked one that was close to something that you're happy with.) { ("x" ( { ("y" "a") ("z" 23) ("q" ( 54 32 45 )) } )) ("r" 43) }
    - time_management 18y ago
      Clojure uses {} for maps, #{} for sets, and [] for vectors, and vectors are used in function definitions, let statements, etc. This slight decrease in regularity makes a lot of functionality more visible. For example: SBCL: (defun f (x y) (let ((z (gethash x :a))) (+ z y)) Clojure (defn f [x y] (let [z (get x :a)] (+ x y))) Having syntax for maps is a huge win. Like ML's pattern matching, it's one of those things that changes your coding style entirely for the better, in a way that you wouldn't predict just by looking at the feature. The only think I miss from CL when I work in Clojure is keyword arguments to functions. There, the Clojure way is a bit worse: (defun f (x &key y z) (list x y z)) (f 2 :z 3) => (2 nil 3) (defn f [x {y :y z :z}] (list x y z)) (f 2 {:z 3}) => (2 nil 3)
      - anamax 18y ago
        > (defun f (x y) (let ((z (gethash x :a))) (+ z y)) vs > (defn f [x y] (let [z (get x :a)] (+ x y))) The CL defn of f is a function that is called with two arguments. That function is called like "(f a b)" If the Clojure definition is comparable, that is, the call looks like "(f a b)", why are []s used in the definition and the let? > This slight decrease in regularity makes a lot of functionality more visible. What functionality? x,y aren't part of a vector and neither is z. (x,y may come from a vector in the caller, but I'll assume that the defn works if they don't, so that shouldn't matter.)

habibur 18y ago

Why can't we keep the indents and drop the parens?

smallpaul 18y ago
YAML?
deleted 18y ago
[deleted]
ilkhd2 18y ago
1.hmm, well, if you try it you'll see that at least in the area of programming languages, after spending some time you'll see that you reinvented s-expressions. 2. can be very interesting to see for example this (sum of every vector-element) in json/yaml... (defn sum-vec [vec] (let [vec-len (count vec)] (loop [idx 0 acc 0] (if (< idx vec-len) (recur (inc idx) (+ acc (vec idx))) acc))))
- smallpaul 18y ago
  I don't want that in my json/yaml. If I have Javascript then I already have mobile code. If I'm using json in a situation where I don't have a Javascript interpreter, then I probably don't have a Lisp interpreter around either.
  - failrate 18y ago
    A decent JSON parser is also only a day's worth of work or less in just about any language. My experience is that it is as little as and possibly less initial development and maintenance as a custom flat-file format or a really robust csv parser.
scott_s 18y ago
It would make data generation more difficult. When you emit any given data, you'd have to know its level of nesting to get the correct number of indents. Using begin and end tokens (whatever they are) makes that much easier. (I actually prefer Python's style of using indentation to indicate blocks, but I recognize generating such code is harder than code with tokens.)
- abecedarius 18y ago
  You don't have to know the level of nesting; you can add indents afterward just as easily as you can wrap a subexpression in parentheses afterward. def indent(code): return code.replace('\n', '\n ')
  - scott_s 18y ago
    In my current project, I've implemented a source-to-source compiler. In the places where I emit C code, I usually don't have a handle to the scopes above me. I could get one, but it would take more work. The code I generate has no indents and no newlines. Not having to keep track of these makes life simpler. To make my generated code more legible, I just run indent on it.
    - abecedarius 18y ago
      I've written C code emitters too. FWIW, I've found nicely-indented output templates help to keep the source code of the emitter clear (and with no need to get at the enclosing scopes). But the question you raised was whether indentation-only was harder to generate, and I'd say no, because code.replace('\n', '\n ') is as simple as '{' + code + '}', if slightly slower.
      - scott_s 18y ago
        And my point was that with the transformations I generate, I don't just say '{' + code + '}'. I'm applying transformations to existing code, not generating all of my own code from scratch. Again, I see no point in making efforts to generate clean looking code when utilities like indent exist.
rgoddard 18y ago
{} means object [] means array So you would not be able to just drop them, since they mean two different things.
- sharkbrainguy 18y ago
  for associative arrays foo: bar, for non-associative foo, bar, surely this is unambiguous? x: y: "a", z: "23", q: 54, 32, 45 , r: 43

anamax 18y ago

JSON is a subset of s-expressions. (Yes, s-expressions provide explicit and compact representations for mappings. They also handle other kinds of objects.) The other difference is that there are JSON parsers and generators for more languages and they're not programmable.

smallpaul 18y ago
Don't tell me. Show me. Please translate the example into s-expressions.
- anamax 18y ago
  I'm confused why you don't see this as obvious. (There are several possible ways to represent mappings. I picked one that was close to something that you're happy with.) { ("x" ( { ("y" "a") ("z" 23) ("q" ( 54 32 45 )) } )) ("r" 43) }
  - time_management 18y ago
    Clojure uses {} for maps, #{} for sets, and [] for vectors, and vectors are used in function definitions, let statements, etc. This slight decrease in regularity makes a lot of functionality more visible. For example: SBCL: (defun f (x y) (let ((z (gethash x :a))) (+ z y)) Clojure (defn f [x y] (let [z (get x :a)] (+ x y))) Having syntax for maps is a huge win. Like ML's pattern matching, it's one of those things that changes your coding style entirely for the better, in a way that you wouldn't predict just by looking at the feature. The only think I miss from CL when I work in Clojure is keyword arguments to functions. There, the Clojure way is a bit worse: (defun f (x &key y z) (list x y z)) (f 2 :z 3) => (2 nil 3) (defn f [x {y :y z :z}] (list x y z)) (f 2 {:z 3}) => (2 nil 3)
    - anamax 18y ago
      > (defun f (x y) (let ((z (gethash x :a))) (+ z y)) vs > (defn f [x y] (let [z (get x :a)] (+ x y))) The CL defn of f is a function that is called with two arguments. That function is called like "(f a b)" If the Clojure definition is comparable, that is, the call looks like "(f a b)", why are []s used in the definition and the let? > This slight decrease in regularity makes a lot of functionality more visible. What functionality? x,y aren't part of a vector and neither is z. (x,y may come from a vector in the caller, but I'll assume that the defn works if they don't, so that shouldn't matter.)