Live data from Hacker News

S-expressions

igor.io

41–46 of 46 posts

Re: S-expressions

#41
post #32
post #27

Earlier quoted context omitted.

That's an nice idea, using # as a straight-up constructor. I've always found hash-tables to be a colossal pain to create in Common Lisp. I tried to create a special JSON-esque syntax in CL for them, but it wasn't a smooth semantic drop-in.

Yeah I think it is pretty neat too. I had a couple of design ideas. This way I can persist some other structures (from Python for ex): For set(): (#set v1 v2 ...) For circular object graphs, I can encode an object reference to avoid serializing the same object twice: (#ref oid) Then of course there are custom class names I can pass in to serializer and deserializer: (#MyClass (attr1 val1) (attr2 val2) ...) This might…

CL uses # as a special character; I rewrote the idea into the (CL-standard idiom) `make-map` nomenclature: https://gist.github.com/4709844

But yea, I hadn't thought of particularly using this idea. It's a good idea from Python (or maybe its older than that, IDK). :-)

Re: S-expressions

#42

If you love the expressiveness of S-expressions but hate the super noisy parenthesis, check the sugar version, called "sweet-expressions". http://readable.sourceforge.net/

You have to love the intellectual dishonesty of that site you linked to: they quote Paul Graham whose not just a big Lisp dialects advocate but also probably partly responsible for the regain of interest in Lisp dialects... Yet they quote pg as if he ever said that Lisp source code were ugly. Regarding the "noisyness", I really think that the one and only place that you can really criticize is the closing of the oute…

Agreed. You don't hear people bitching about all the {}'s in C and Java, but when lisp comes up you'd think parens were responsible for the plague.

Get a real editor and deal with it. Once you write your first macro, you'll realize how stupid all the whining was and why homoiconicity is in many aspects superior to other syntaxes without sacrificing much at all.

Re: S-expressions

#43
post #34

If you love the expressiveness of S-expressions but hate the super noisy parenthesis, check the sugar version, called "sweet-expressions". http://readable.sourceforge.net/

I find that alternative syntaxes like this for S-expressions tend to get really awkward when confronted with real-world Lisp code. For example, the following code sample†: (define (pointless-function a z) (let* ((numbers (map (lambda (n) (* n 2)) (range a z))) (multiple-of-three? (lambda (n) (= 0 (mod n 3)))) (multiples-of-three (filter multiple-of-three? numbers))) (printf "Your numbers are: ~s~%" multiples-of-three…

My ideal s-expression syntax would allow you to replace some brackets with whitespace. For instance, your function would become:

  define (pointless-function a z)
    let*
        numbers (map (lambda (n) (* n 2)) (range a z))
        multiple-of-three? (lambda (n) (= 0 (mod n 3)))
        multiples-of-three (filter multiple-of-three? numbers)
      printf "Your numbers are: ~s~%" multiples-of-three
Obviously there are some down-sides, but the main idea is that the mapping should have no knowledge of the language details, and be a pure s-expression transform. I really should explore the idea more. I have no idea whether the above example can even be uniquely parsed.

Re: S-expressions

#44

Earlier quoted context omitted.

You have to love the intellectual dishonesty of that site you linked to: they quote Paul Graham whose not just a big Lisp dialects advocate but also probably partly responsible for the regain of interest in Lisp dialects... Yet they quote pg as if he ever said that Lisp source code were ugly. Regarding the "noisyness", I really think that the one and only place that you can really criticize is the closing of the oute…

Agreed. You don't hear people bitching about all the {}'s in C and Java, but when lisp comes up you'd think parens were responsible for the plague. Get a real editor and deal with it. Once you write your first macro, you'll realize how stupid all the whining was and why homoiconicity is in many aspects superior to other syntaxes without sacrificing much at all.

Well, a lot of it is that Lisp uses parens for everything while most other languages use a variety of syntactic tools.

For example, declaring a bunch of variables in Lisp:

  (let ((a 1)
        (b 2)
        (c 3))
    (format t "They are ~D, ~D and ~D~%" a b c))
The same thing in C

  int a = 1;
  int b = 2;
  int c = 3;
  printf("They are %d, %d and %d\n", a, b, c);
Lisp used parens around the whole construct, as well as around the assignment list, around each individual assignment and to do the printing. C completely eschews some of these parens and uses = and ; to fill essentially the same role as the others. Only `printf()` keeps the parens. In short, C has lots of different syntactic symbols, while Lisp has relatively few.

To illustrate further, Clojure gets the "OMG parens" complaint a lot less than most Lisps because it consciously shies away from the traditional parens-everywhere look of Lisp. For example, the above code in Clojure:

  (let [a 1
        b 2
        c 3]
    (printf "They are %d, %d and %d\n" a b c))
Still more parens than C, but the difference is marked — the assignment block is clearly set apart by syntax, and the assignments are paired by juxtaposition rather than by grouping into lists. Parens are used relatively sparingly.

This isn't to say that this is really a problem, but the idea that parens in Lisp are equivalent to brackets in C isn't really right either. Parens in Lisp are used in place of nearly every bit of syntax in C, from braces to equals signs to semicolons.

Re: S-expressions

#46
post #27
post #19

Earlier quoted context omitted.

It is if you want to differentiate between a list of lists and a map. Maps are not natively supported in s-expressions. So there is a need to create a sub-language to handle special data structures. I have done this as well. But I use a special namespace '#dict' for example. So it would be (#dict (k1 v1) (k2 v2)) This way there is less of a chance of collision between data and this sub-language. It also allows for ex…

That's an nice idea, using # as a straight-up constructor. I've always found hash-tables to be a colossal pain to create in Common Lisp. I tried to create a special JSON-esque syntax in CL for them, but it wasn't a smooth semantic drop-in.

Isn't calling it a "colossal pain" a bit of hyperbole? A simple wrapper function should take away most of the pain.
Post reply on HN