6 ms·

The Monkey Programming Language

160 points by azhenley 7y ago

robbrit 7y ago
Bit of bait-and-switch here: thought I was learning about a new programming language when it's more a pitch for books about making programming languages. Creative advertising on the part of the author though!
- ptrott2017 7y ago
  A little bit = but personally happy to see a website for the language - there are a lot of implementations out there now ,so its good to have a source point. If you have not read the books they are a really good practical introductions to building interpreters and compilers.
sideb0ard 7y ago
currently working my way through this book, and implementing it in C++ - very good book! I'm really enjoying it.
mntmoss 7y ago
I was looking for this and didn't realize it. I'm designing a fantasy console and wanted to include a modern-syntax, small, interpreted language that has many independent implementations - a new BASIC or Pascal. Lua comes close to this but attention is really centered around the PUC-Rio and LuaJIT implementations and not on being easily reimplemented, and every "classic" option one might think of(including Lisps and Forths) falls a bit outside today's mainstream. I may be getting the book soon...
- snazz 7y ago
  I would argue for a Lisp. If you’re asking the user to use a language they’re not familiar with, it might as well be one that will expand their horizons, despite the potentially offputting syntax. It would be really cool if you added a key that switched from s-expressions to Sweet expressions[0] (and vice-versa). Forth is painful to use for anything more than a toy and no matter what language you choose it would be awesome to see a live-updating (graphical?) REPL. [0] https://readable.sourceforge.io https://readable.sourceforge.io
  - mntmoss 7y ago
    Expanding PL horizons is not a goal for this project. The goal for this specific usercode layer(of which there are four: WASM bytecode, the I/O memory map, the lower level operating system language, and the higher level interpreted language) is to achieve a mix of sustainability and familiarity. A language defined by a book explaining its implementation, while also being in the "looks-like-an-Algol" ballpark, falls very close to that mark. If you want a Lisp, it's possible, just rewrite the OS layer.
- chrisseaton 7y ago
  Also consider looking at SOM - nine implementations http://som-st.github.io http://som-st.github.io.
- jharger 7y ago
  Have you seen Wren? https://github.com/wren-lang/wren https://github.com/wren-lang/wren
  - mntmoss 7y ago
    Wren is small, and the language is aesthetically appealing, but it's small in the specific way of its C implementation being a small SLOC while implementing nifty features, not "anyone could study this codebase and port it to a new environment". It relies extensively on the preprocessor. (I speak from experience.)
- kitd 7y ago
  Racket has an embedded shell language, Rash https://docs.racket-lang.org/rash/index.html https://docs.racket-lang.org/rash/index.html
adamson 7y ago
Thorsten Ball very recently gave an interview on Software Engineering Radio [1] where he discusses the books and the language and his thinking on each. [1] https://www.se-radio.net/2019/05/365-thorsten-ball-on-building-an-interpreter/ https://www.se-radio.net/2019/05/365-thorsten-ball-on-buildi...
yokohummer7 7y ago
This is another language whose syntax is similar to Rust's. I wonder why the author chose it, in spite of its Go heritage.
- zero_iq 7y ago
  Also yet another language called 'Monkey'. There's already Monkey C used to develop for Garmin devices, and the Monkey/MonkeyX/Monkey2 family by Mark Sibly (of Amiga Blitz Basic fame).
  - asddgsgsaxg 7y ago
    Username checks out
  - adamredwoods 7y ago
    I originally thought this post was related to Mark Sibly's trans-compiler, which I used in the past and enjoyed quite a bit: http://monkeycoder.co.nz/ http://monkeycoder.co.nz/
- simen 7y ago
  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.
  - misternugget 7y ago
    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.
