8 ms·

Show HN: a Lisp that uses JSON instead of S-expressions (in .js)

69 points by jes5199 15y ago

tantalor 15y ago
How is this different than S-expressions? It seems equivalent modulo syntax. "They are typically represented in text by parenthesized, whitespace-separated sequences" - S-expression, Wikipedia, emphasis added.
- agumonkey 15y ago
  He should call them SMexp. (Mexp used []..out)
arethuza 15y ago
I really like Lisp (I was even paid to develop in it for 6 years) and these days I love JSON because of its Lisp-ish nature - but those expressions look damn ugly to me.
- akkartik 15y ago
  You could lose the quotes around strings, but you'd still have the commas. Maybe start with lisp and just add {key: value key2: value2} syntax for tables? It'd be useful to get ruby-style keyword args for free, at least. I spend a lot of time thinking about keyword args because I've been working on a lisp interpreter that supports them. Here's a webserver that is nice to read because of a crucial keyword arg (it starts with a colon): http://github.com/akkartik/wart/blob/460565a2e0/064http-serve.wart#L10 http://github.com/akkartik/wart/blob/460565a2e0/064http-serv... Like in python the keyword arg is always optional. You could delete it from this definition and it would behave the same. In conclusion: please try to include python-style keyword args in your next language. You never know when they'll come in handy.
  - anghyflawn 15y ago
    What's wrong with Common Lisp's keyword arguments? I'm not being snarky, just asking. I'd say CL works at least as well as Python in this respect.
    - akkartik 15y ago
      No, in Common Lisp you can't mix a keyword arg for a non-keyword param, or vice versa.
      - arethuza 15y ago
        Couldn't you write a macro to call functions using whatever mixture of keyword and non-keyword params you wanted? Or perhaps using some CLOS magic do to do this behind the scenes, e.g. no-applicable-method http://www.lispworks.com/documentation/HyperSpec/Body/f_no_app.htm#no-applicable-method http://www.lispworks.com/documentation/HyperSpec/Body/f_no_a... [NB It's been a long time since I did much Lisp]
        akkartik 15y ago
        Yes, that's basically what my repo does. It started out as an attempt to build 'arc using macros atop Common Lisp' like the original critics claimed could be done. I pretty much succeeded (and I've been told it's very readable) except that I ended up with a lisp-2. (Lately I've been building it in naked C to get out of that constraint: http://github.com/akkartik/wart/tree/unstable http://github.com/akkartik/wart/tree/unstable) I wasn't aware of no-applicable-method; thanks for that pointer.
      - sedachv 15y ago
        You can do (&rest all-args &key keyword1 (keyword 2 default2)) and then try to figure out all-args in the function body. How does Python handle mixing order of specifying keyword args positionally and with a keyword?
        akkartik 15y ago
        Python requires all args following a keyword arg to be keyword args: >>> def foo(a=0, b=1, c=2): return [a, b, c]; ... >>> foo(34) [34, 1, 2] >>> foo(b=34) [0, 34, 2] >>> foo(b=34, 35) File "<stdin>", line 1 SyntaxError: non-keyword arg after keyword arg I chose instead to simply bind args by position after keyword args have been taken: wart> (foo :b 34 35) (35 34 2)
  - arethuza 15y ago
    Common Lisp already has hashtables (not to mention simple association lists) what it doesn't have is a standard syntax for them. However, this is pretty easy to add with reader macros, for example: http://frank.kank.net/essays/hash.html http://frank.kank.net/essays/hash.html
  - spacemanaki 15y ago
    > Maybe start with lisp and just add {key: value key2: value2} syntax for tables? It'd be useful to get ruby-style keyword args for free, at least. This is how Clojure hacks around keyword args, and altho destructuring kind of makes up for it, it's not that pretty. (It's not pretty in Ruby either) Hash table literals are a nice addition to Lisp but I think it's kind of ugly to use them for keyword args.
    - akkartik 15y ago
      Ah, that's good to know, thanks.
oconnor0 15y ago
Does it use more JSON data types than arrays? The only examples are ["map", ....] I don't see any `{ }`, etc.
- jes5199 15y ago
  Yes, it supports object literals as hashmaps. I'll try to add some more examples, soon.
- benatkin 15y ago
  There is only one other composite data type besides arrays: objects. I don't think these are being used for invoking functions, but I think it would be interesting to try.
  - deleted 15y ago
    [deleted]
  - jes5199 15y ago
    An idea that I had was to use Objects to define namespaces, like when writing a library: { "myFunction": ["lambda", ...], "myFunction2": ["lambda", ...], } I can't decide if it has any advantage over the traditional "define" function, though.
gruseom 15y ago
I still think there's room for experimenting with a Lisp that has the hashmap (a.k.a. dictionary, associative array, property bag) as its organizing principle rather than the list. There's nothing better than hashmaps for exploratory programming. If there is something to be gained from building a Lisp in terms of them (from the ground up; I don't mean support for object literals), I'd like to know what it is. This has little to do with syntax.
- cyrus_ 15y ago
  You could argue that Javascript is a language with the hashmap as its central data structure. It doesn't have a macro system/quotations/other LISPy things, of course, but you can certainly frame your argument as "would JS benefit from <LISP feature>?"
  - gruseom 15y ago
    Yes, JS certainly is that (or comes close), which is the thing I like the most about JS and miss the most in Lisp - so much so that I wrote macros to allow me to use JS-style objects wherever possible. (I don't mean JS-style OO, which I avoid at all costs. Hate "this" and "prototype", love "a.b" and "a[b]".) The benefit of the hashmap for exploratory programming is so great that it raises the question of whether a fully regular/metaprogrammable Lisp could be evolved from it. Not clear if it would be practical, or add anything of value, but if it did it would be interesting.
- lisper 15y ago
  This presents a very thorny language design problem. Lists have this very nice property that they are ordered, which lets you attach implied semantics to the position of an element, e.g.: (defun foo (a b c) ...) We know this is a function defining because the symbol DEFUN is in the FIRST position of the list. Associative arrays are unordered, so you have to explicitly label everything: { top-level-form : defun, arguments : { 1 : a, 2 : b, 3 : c }, ... } Or something like that. You can see where that would get annoying. Exercise for the reader: what happens if you base a Lisp-like language on vectors instead of cons cells?
xyzzyz 15y ago
I'm sorry, but I cannot get excited over Yet Another Implementation of McCarthy's LISP[1]. If your Lisp had _any_ interesting feature, e.g. call/cc, or object system, or nifty macro system, or something else, then, maybe, but doing the the same old, trivial thing, again and again, does not seem very interesting for me. We don't usually see yet another Brainfuck interpreter, or yet another Fibonacci queue implementation on HN's front page, so why LISP? [1] - http://lib.store.yahoo.net/lib/paulgraham/jmc.lisp http://lib.store.yahoo.net/lib/paulgraham/jmc.lisp
- yangyang 15y ago
  Because it's pretty straightforward - there's very little parsing involved (in this case basically none).
  - lisper 15y ago
    No, there's a lot of parsing happening. It's just that you're using (part of) the Javascript parser to do it.
- jes5199 15y ago
  I didn't claim it was revolutionary, I just keep hearing LISP hackers say "there's no reason to care about XML or JSON if you've got S-Expressions, which are so much cleaner" This project is exercising (proving? refuting?) that claim. I recognize that this isn't the most ambitious project in the world, but it was a Thanksgiving-weekend hack. I'm thrilled that it got the 20 votes necessary to get it on the front page of HN.
  - lisper 15y ago
    I vote for "prove". All those extra and unnecessary quotes and commas. Blech. And all that extra ugliness just so you can re-use the JS parser? IMHO there's no excuse for this. It's really easy to write a parser that does the Right Thing, e.g.: http://www.flownet.com/ron/lisp/l.py http://www.flownet.com/ron/lisp/l.py
- raganwald 15y ago
ktusznio 15y ago
What is the purpose of the "quote" parameter? The only place it is in the code is here: else if(x[0] == 'quote'){ return x[1]; So why not just skip that extra verbosity? What am I missing?
- ohyes 15y ago
  Quote prevents evaluation. If you didn't quote it, x[1] would get evaluated as code.
sxephil 15y ago
Many people seem to confuse lisp's expressiveness with its syntax. Syntax is just the beginning. How you abuse it, to get things done is the more important thing. Please take time to explore this aspect more than those silly fracking parens.
fogus 15y ago
Any new McCarthy LISP implementation is destined to provoke the programming equivalent of "git offa mah lawn!"
akkartik 15y ago
Get thee to the arc forum, where the six of us will provide good entertainment: http://arclanguage.org/item?id=15422 http://arclanguage.org/item?id=15422
schiptsov 15y ago
The goal should be to make a language less noisy, not more. We need less symbols, not more. =) Less is more. Less types of parenthesis, less commas, less semicolons. If we can only incorporate the list-comprehension into a Lisp/Scheme language without creating a terrible mess, this is good enough, and one should stop here. Python3 is the best thing that could happen to *comprehension syntax. Everything else, especially Clojure, is much worse, because it breaks a great pair of clarity and beauty. ^_^

69 points by jes5199 15y ago

How is this different than S-expressions? It seems equivalent modulo syntax. "They are typically represented in text by parenthesized, whitespace-separated sequences" - S-expression, Wikipedia, emphasis added.

agumonkey 15y ago
He should call them SMexp. (Mexp used []..out)

arethuza 15y ago

I really like Lisp (I was even paid to develop in it for 6 years) and these days I love JSON because of its Lisp-ish nature - but those expressions look damn ugly to me.

akkartik 15y ago
You could lose the quotes around strings, but you'd still have the commas. Maybe start with lisp and just add {key: value key2: value2} syntax for tables? It'd be useful to get ruby-style keyword args for free, at least. I spend a lot of time thinking about keyword args because I've been working on a lisp interpreter that supports them. Here's a webserver that is nice to read because of a crucial keyword arg (it starts with a colon): http://github.com/akkartik/wart/blob/460565a2e0/064http-serve.wart#L10 http://github.com/akkartik/wart/blob/460565a2e0/064http-serv... Like in python the keyword arg is always optional. You could delete it from this definition and it would behave the same. In conclusion: please try to include python-style keyword args in your next language. You never know when they'll come in handy.
- anghyflawn 15y ago
  What's wrong with Common Lisp's keyword arguments? I'm not being snarky, just asking. I'd say CL works at least as well as Python in this respect.
  - akkartik 15y ago
    No, in Common Lisp you can't mix a keyword arg for a non-keyword param, or vice versa.
    - arethuza 15y ago
      Couldn't you write a macro to call functions using whatever mixture of keyword and non-keyword params you wanted? Or perhaps using some CLOS magic do to do this behind the scenes, e.g. no-applicable-method http://www.lispworks.com/documentation/HyperSpec/Body/f_no_app.htm#no-applicable-method http://www.lispworks.com/documentation/HyperSpec/Body/f_no_a... [NB It's been a long time since I did much Lisp]
      - akkartik 15y ago
        Yes, that's basically what my repo does. It started out as an attempt to build 'arc using macros atop Common Lisp' like the original critics claimed could be done. I pretty much succeeded (and I've been told it's very readable) except that I ended up with a lisp-2. (Lately I've been building it in naked C to get out of that constraint: http://github.com/akkartik/wart/tree/unstable http://github.com/akkartik/wart/tree/unstable) I wasn't aware of no-applicable-method; thanks for that pointer.
    - sedachv 15y ago
      You can do (&rest all-args &key keyword1 (keyword 2 default2)) and then try to figure out all-args in the function body. How does Python handle mixing order of specifying keyword args positionally and with a keyword?
      - akkartik 15y ago
        Python requires all args following a keyword arg to be keyword args: >>> def foo(a=0, b=1, c=2): return [a, b, c]; ... >>> foo(34) [34, 1, 2] >>> foo(b=34) [0, 34, 2] >>> foo(b=34, 35) File "<stdin>", line 1 SyntaxError: non-keyword arg after keyword arg I chose instead to simply bind args by position after keyword args have been taken: wart> (foo :b 34 35) (35 34 2)
- arethuza 15y ago
  Common Lisp already has hashtables (not to mention simple association lists) what it doesn't have is a standard syntax for them. However, this is pretty easy to add with reader macros, for example: http://frank.kank.net/essays/hash.html http://frank.kank.net/essays/hash.html
- spacemanaki 15y ago
  > Maybe start with lisp and just add {key: value key2: value2} syntax for tables? It'd be useful to get ruby-style keyword args for free, at least. This is how Clojure hacks around keyword args, and altho destructuring kind of makes up for it, it's not that pretty. (It's not pretty in Ruby either) Hash table literals are a nice addition to Lisp but I think it's kind of ugly to use them for keyword args.
  - akkartik 15y ago
    Ah, that's good to know, thanks.

oconnor0 15y ago

Does it use more JSON data types than arrays? The only examples are ["map", ....] I don't see any `{ }`, etc.

jes5199 15y ago
Yes, it supports object literals as hashmaps. I'll try to add some more examples, soon.
benatkin 15y ago
There is only one other composite data type besides arrays: objects. I don't think these are being used for invoking functions, but I think it would be interesting to try.
- deleted 15y ago
  [deleted]
- jes5199 15y ago
  An idea that I had was to use Objects to define namespaces, like when writing a library: { "myFunction": ["lambda", ...], "myFunction2": ["lambda", ...], } I can't decide if it has any advantage over the traditional "define" function, though.

gruseom 15y ago

I still think there's room for experimenting with a Lisp that has the hashmap (a.k.a. dictionary, associative array, property bag) as its organizing principle rather than the list. There's nothing better than hashmaps for exploratory programming. If there is something to be gained from building a Lisp in terms of them (from the ground up; I don't mean support for object literals), I'd like to know what it is. This has little to do with syntax.

cyrus_ 15y ago
You could argue that Javascript is a language with the hashmap as its central data structure. It doesn't have a macro system/quotations/other LISPy things, of course, but you can certainly frame your argument as "would JS benefit from <LISP feature>?"
- gruseom 15y ago
  Yes, JS certainly is that (or comes close), which is the thing I like the most about JS and miss the most in Lisp - so much so that I wrote macros to allow me to use JS-style objects wherever possible. (I don't mean JS-style OO, which I avoid at all costs. Hate "this" and "prototype", love "a.b" and "a[b]".) The benefit of the hashmap for exploratory programming is so great that it raises the question of whether a fully regular/metaprogrammable Lisp could be evolved from it. Not clear if it would be practical, or add anything of value, but if it did it would be interesting.
lisper 15y ago
This presents a very thorny language design problem. Lists have this very nice property that they are ordered, which lets you attach implied semantics to the position of an element, e.g.: (defun foo (a b c) ...) We know this is a function defining because the symbol DEFUN is in the FIRST position of the list. Associative arrays are unordered, so you have to explicitly label everything: { top-level-form : defun, arguments : { 1 : a, 2 : b, 3 : c }, ... } Or something like that. You can see where that would get annoying. Exercise for the reader: what happens if you base a Lisp-like language on vectors instead of cons cells?

xyzzyz 15y ago

I'm sorry, but I cannot get excited over Yet Another Implementation of McCarthy's LISP[1]. If your Lisp had _any_ interesting feature, e.g. call/cc, or object system, or nifty macro system, or something else, then, maybe, but doing the the same old, trivial thing, again and again, does not seem very interesting for me. We don't usually see yet another Brainfuck interpreter, or yet another Fibonacci queue implementation on HN's front page, so why LISP? [1] - http://lib.store.yahoo.net/lib/paulgraham/jmc.lisp http://lib.store.yahoo.net/lib/paulgraham/jmc.lisp

yangyang 15y ago
Because it's pretty straightforward - there's very little parsing involved (in this case basically none).
- lisper 15y ago
  No, there's a lot of parsing happening. It's just that you're using (part of) the Javascript parser to do it.
jes5199 15y ago
I didn't claim it was revolutionary, I just keep hearing LISP hackers say "there's no reason to care about XML or JSON if you've got S-Expressions, which are so much cleaner" This project is exercising (proving? refuting?) that claim. I recognize that this isn't the most ambitious project in the world, but it was a Thanksgiving-weekend hack. I'm thrilled that it got the 20 votes necessary to get it on the front page of HN.
- lisper 15y ago
  I vote for "prove". All those extra and unnecessary quotes and commas. Blech. And all that extra ugliness just so you can re-use the JS parser? IMHO there's no excuse for this. It's really easy to write a parser that does the Right Thing, e.g.: http://www.flownet.com/ron/lisp/l.py http://www.flownet.com/ron/lisp/l.py
raganwald 15y ago

ktusznio 15y ago

What is the purpose of the "quote" parameter? The only place it is in the code is here: else if(x[0] == 'quote'){ return x[1]; So why not just skip that extra verbosity? What am I missing?

ohyes 15y ago
Quote prevents evaluation. If you didn't quote it, x[1] would get evaluated as code.

sxephil 15y ago

Many people seem to confuse lisp's expressiveness with its syntax. Syntax is just the beginning. How you abuse it, to get things done is the more important thing. Please take time to explore this aspect more than those silly fracking parens.

fogus 15y ago

Any new McCarthy LISP implementation is destined to provoke the programming equivalent of "git offa mah lawn!"

akkartik 15y ago

Get thee to the arc forum, where the six of us will provide good entertainment: http://arclanguage.org/item?id=15422 http://arclanguage.org/item?id=15422

schiptsov 15y ago

The goal should be to make a language less noisy, not more. We need less symbols, not more. =) Less is more. Less types of parenthesis, less commas, less semicolons. If we can only incorporate the list-comprehension into a Lisp/Scheme language without creating a terrible mess, this is good enough, and one should stop here. Python3 is the best thing that could happen to *comprehension syntax. Everything else, especially Clojure, is much worse, because it breaks a great pair of clarity and beauty. ^_^