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

A JavaScript parser and interpreter written in Go

github.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: A JavaScript parser and interpreter written in Go

#61

Post by astrodust »

toong wrote: post #46
robzyb wrote: 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";

It allows you to create a single, compact structure that can then be utilized in a number of ways without having to re-cast it, replace it, or otherwise reallocate it.

For example, you can have a union between a 64-bit pointer and a 32-bit type identifier plus 32-bit value. This means you can store 32-bit integers in the same space as a pointer.

Re: A JavaScript parser and interpreter written in Go

#62

Post by 1631- »

codebeaker wrote: post #31
gyepi wrote: post #21

Earlier quoted context omitted.

It is a useful convention in C and C++ to group includes, but I don't see the benefit in Go. Since gofmt sorts imports, the grouping is soon undone. In any case, it is quite easy to distinguish the three kinds of imports if local imports share a common prefix or set of prefixes. Am I missing something here?

It's possible that if you have packages that understand flags (config package, with flags in init(), for example) that if you include it after the testing package, or before. One of them won't accept flags. (because flag.Parse() has already been called)

You can't rely on the order of imports initialization anyway. See http://golang.org/ref/spec#Program_execution .. I believe that's also the reason, you shouldn't call `flag.Parse()` in `init()`

Re: A JavaScript parser and interpreter written in Go

#63

Post by [deleted] »

jerf wrote: post #60
ek wrote: 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…

Sum Types in Go - http://www.jerf.org/iri/post/2917 It's less convenient than writing a compiler in Haskell, but then, what isn't? It does give you reasonable type safety, though. (Again, don't say that where a Haskell programmer is listening, but it's at least decent.)

[deleted]

Re: A JavaScript parser and interpreter written in Go

#65

Post by gouggoug »

mturmon wrote: post #34
gouggoug wrote: post #20

Earlier quoted context omitted.

Not everything needs a use case. But if you really want one, here's one: I'm a student and I want to write my own interpreter. Well, here's a good example of how to write your interpreter.

That's not a use case.

You nonetheless understood what I meant, and knew by reading my comment that "use case" was a mis-use of language. That's nit-picking.

Re: A JavaScript parser and interpreter written in Go

#66

Post by cdcarter »

astrodust wrote: post #61
toong wrote: post #46

Earlier quoted context omitted.

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

It allows you to create a single, compact structure that can then be utilized in a number of ways without having to re-cast it, replace it, or otherwise reallocate it. For example, you can have a union between a 64-bit pointer and a 32-bit type identifier plus 32-bit value. This means you can store 32-bit integers in the same space as a pointer.

The question is what about a JS interpreter makes this necessary.

Re: A JavaScript parser and interpreter written in Go

#67

Post by ek »

toong wrote: post #46
robzyb wrote: 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";

Yes. JavaScript has dynamic types, and representing these in a statically typed language requires some finagling.

Re: A JavaScript parser and interpreter written in Go

#68

Post by ek »

cdcarter wrote: post #66
astrodust wrote: post #61

Earlier quoted context omitted.

It allows you to create a single, compact structure that can then be utilized in a number of ways without having to re-cast it, replace it, or otherwise reallocate it. For example, you can have a union between a 64-bit pointer and a 32-bit type identifier plus 32-bit value. This means you can store 32-bit integers in the same space as a pointer.

The question is what about a JS interpreter makes this necessary.

As I answered above to another commenter with a similar question, JavaScript is a dynamically typed language and representing dynamic values in a statically typed language requires a bit of thinking, and unions are a common way of doing this.

Re: A JavaScript parser and interpreter written in Go

#69

Post by zik »

jerf wrote: post #60
ek wrote: 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…

Sum Types in Go - http://www.jerf.org/iri/post/2917 It's less convenient than writing a compiler in Haskell, but then, what isn't? It does give you reasonable type safety, though. (Again, don't say that where a Haskell programmer is listening, but it's at least decent.)

Thanks. That was really interesting.

Re: A JavaScript parser and interpreter written in Go

#70

Post by adrianmalacoda »

wldlyinaccurate wrote: post #33
jkchang wrote: post #13

Earlier quoted context omitted.

I think the title has been changed. Can you say what the original was?

I could be wrong, but I think they're just poking fun at all the "An X interpreter written in Y" where X and Y are the current trendy languages. Usually one of X or Y are JavaScript or Go, so seeing both in the same headline is like some sort of Hacker News headline jackpot.

I'm subscribed to HN's RSS feed using a feed reader app on my phone, and when I saw this item the title was truncated at around "written." Somehow I just knew it would be Go.

I entertained the idea that maybe it would have been written in JavaScript, but I think a JS interpreter written in JS has already been done at least once.

Post reply on HN