thanks-but-no 7y ago
So, basically JavaScript. Again.
jedisct1 7y ago
I initially thought it was about the Monkey C language: https://developer.garmin.com/connect-iq/monkey-c/ https://developer.garmin.com/connect-iq/monkey-c/
- qrohlf 7y ago
  As a Monkey C developer, I'd say Monkey C is a better example of how not to design a programming language.
  - asark 7y ago
    Making it OO on a system with so little memory available to apps was an especially weird basic decision, I thought. There were cases where memory use was unavoidably bloated for no good reason, and meanwhile there wasn't enough space to actually do any architecture-astronaut OO stuff. I wished the whole time they'd just given me a somewhat locked-down C, and I'm only a C-dabbler so that's not a preference I'd have due to great familiarity or anything. It was overall somewhat more unpleasant, but less weird, than writing code for Roku. Most of the Roku weirdness was just because they had some new very-much-halfassed XML programming system you had to use for new apps at the time, which forced you to define public interfaces for objects in XML for no good reason while doing the actual work in Brightscript, which isn't gonna win any language design awards ever but is at least usable. Plus it's obscure so figuring all that out was tons of fun.
fernly 7y ago
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 http://www.craftinginterpreters.com
- pseudoramble 7y ago
  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!
- rumbletumjum 7y ago
  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.
_bxg1 7y ago
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.
- hybrids 7y 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.
  - lifthrasiir 7y ago
    > 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.
  - _bxg1 7y ago
    Yes yes, Lisp invented everything, I know. I was talking about the fact that (to the best of my knowledge) Rust introduced them to the C-like syntax world.
Crinus 7y ago
I thought this was Mark Sibly's Monkey language. [1] http://monkeycoder.co.nz/ http://monkeycoder.co.nz/
ngcc_hk 7y ago
Clojure version, any?
wildduck 7y ago
Seems very similar to ES6
chrismsimpson 7y ago
Much more thought needs to be given to the AST and the public API(s). See here: https://github.com/chrismsimpson/Meta https://github.com/chrismsimpson/Meta. If it's going to be 'the final system' there really has to be legion compelling reason to switch. I just don't see it. Also, and I honestly mean no offence, but do we really want to call it Monkey? It's a tad childish. We're going to be asking Governments, Banks, public services etc. to being using this thing.
- Quarrelsome 7y ago
  You're telling me you wouldn't use NSSM? Its awesome.
  - chrismsimpson 7y ago
    No. For the non tech literate, this will become a fundamental issue of safety.
    - Quarrelsome 7y ago
      Non tech literate shouldn't be making these choices. This is why they'll miss out on Cockroach DB, eh?
      - chrismsimpson 7y ago
        Umm.. says who? You?

160 points by azhenley 7y ago

Bit of bait-and-switch here: thought I was learning about a new programming language when it's more a pitch for books about making programming languages. Creative advertising on the part of the author though!

ptrott2017 7y ago
A little bit = but personally happy to see a website for the language - there are a lot of implementations out there now ,so its good to have a source point. If you have not read the books they are a really good practical introductions to building interpreters and compilers.

sideb0ard 7y ago

currently working my way through this book, and implementing it in C++ - very good book! I'm really enjoying it.

mntmoss 7y ago

I was looking for this and didn't realize it. I'm designing a fantasy console and wanted to include a modern-syntax, small, interpreted language that has many independent implementations - a new BASIC or Pascal. Lua comes close to this but attention is really centered around the PUC-Rio and LuaJIT implementations and not on being easily reimplemented, and every "classic" option one might think of(including Lisps and Forths) falls a bit outside today's mainstream. I may be getting the book soon...

snazz 7y ago
I would argue for a Lisp. If you’re asking the user to use a language they’re not familiar with, it might as well be one that will expand their horizons, despite the potentially offputting syntax. It would be really cool if you added a key that switched from s-expressions to Sweet expressions[0] (and vice-versa). Forth is painful to use for anything more than a toy and no matter what language you choose it would be awesome to see a live-updating (graphical?) REPL. [0] https://readable.sourceforge.io https://readable.sourceforge.io
- mntmoss 7y ago
  Expanding PL horizons is not a goal for this project. The goal for this specific usercode layer(of which there are four: WASM bytecode, the I/O memory map, the lower level operating system language, and the higher level interpreted language) is to achieve a mix of sustainability and familiarity. A language defined by a book explaining its implementation, while also being in the "looks-like-an-Algol" ballpark, falls very close to that mark. If you want a Lisp, it's possible, just rewrite the OS layer.
