TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: Ideas for a Programming Language Book

6 pointsby wycliffbabout 6 years ago
Hey! So I intend to write an end-to-end book on the design and implementation of a programming language, right from design choices, type system, native implementation to formal semantics (K Framework). Any pointers/requests?

2 comments

s-p-nabout 6 years ago
While working on a language design over the last 6 years, I&#x27;ve created my own rules to achieve my own goals. I made a seemingly backwards switch from using an Abstract Syntax Tree, to a method of just simply lexing and replacing.<p>I find that it&#x27;s very hard to write &quot;good code&quot; when writing a language. I also found that the Abstract Syntax Tree didn&#x27;t help me write good code. It appeared to, but the biggest stride I made was when I took out that middle man and abstracted the grammar and lexer instead.<p>I would never have taken out the AST if it weren&#x27;t for one problem: lexer state changes at compile time. Now, it&#x27;s possible to do that with an AST.. But in my case, I couldn&#x27;t go back to the lexer and change states after the AST was generated. I was specifically working on regular expressions, string interpolation, and XML Tags, and managing precedence for all these things (you gotta remember, greater than and less than tokens hate XML...). My biggest problem was that in each of those &quot;sub-syntax&quot; features, each sub-syntax needed the entire feature set and complexity of the rest of the language. I solved all that. String interpolation was the straw that broke my delicate parser&#x27;s back. Before I knew it, despite my attempted use of &quot;good practice&quot;, the token ambiguity problem became far too big to solve without modifying the lexer. And modifying the lexer was simply too hard, as many sub-systems managed each other, and I noticed I somehow created a very deep dependency hell despite my efforts.<p>Today, my grammar isn&#x27;t perfect. I did, however, gain the ability to entangle the lexer with an API that tries to achieve loose coupling between rules, but the coupling problem is inherit to language design- the issue is ingrained in the algorithm.<p>See, writing grammars are very susceptible to tight coupling. I guess that&#x27;s my whole point.<p>We should talk sometime.
评论 #19434047 未加载
federicobondabout 6 years ago
Not sure which audience you are targetting but I would love to read more on modern compiler design. There is very little information on the web on how to design a compiler to provide good error messages and code intelligence features even in the face of incomplete or incorrect source code.<p>A good starting point would be some of the themes touched towards the end of this article: <a href="https:&#x2F;&#x2F;blog.adamant-lang.org&#x2F;2019&#x2F;dreaming-of-a-parser-generator&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.adamant-lang.org&#x2F;2019&#x2F;dreaming-of-a-parser-gene...</a>