Live data from Hacker News

A JavaScript parser and interpreter written in Go

github.com

41–50 of 72 posts

Re: A JavaScript parser and interpreter written in Go

#41
post #18

Alright, 90 points, most comments being meta about the title so I'll be the brave one and ask: What is this actually good for? I can't think of any reasonable use case. Grab little NPM ditties and incorporate them into your Go binary - Javascript to Go becomes as Lua is to C? Somebody enlighten me. Edit: Not that this needs a use case per say, just that the intent behind it is underspecified enough for me to wonder a…

You can scale npm now.

Re: A JavaScript parser and interpreter written in Go

#43
post #18

Alright, 90 points, most comments being meta about the title so I'll be the brave one and ask: What is this actually good for? I can't think of any reasonable use case. Grab little NPM ditties and incorporate them into your Go binary - Javascript to Go becomes as Lua is to C? Somebody enlighten me. Edit: Not that this needs a use case per say, just that the intent behind it is underspecified enough for me to wonder a…

We use it because we have user programmable callbacks, and JavaScript provides a well-known sandboxed language. Otto makes it really easy to expose native functionality to JS.

Re: A JavaScript parser and interpreter written in Go

#45
I have no idea how to really ask this, but does it uses continuation-passing style [0] to execute expressions? I tried to search for "cps" or "continuation" in the repo, but no luck. I also don't really have the time right now to go dig through the source.

[0]: http://en.wikipedia.org/wiki/Continuation-passing_style

Re: A JavaScript parser and interpreter written in Go

#46
post #37
post #11

A couple years ago for a programming languages course, we wrote a bytecode compiler and interpreter for a JavaScript-like language we were using in the class (objects, prototype-based inheritance, higher-order functions, etc), and we initially started building it in Go, but the biggest thing that made us switch to C++ at that time was the fact that Go didn't have a straightforward union type. It looks like this inter…

Excuse the silly question, but why was a union type so important?

I was wondering myself why you needed a union type.

Is it because JS has dynamic types ? var x = 5; x = "John Doe";

Re: A JavaScript parser and interpreter written in Go

#47
post #46
post #37

Earlier quoted context omitted.

Excuse the silly question, but why was a union type so important?

I was wondering myself why you needed a union type. Is it because JS has dynamic types ? var x = 5; x = "John Doe";

The alternative is a data structure which has N-1 empty, yet allocated, slots (N is the number of possible types.) instead you can have one field indicating the type of the variable and then your code can switch which field it accedes based off that indication. Total size is one int plus size of largest type represented.

Re: A JavaScript parser and interpreter written in Go

#48
post #37
post #11

A couple years ago for a programming languages course, we wrote a bytecode compiler and interpreter for a JavaScript-like language we were using in the class (objects, prototype-based inheritance, higher-order functions, etc), and we initially started building it in Go, but the biggest thing that made us switch to C++ at that time was the fact that Go didn't have a straightforward union type. It looks like this inter…

Excuse the silly question, but why was a union type so important?

Interpreters typically use polymorphic locations to hold values for the interpreted language. Technically almost any type of polymorphism is enough, but the fewer indirections you can get away with, the faster you can make a simple interpreter. So that would usually mean a sum type in a functional programming language with algebraic data types, or a simple object in an OO language, or a tagged union in C and Pascal.

But for better performance, approaches like tagged pointers (often used in Lisp implementations) are useful, as it eliminates a level of indirection for most integer operations. If you can afford to use 64 bits for your values, you might consider using doubles everywhere, with invalid exponents for stuffing a shortened pointer inside the float (I believe luajit uses, or used to use, this technique; it would probably be a good match for JS as well, as JS doesn't have integers).

Re: A JavaScript parser and interpreter written in Go

#49

I have no idea how to really ask this, but does it uses continuation-passing style [0] to execute expressions? I tried to search for "cps" or "continuation" in the repo, but no luck. I also don't really have the time right now to go dig through the source. [0]: http://en.wikipedia.org/wiki/Continuation-passing_style

Most languages don't have reliable enough tail call elimination to implement CPS without trampoline techniques to get rid of the excess stack frames, which in turn has a fairly hefty performance impact unless you're using it for something high-level like async callbacks.

Re: A JavaScript parser and interpreter written in Go

#50

I have no idea how to really ask this, but does it uses continuation-passing style [0] to execute expressions? I tried to search for "cps" or "continuation" in the repo, but no luck. I also don't really have the time right now to go dig through the source. [0]: http://en.wikipedia.org/wiki/Continuation-passing_style

[deleted]
Post reply on HN