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

Arc Ported to JavaScript

halogen.note.amherst.edu

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Arc Ported to JavaScript

#11

Post by apgwoz »

While I didn't think it would be JavaScript, I think my prediction of "how long before there's another implementation out there" of a "few days" was only a little bit off.

Re: Arc Ported to JavaScript

#14

Post by nostrademons »

tlrobinson wrote: post #7
staticshock wrote: post #5

an important limitation of javascript means this will never quite be a complete implementation: Continuations are not implemented. I had started on a CPS-based interpreter, but then realized that JavaScript lacks tail-call optimization and has a recursion limit of 1000 calls, which'll make any CPS-transformation blow the stack. looks like a good piece of code otherwise, though.

This guy implemented a continuation-based syntax highlighter in JavaScript: http://marijn.haverbeke.nl/codemirror/story.html I'm not sure how relevant it is to implementing Arc, but never say never. JavaScript is Turing complete, after all...

That approach could work. He's storing the current continuation as a global variable, which I never thought of, because typically you want your interpreters to be self-contained. (I was also working off Guy Steele's toy CPS interpreter, which passes cont in and then ends each function with a tailcall to another function or the invocation of the continuation.) But I can't see any real reason why the global won't work; it'll get stored in a data structure when the continuation is captured, and since stack frames are normal JavaScript objects in ArcLite, the garbage collector will hold on to them.

It'll mean that any loop that may call back into the interpreter has to be rewritten as a tail-recursive function though, with the tail call being saved into the global continuation variable. Could be quite a bit of overhead.

Re: Arc Ported to JavaScript

#16

Post by nostrademons »

byrneseyeview wrote: post #13
albertcardona wrote: post #12

Super cool, thanks a lot! Now if only we could push return to enter instead of having to use the mouse ...

Tab-return?

Yeah, that's what I do. I couldn't figure out how to get accesskeys to take "return" as the key. If anyone knows a better solution, I can change it.

Re: Arc Ported to JavaScript

#17

Post by nostrademons »

cstejerean wrote: post #4

Although unrelated to my challenge ( http://blog.offbytwo.com/2008/02/05/a-different-kind-of-arc-... ) this seems to be the first implementation of Arc in a language other than Scheme. I'm curious if others will follow.

I thought about that while I was writing it (I started before your challenge came out). Here's the results for ArcLite:

  > wc [^j]*.js
   66   147  1359 buffer.js
  369  1114 10672 eval.js
  149   488  4522 primitives.js
  188   509  4989 reader.js
  356  1145 11869 types.js
  136   370  3260 utils.js
 1264  3773 36671 total

 > wc [^d]*.scm
 1093  4404 36047 ac.scm
   16    30   242 as.scm
   48   152  1252 brackets.scm
 1157  4586 37541 total
So ArcLite is about 100 lines of code more. OTOH, if you take out the reader (which is supplied by Scheme but I had to write myself for ArcLite) it's -254 lines for ArcLite and -48 lines for Arc0. Which means the JavaScript version is actually smaller, at least in line count. (There's also the matter of the missing I/O primitives, but most of them just delegate to Scheme in Arc0 as well.)

I have no idea how it compares in code-tree count. Probably larger, as my JavaScript coding style is fairly dense. One could argue that that's the point of syntax though; it makes common operations take up very little space on the page.

Re: Arc Ported to JavaScript

#19

Post by nostrademons »

anaphoric wrote: post #9

Cool, you deserve many up votes for this! I just played around with it quickly, pasted in the recursive definition of factorial: (def fact (x) (if ( It was fairly quick, but the results came back as floating point numbers. It broke on (fact 100). Under arc-over-scheme it did better. CLISP performed better than both, but the default limit in the call depth was easily exceeded (E.g. it busted on (fact 8000)). I don't r…

I tried factorial as one of my test cases. Up through factorial 10 it was still coming back as integers. You may have triggered some overflow condition. The interpreter uses the native JavaScript + operation, then checks whether result == Math.round(result) to see whether it should wrap it in an int or a num.

I'm truly amazed you got it to work up to (fact 100), and that it came back in a reasonable amount of time. Firefox has a recursion limit depth of 1000, which means that the interpreter overhead is only about a factor of 10. I was expecting much more...

Re: Arc Ported to JavaScript

#20

Post by anaphoric »

nostrademons wrote: post #19
anaphoric wrote: post #9

Cool, you deserve many up votes for this! I just played around with it quickly, pasted in the recursive definition of factorial: (def fact (x) (if ( It was fairly quick, but the results came back as floating point numbers. It broke on (fact 100). Under arc-over-scheme it did better. CLISP performed better than both, but the default limit in the call depth was easily exceeded (E.g. it busted on (fact 8000)). I don't r…

I tried factorial as one of my test cases. Up through factorial 10 it was still coming back as integers. You may have triggered some overflow condition. The interpreter uses the native JavaScript + operation, then checks whether result == Math.round(result) to see whether it should wrap it in an int or a num. I'm truly amazed you got it to work up to (fact 100), and that it came back in a reasonable amount of time. F…

I think it worked for 50, but then it busted on 100. I only tried a couple of calls.
Post reply on HN