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

61–70 of 74 posts

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

#61

Post by ekiru »

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…

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.

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

#62

Post by akkartik »

lisper wrote: post #58
akkartik wrote: post #54

Earlier quoted context omitted.

(a (b (c . nil)) ^ ^ | | | | A B If you implement lists as vectors with car/cdr (I'm still thinking about your other questions) and choose to have cdr not copy results out of the original cell, you can end up in the (rope-like) situation above with pointer B (value (b c) ) in addition to pointer A (value (a b c) ). But that makes GC inefficient. For a vector to be GC'd you have to know what internal pointers it has,…

Ah. What you are calling a "pointer to the inside of a vector" is actually called a displaced vector. It's a standard Common Lisp feature, and no problem for modern GCs.

Interesting! Thanks.

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

#63

Post by akkartik »

arethuza wrote: post #59
akkartik wrote: post #55

Earlier quoted context omitted.

No, in Common Lisp you can't mix a keyword arg for a non-keyword param, or vice versa.

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_a... [NB It's been a long time since I did much Lisp]

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)

I wasn't aware of no-applicable-method; thanks for that pointer.

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

#64

Post by sedachv »

akkartik wrote: post #55
anghyflawn wrote: post #51

Earlier quoted context omitted.

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.

No, in Common Lisp you can't mix a keyword arg for a non-keyword param, or vice versa.

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?

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

#65

Post by akkartik »

sedachv wrote: post #64
akkartik wrote: post #55

Earlier quoted context omitted.

No, in Common Lisp you can't mix a keyword arg for a non-keyword param, or vice versa.

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?

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 "", 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)

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

#66

Post by xyzzyz »

apotheon wrote: post #34
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.

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

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

#67

Post by ori_b »

wanorris wrote: post #60
lisper wrote: post #52

Earlier quoted context omitted.

You are conflating the abstract data type with its implementation. A hash-map is one implementation of an associative array. A tree is another implementation of an associative array. A tree happens to depend on an ordering of the keys in order to do efficient lookup and a hash-map doesn't, but this is an implementation detail. It's not part of the definition of an associative array. And this is a good thing because n…

I think the mistake the parent post has made is conflating the kind of ordering you're referring to -- ordering in a tree implementation to allow for O(log n) resolution -- and ordering to preserve the position of each key-value pair as it was in the source structure. These are only the same thing if the source structure already happens to be sorted by some kind of ordering, something that obviously cannot be extende…

Or by having the map nodes have a "next" pointer.

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

#68

Post by munificent »

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…

> 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.)

Having done this before (https://github.com/munificent/lark), all it meant for me was that numbers and basic integer arithmetic became primitive. The clever bit about McCarthy's original metacircular interpreter is that it didn't need any types at all beyond atoms and cons cells: no bools, no ints, no nothing.

I found it interesting, but I don't know if I reached any deep insight. Maybe that's just me, or maybe I missed something.

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

#69

Post by wanorris »

ori_b wrote: post #67
wanorris wrote: post #60

Earlier quoted context omitted.

I think the mistake the parent post has made is conflating the kind of ordering you're referring to -- ordering in a tree implementation to allow for O(log n) resolution -- and ordering to preserve the position of each key-value pair as it was in the source structure. These are only the same thing if the source structure already happens to be sorted by some kind of ordering, something that obviously cannot be extende…

Or by having the map nodes have a "next" pointer.

Duh, I should have thought of that. Thank you.

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

#70

Post by ori_b »

lisper wrote: post #58
akkartik wrote: post #54

Earlier quoted context omitted.

(a (b (c . nil)) ^ ^ | | | | A B If you implement lists as vectors with car/cdr (I'm still thinking about your other questions) and choose to have cdr not copy results out of the original cell, you can end up in the (rope-like) situation above with pointer B (value (b c) ) in addition to pointer A (value (a b c) ). But that makes GC inefficient. For a vector to be GC'd you have to know what internal pointers it has,…

Ah. What you are calling a "pointer to the inside of a vector" is actually called a displaced vector. It's a standard Common Lisp feature, and no problem for modern GCs.

It does mean that you are potentially keeping around masses of data when you only care about one or two elements. Normally not an issue, but normally internal pointers ("displaced arrays") aren't a central organizational concept in a language.
Post reply on HN