chrisseaton 7y ago
Also consider looking at SOM - nine implementations http://som-st.github.io http://som-st.github.io.
jharger 7y ago
Have you seen Wren? https://github.com/wren-lang/wren https://github.com/wren-lang/wren
- mntmoss 7y ago
  Wren is small, and the language is aesthetically appealing, but it's small in the specific way of its C implementation being a small SLOC while implementing nifty features, not "anyone could study this codebase and port it to a new environment". It relies extensively on the preprocessor. (I speak from experience.)
kitd 7y ago
Racket has an embedded shell language, Rash https://docs.racket-lang.org/rash/index.html https://docs.racket-lang.org/rash/index.html

adamson 7y ago

Thorsten Ball very recently gave an interview on Software Engineering Radio [1] where he discusses the books and the language and his thinking on each. [1] https://www.se-radio.net/2019/05/365-thorsten-ball-on-building-an-interpreter/ https://www.se-radio.net/2019/05/365-thorsten-ball-on-buildi...

yokohummer7 7y ago

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

zero_iq 7y ago
Also yet another language called 'Monkey'. There's already Monkey C used to develop for Garmin devices, and the Monkey/MonkeyX/Monkey2 family by Mark Sibly (of Amiga Blitz Basic fame).
- asddgsgsaxg 7y ago
  Username checks out
- adamredwoods 7y ago
  I originally thought this post was related to Mark Sibly's trans-compiler, which I used in the past and enjoyed quite a bit: http://monkeycoder.co.nz/ http://monkeycoder.co.nz/
simen 7y ago
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.
- misternugget 7y ago
  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.

thanks-but-no 7y ago

So, basically JavaScript. Again.

jedisct1 7y ago

I initially thought it was about the Monkey C language: https://developer.garmin.com/connect-iq/monkey-c/ https://developer.garmin.com/connect-iq/monkey-c/

qrohlf 7y ago
As a Monkey C developer, I'd say Monkey C is a better example of how not to design a programming language.
- asark 7y ago
  Making it OO on a system with so little memory available to apps was an especially weird basic decision, I thought. There were cases where memory use was unavoidably bloated for no good reason, and meanwhile there wasn't enough space to actually do any architecture-astronaut OO stuff. I wished the whole time they'd just given me a somewhat locked-down C, and I'm only a C-dabbler so that's not a preference I'd have due to great familiarity or anything. It was overall somewhat more unpleasant, but less weird, than writing code for Roku. Most of the Roku weirdness was just because they had some new very-much-halfassed XML programming system you had to use for new apps at the time, which forced you to define public interfaces for objects in XML for no good reason while doing the actual work in Brightscript, which isn't gonna win any language design awards ever but is at least usable. Plus it's obscure so figuring all that out was tons of fun.

fernly 7y ago

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 http://www.craftinginterpreters.com

pseudoramble 7y ago
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!
rumbletumjum 7y ago
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.

_bxg1 7y ago

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.

hybrids 7y 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.
- lifthrasiir 7y ago
  > 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.
- _bxg1 7y ago
  Yes yes, Lisp invented everything, I know. I was talking about the fact that (to the best of my knowledge) Rust introduced them to the C-like syntax world.

Crinus 7y ago

I thought this was Mark Sibly's Monkey language. [1] http://monkeycoder.co.nz/ http://monkeycoder.co.nz/

ngcc_hk 7y ago

Clojure version, any?

wildduck 7y ago

Seems very similar to ES6

chrismsimpson 7y ago

Much more thought needs to be given to the AST and the public API(s). See here: https://github.com/chrismsimpson/Meta https://github.com/chrismsimpson/Meta. If it's going to be 'the final system' there really has to be legion compelling reason to switch. I just don't see it. Also, and I honestly mean no offence, but do we really want to call it Monkey? It's a tad childish. We're going to be asking Governments, Banks, public services etc. to being using this thing.

Quarrelsome 7y ago
You're telling me you wouldn't use NSSM? Its awesome.
- chrismsimpson 7y ago
  No. For the non tech literate, this will become a fundamental issue of safety.
  - Quarrelsome 7y ago
    Non tech literate shouldn't be making these choices. This is why they'll miss out on Cockroach DB, eh?
    - chrismsimpson 7y ago
      Umm.. says who? You?