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

by jes5199 • 15 years ago

69 70 15 years ago

tantalor• 15 years 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• 15 years ago

He should call them SMexp.

(Mexp used []..out)

arethuza3• 15 years 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.

akkartik14• 15 years 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-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• 15 years 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.

arethuza3• 15 years 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

spacemanaki• 15 years 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.

oconnor0• 15 years ago

Does it use more JSON data types than arrays? The only examples are

  ["map", ....]

I don't see any `{ }`, etc.

jes51994• 15 years ago

Yes, it supports object literals as hashmaps. I'll try to add some more examples, soon.

benatkin• 15 years 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.

gruseom4• 15 years 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_• 15 years 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>?"

gruseom4• 15 years 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.

lisper9• 15 years 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?

gruseom4• 15 years ago

Could you allow (a b c) as a synonym for { 0 a 1 b 2 c }? That's more or less how JS deals with this, though JS feels messy under the hood.

what happens if you base a Lisp-like language on vectors instead of cons cells?

I want to know that too! One thing is that you lose cons and cdr (except by copying the vector), so you lose the ability to do most of the classic Lisp things efficiently. You must have something in mind other than this?

akkartik14• 15 years ago

I'll bite: cdr gets expensive? You could represent a list as a naked array of lisp pointers, but then cons gets expensive. And good luck garbage collecting the vectors.

akkartik14• 15 years ago

The point of json, I think, is that you'd only use associative arrays when you need them.

akkartik14• 15 years ago

Nobody seems to have mentioned the advantage of table literals: free syntax for ruby-style keyword arts.

jes51994• 15 years ago

  (defun foo (a b c))

could accept a map of variable names

  (foo {a: 1, b: 2, c: 3})

baddox• 15 years ago

> Associative arrays are unordered

That's not true in general, is it? It's just hash maps that are unordered. You can use a tree to represent an associative array (so the order of keys is found by a tree traversal), or a "worse" method like an association list (linked list). You can also just store a linked list of keys along with your hash map.

ekiru• 15 years ago

Smalltalk requires explicit labeling of all but the first argument (though they are ordered) for keyword messages. Good naming conventions can make this enjoyable (at least subjectively).

In a hashmap based lisp, I'd expect defun to look something like

(define-function: (foo-with-a: a b: b c: c) with-body: ...)

Of course, since you're using an unordered representation, one could instead say (with-body: ... define-function: (c: c b: b foo-with-a: a)), which is significantly more confusing. This also means you probably can't do implicit progn.

progn in general will probably be unpleasant, unfortunately, unless one includes syntactic sugar for ordered sequences, which might defeat the purpose of an associative-array-based Lisp.

The first thing I've noticed about a vector-based Lisp is that you actually need primitive integers so that you can do indexing, which isn't the case with cons-cell based Lisps.

sedachv2• 15 years ago

> Exercise for the reader: what happens if you base a Lisp-like language on vectors instead of cons cells?

I've been thinking about this in terms of a self-hosted Parenscript. What I see is a lot more pattern matching and map/reducing. Not altogether a bad thing.

premchai212• 15 years ago

Lua tables are a general-purpose associative structure that are used for both map and list functions in that language: there's syntactic sugar for both consecutive integer keys and simple string keys, and the former are used to make sequences (with internal, semantics-preserving optimizations in the Lua runtime for storing them). They strike me as one of the best options for a single core data structure if one were limited to one.

tikhonj• 15 years ago

I haven't use Lua, but that sounds exactly like JavaScript objects. JavaScript does get on very well with basically just these objects.

xyzzyz2• 15 years 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

yangyang• 15 years ago

Because it's pretty straightforward - there's very little parsing involved (in this case basically none).

lisper9• 15 years ago

No, there's a lot of parsing happening. It's just that you're using (part of) the Javascript parser to do it.

jes51994• 15 years 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.

lisper9• 15 years 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

raganwald4• 15 years ago

(cranky

You know, we have the upvote arrow for things that excite you, and the “Go read something else and comment on it” feature for things that don’t float your boat.

Clearly this is not spam and it is not off-topic. So:

You asked the OP and/or your fellow HNers why they upvoted this onto the front page. I ask you, why this comment, what value does it add to my life to read about how smart and educated you are?

What about all the people who haven’t seen an implementation of McCarthy’s Lisp? Do they not deserve to find this interesting? Should they turn in their HN accounts and head over to reddit?

I wrote an implementation of Scheme in Java with macros, tail call optimization, lambda hoisting, a bunch of stuff. Yet I find this interesting. Is there something wrong with me?

)

raganwald4• 15 years ago

Raganwald, you pretentious douche:

> I wrote an implementation of Scheme in Java with macros, tail call optimization, lambda hoisting, a bunch of stuff.

Greenspun’s Tenth Law is widely accepted, demonstrations of it in action add nothing of value to the programming community. Furthermore, writing a Scheme in Java is likely to be a project where you learned nothing of interest about Lisp or about Java.

—signed, Nikolai Bourbaki

apotheon2• 15 years ago

I think the "any interesting feature" in this case is the fact it uses JSON rather than s-expressions. This may not be a feature you think it needs, but it's interesting nonetheless.

xyzzyz2• 15 years ago

It still uses S-expressions, albeit with different kind of parentheses and separators. The whole point of S-expressions is that syntax is irrelevant.

ktusznio• 15 years 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• 15 years ago

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

sxephil• 15 years 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• 15 years ago

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

akkartik14• 15 years ago

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

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

Related Stories