Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 74 posts

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

#21

Post by lisper »

yangyang wrote: post #13
xyzzyz wrote: post #9

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 implementati…

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

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

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

#22

Post by gruseom »

cyrus_ wrote: post #15
gruseom wrote: post #8

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 ha…

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 ?"

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.

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

#23

Post by raganwald »

raganwald wrote: post #20
xyzzyz wrote: post #9

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 implementati…

(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? Wha…

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

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

#24

Post by gruseom »

lisper wrote: post #19
gruseom wrote: post #8

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 ha…

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, argu…

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?

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

#25

Post by premchai21 »

gruseom wrote: post #8

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 ha…

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.

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

#26

Post by appamatto »

raganwald wrote: post #23
raganwald wrote: post #20

Earlier quoted context omitted.

(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? Wha…

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, Nikola…

Misapplication? I thought the Law was meant to describe accidental implementations of Lisp rather than overt ones.

In other words, "the complicated system you made _just happens_ to contain a Lisp, and if you had noticed that requirement in the first place its design would have been cleaner."

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

#28

Post by raganwald »

appamatto wrote: post #26
raganwald wrote: post #23

Earlier quoted context omitted.

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, Nikola…

Misapplication? I thought the Law was meant to describe accidental implementations of Lisp rather than overt ones. In other words, "the complicated system you made _just happens_ to contain a Lisp, and if you had noticed that requirement in the first place its design would have been cleaner."

I think you have captured the spirit of the law. The project in question was the development of a scripting language for something-or-other, so this wasn’t an accidental implementation of Lisp, it was done with malice aforethought.

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

#29

Post by akkartik »

lisper wrote: post #19
gruseom wrote: post #8

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 ha…

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, argu…

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.

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

#30

Post by akkartik »

lisper wrote: post #19
gruseom wrote: post #8

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 ha…

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, argu…

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