Live data from Hacker News

The Monkey Programming Language

monkeylang.org

21–30 of 37 posts

Re: The Monkey Programming Language

#21
post #18

This is remarkably similar to the Lox language and the book Crafting Interpreters[1] by Bob Nystrom, which I only just read about on HN like two days ago. (Edit: one major difference is, Nystrom's book is free.) [1] http://www.craftinginterpreters.com

I had the same thought while reading through this site! I've started working through Crafting Interpreters a few weeks ago. I have been loving it. I'll generally read a chapter one evening, and then write the code from it the next day and re-read bits of the chapter to clarify the code. It's been really enjoyable.

One thing I want to do next is to try and implement the tree-walking interpreter again in another language (probably F# in my case) and maybe share it if I finished it up. This site is basically a concrete version of that small thought in my head.

Funny how things work out!

Re: The Monkey Programming Language

#22

This is another language whose syntax is similar to Rust's. I wonder why the author chose it, in spite of its Go heritage.

I'd say it's more similar to Javascript. In fact all of the examples are valid JS if you replace `fn` with `function`. (Although JS doesn't have implicit returns.)

At a guess, the author chose the syntax because it's familiar and easy to parse. Go's syntax is... eccentric where it differs from typical C-style languages.

Re: The Monkey Programming Language

#23
It seems every new C-like has Rust's expressive if/else and implicit returns. And why not? They're strict improvements on the syntax. Makes me wonder why they didn't become prevalent many years ago.

Re: The Monkey Programming Language

#24
post #23

It seems every new C-like has Rust's expressive if/else and implicit returns. And why not? They're strict improvements on the syntax. Makes me wonder why they didn't become prevalent many years ago.

Both of these things were invented by Lisp. The reason C didn't include them was because C and its ancestors was designed to be easy to write a parser for (well, "relatively" anyway, it's not exactly as barebones as sexps) and to be usable with a preprocessor macro system, so you end up with a language designed with a lot of syntactic cruft (braces, semicolons, ternaries, etc.) meant as aids to compiler authors.

Re: The Monkey Programming Language

#25
post #18

This is remarkably similar to the Lox language and the book Crafting Interpreters[1] by Bob Nystrom, which I only just read about on HN like two days ago. (Edit: one major difference is, Nystrom's book is free.) [1] http://www.craftinginterpreters.com

One is Java/recusrive descent, the other is Go/Pratt -- in the Go interpreter book, Thorsten explicity mentions Bob's Pratt parser tutorial as the go-to resource for explaining how Pratt parsers work. Both books are very good as practical guides to language implementation -- if Bob ever charged for Crafting Interpreters I'd gladly pay.

Re: The Monkey Programming Language

#26
post #24
post #23

It seems every new C-like has Rust's expressive if/else and implicit returns. And why not? They're strict improvements on the syntax. Makes me wonder why they didn't become prevalent many years ago.

Both of these things were invented by Lisp. The reason C didn't include them was because C and its ancestors was designed to be easy to write a parser for (well, "relatively" anyway, it's not exactly as barebones as sexps) and to be usable with a preprocessor macro system, so you end up with a language designed with a lot of syntactic cruft (braces, semicolons, ternaries, etc.) meant as aids to compiler authors.

> you end up with a language designed with a lot of syntactic cruft (braces, semicolons, ternaries, etc.) meant as aids to compiler authors.

Many of those are not just for the easiness of implementation but also for the quality of partial parsing, frequently required for today's compilers. I do agree that they are not intentionally designed in that way.

Re: The Monkey Programming Language

#27
post #22

This is another language whose syntax is similar to Rust's. I wonder why the author chose it, in spite of its Go heritage.

I'd say it's more similar to Javascript. In fact all of the examples are valid JS if you replace `fn` with `function`. (Although JS doesn't have implicit returns.) At a guess, the author chose the syntax because it's familiar and easy to parse. Go's syntax is... eccentric where it differs from typical C-style languages.

Author here. Yes, that's exactly right. I wanted to show how to write a parser/interpreter for something that you encounter every day. JavaScript-like syntax, with curly braces and `if`/`else` is just that.
Post reply on HN