Live data from Hacker News

Show HN: Crafting Interpreters – A handbook for making programming languages

craftinginterpreters.com

41–50 of 77 posts

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#42

Looking forward to the chapters about the C interpreter. Meanwhile, it looks like both interpreters are available to study now in the Git repo. [1] [1]: https://github.com/munificent/craftinginterpreters

Nice project. What do all the

//> SomeName not-yet

in the code mean? Are they meant for some kind of automatic processing? Its a bit hard to read with all of them there...

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#44

Seems to be a hot topic, a friend and colleague published this in December 2016 and I can thoroughly recommend it (Uses Go as an implementation language): - https://interpreterbook.com

I bought this when it appeared on HN around xmas, can recommend, its a pretty great introduction to the subject

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#45
This is awesome, since I'm currently working on my own (toy) language! Thanks for making this public!

On a side note, to anyone interested in an overview of high-level language features and what their implementation requires, I can wholeheartedly recommend Michael Scott's Programming Language Pragmatics. It doesn't go into implementation details, but tells you a lot about the historical choices and implementation possibilities of (mostly) mainstream languages.

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#46

Seems to be a hot topic, a friend and colleague published this in December 2016 and I can thoroughly recommend it (Uses Go as an implementation language): - https://interpreterbook.com

I can recommend this book as well! It is easy to read and understand and the choice of Go as the host language is also great.

I am in the process writing a semi-natural query language (boolean logic) targeted at domain experts (in this case biomedical researchers) that compiles to either database queries (e.g. SQL) or a function call for arbitrary logic. The goal of the compiler bit is to abstract away where the data ultimately lives (similar to GraphQL) or how it is structured.

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#47
That's so cool! Learning to make a programming language is in my life's todo list, just as doing my own (super simple) operating system. Thank's for contributing with a free book, I very much appreciate it. Does anybody know of something similar but for operating systems?

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#48
I clicked the link without looking at the poster, and by the end of the "What’s the Catch?" paragraph I was thinking to myself that this really seems like something written by The Munificent Bob. Then I read the first sentence of the next paragraph :)

I really like your blog, I have read all of it, some posts even 2-3 times, and not only because of the content, but your writing style. I will probably read this book too ;)

Also, I think Magpie is awesome.

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#49
post #21
post #6

Another great-looking book on making dynamic languages. There's been some good ones recently, and this one looks like another good one covering how to make a basic, interpreted language. Some of us have written 1 or 2 dynamic, interpreted languages, feel pretty comfortable with those concepts, and are interested in transiting to more advanced, static type systems and writing a good type checker. Anyone up for writing…

There's nothing more "advanced" about statically typed languages. Static typing and type inference are straightforward and can make implementation details simpler than dynamic languages (because you're greatly reducing or removing the unknowns you have to deal with at runtime). This is assuming you're making a batch-style compiler, as most implementors do, and not an interactive system. If you're focused on benchmark…

While I agree that compilation of dynamically typed languages is more challenging, inference for advanced typing systems is full of problems:

- How to ensure that the inference algorithm is correct.

- How to design typing systems that are expressive, yet lightweight, and have enough type inference to be usable in practise.

- How to deal with concurrency and parallelism.

None of these problems is really solved. In practise even making type inference fast is a challenge, e.g. in older versions of the Scala compiler, type inference was really slow due to implicits.

Re: Show HN: Crafting Interpreters – A handbook for making programming languages

#50
post #6

Another great-looking book on making dynamic languages. There's been some good ones recently, and this one looks like another good one covering how to make a basic, interpreted language. Some of us have written 1 or 2 dynamic, interpreted languages, feel pretty comfortable with those concepts, and are interested in transiting to more advanced, static type systems and writing a good type checker. Anyone up for writing…

   Anyone up for writing such a high-quality 
   book as this one on statically-typed languages, 
Not a book, but maybe "The Essence of ML Type Inference" by Pottier and Remy [1] is of interest. It's a bit more in-depth than TAPL.

[1] gallium.inria.fr/~fpottier/publis/emlti-final.pdf

Post reply on HN