However my one tiny complaint is that the sign-up box is on every page, and even after I've signed up, it still has to be closed every page I go to.
Show HN: Crafting Interpreters – A handbook for making programming languages
41–50 of 77 posts
Re: Show HN: Crafting Interpreters – A handbook for making programming languages
#42Looking 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
//> 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
#43Re: Show HN: Crafting Interpreters – A handbook for making programming languages
#44Seems 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
Re: Show HN: Crafting Interpreters – A handbook for making programming languages
#45On 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
#46Seems 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 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
#47Re: Show HN: Crafting Interpreters – A handbook for making programming languages
#48I 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
#49Another 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…
- 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
#50Another 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