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

31–40 of 74 posts

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

#31

Post by lisper »

gruseom wrote: post #24
lisper wrote: post #19

Earlier quoted context omitted.

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

> Could you allow (a b c) as a synonym for { 0 a 1 b 2 c }?

Yes, of course, but all you've done is re-invent vectors.

> you lose cdr (except by copying the rest of the vector)

Copying the rest of the vector is not semantically equivalent to CDR unless you are being purely functional. But you can actually implement CDR using displaced vectors.

> You must have something in mind other than this?

Could be :-)

Try writing EVAL for a vector-based Lisp and see what happens. In particular, when you're done, make a list of all the primitives you needed to employ in order to do it. There's a deep insight at the end of this process. (No, I'm not going to tell you what it is.)

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

#32

Post by apotheon »

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…

That's kind of an inappropriate response. Pointing out one has implemented Scheme with all the bells and whistles as a condition in which the implementor is still interested in Lisp implementations and similar stuff is not a pretension or a statement that it was some kind of tremendous feat.

I have a motorcycle, but I'm still interested in not only other motorcycles, but also bicycles. I don't think this makes me a pretentious douche.

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

#33

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…

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

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

#34

Post by apotheon »

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…

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.

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

#35

Post by lisper »

akkartik wrote: post #29
lisper wrote: post #19

Earlier quoted context omitted.

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.

> cdr gets expensive

Yes, that's one thing. But do you really need CDR?

> You could represent a list as a naked array of lisp pointers, but then cons gets expensive.

Actually, it's much worse than that. CONS actually becomes impossible. (Think about it.) But maybe there's something else that you can use instead of CONS?

> And good luck garbage collecting the vectors

Why would that be a problem? Extant Lisps collect vectors just fine.

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

#36

Post by gruseom »

lisper wrote: post #31
gruseom wrote: post #24

Earlier quoted context omitted.

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

> Could you allow (a b c) as a synonym for { 0 a 1 b 2 c }? Yes, of course, but all you've done is re-invent vectors. > you lose cdr (except by copying the rest of the vector) Copying the rest of the vector is not semantically equivalent to CDR unless you are being purely functional. But you can actually implement CDR using displaced vectors. > You must have something in mind other than this? Could be :-) Try writing…

Yes, of course, but all you've done is re-invent vectors.

True, but only as a device to keep the playing field open for any new benefits that might spring from universal hashmaps. What are they? I don't know, that's the question. Maybe there aren't any, but that itself would be interesting as a negative result (the L in Lisp is there for a reason).

What I'd really like to know is what would complete this sequence: list:Lisp, array:APL, stack:Forth, hashmap:?. That would be really interesting, no? And no one seems to be working on it, which is surprising given the ubiquity of hashmaps in modern languages (especially JS, but also Python, Lua, etc).

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

#38

Post by tikhonj »

premchai21 wrote: post #25
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 l…

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

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

#39

Post by schiptsov »

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. ^_^

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

#40

Post by akkartik »

lisper wrote: post #35
akkartik wrote: post #29

Earlier quoted context omitted.

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.

> cdr gets expensive Yes, that's one thing. But do you really need CDR? > You could represent a list as a naked array of lisp pointers, but then cons gets expensive. Actually, it's much worse than that. CONS actually becomes impossible. (Think about it.) But maybe there's something else that you can use instead of CONS? > And good luck garbage collecting the vectors Why would that be a problem? Extant Lisps collect v…

"Extant Lisps collect vectors just fine."

But they don't permit pointers inside the vectors, do they? I think if you permit internal pointers so you can have copyless cdr, computing reachability would get really expensive.

Post reply on HN