Estimating how long something like that might take is dependent on many different factors. For example, an experienced programmer can easily knock out a simple arithmetic expression evaluator in a couple of hours, with unit tests. But a novice programmer may have to learn about parsing techniques, recursive descent, abstract representation of expression trees, tree-walking strategies, and so on. This could easily take weeks or more, just for arithmetic expressions.
However, don't let that discourage you. As Jeff and Joel were discussing with Eric Sink on a recent Stack Overflow podcast, writing a compiler is an excellent way to learn about many different aspects of programming. I've built a few compilers and they are among my most memorable programming projects.
Dave Hanson, who with Chris Fraser spent 10 years building one of the world's most carefully crafted compilers, told me once that one of the main things he learned from the experience was not to try to write a compiler in C or C++.
If you want to develop something quickly, don't generate native code; target an existing virtual machine such as the CLR, JVM, or the Lua virtual machine. Generate code using maximal munch.
Another good option if you're writing an interpreter is just to use the memory management and other facilities of your underlying programming language. Parse to an AST and then interpret by tree walk of the AST. This will get you off the ground fast. Performance is not the greatest, but it's acceptable. (Using this technique I once wrote a PostScript interpreter in Modula-3. The first implementation took a week and although it later underwent some performance tuning, primarily in the lexer, it never had to be replaced.)
Avoid LALR parser generators; use something that saves your time, like ANTLR or the Elkhound GLR parser generator.
Alfred V. Aho和Jeffrey D. Ullman的《编译器设计原理》。 它已经存在相当长一段时间了，它的粉红骑士和绿龙至少为几代计算机科学学生所熟知。
另外...
“编译器：原理、技术和工具”，作者：Alfred V. Aho、Monica S. Lam、Ravi Sethi、Jeffrey D. Ullman
如果您有兴趣编写编译器，那么这些无疑是最好的起点。
The classic books on compiler design are
"Principles of Compiler Design" by Alfred V. Aho and Jeffrey D. Ullman. It's been around quite some time now and its pink knight and green dragon are well known to at least a couple of generations of CS students.
Also...
"Compilers: Principles, Techniques, and Tools" by Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman
If you're interested in writing a compiler then these are undoubtedly the best places to start.
As a person who knows C++ very well, what tips can you give a person who is looking to write a programming or script language?
Don't do it. (or at least think long and hard before you do!)
If you're trying to write a scripting language to expose the methods/properties of some custom-written objects, it would be better to implement those in Java (or .NET/VB or all those icky Microsoftisms) and then use one of the Bean Scripting Framework languages as your scripting language. (with whatever the equivalent is on the Microsoft end.)
Any questions about compilers will have an answer "go read dragon book, read that book, this book..." on SO regardless of their content in a few minutes. So I skip that part (like I was telling in the first place). Reading these books to learn how to use the tools you want, is about as useful as reading about angular momentum to learn how to ride a bike.
So, to answer what you asked, without questioning your intention, I can easily recommend antlr and antlrworks for starters. You can generate your AST easily (where the real magic happens, I think) and debug your grammar visually. It generates a good portion of a working compiler for you.
If you know your stuff and want to have more control or don't like antlr, you can use lemon parser generator and ragel state machine compiler (have special support for lexing) together.
If you don't need too much performance and since you plan to generate C/C++ code, you can skip doing any optimizations yourself and leave that stuff to your C/C++ compiler.
If you can live with a slow runtime, you can further shorten your development effort just doing interpretation, since it is often easier to implement dynamic features this way.
很多书都可以找到。 我喜欢的是一本 BYTE 书：Threaded Interpreted Languages - 我敢打赌它已经绝版了。
简单的脚本引擎可以通过几个晚上的思考和一些尝试和错误来制作。
但我敢打赌现在有在线课程可以节省你大量的时间。
I think everybody is missing one very important point.
WHY do you want to write a compiler / interpreter / parser etc.
This will seriously determine a lot of what you do.
I have worked on quite a few language implementations, some rather weird, some domain specific, some simply scripted progress through command environments (often where the command environment was later hidden). Each required different levels of skill.
Many books available. One I loved was a BYTE book : Threaded Interpreted Languages - bet it's out of print.
Simple script engines can be crafted with a few evening's thinking and a bit of trial and error.
But I bet there are online courses now that will save you a ton of time.
I'd strongly recommend looking at existing bytecode interpreters. If you can make your language fit into CIL (.NET) or Java (or even others such as Python or Parrot), you'll save yourself all the effort of making a workable supporting environment and can get on with experimenting with language concepts.
If you're planning on writing an interpreter or compiler, don't do it because you want to write the next big thing. Write it because you already have a purpose for it in mind or to learn. If you do this you may find that you've accidentally written the next big thing.
A good tool that I've used for LALR is the GOLD Parsing System. It's free, the grammer is Backus-Naur Form, and there are multiple examples, including engines written in C#, VB.NET, Java and others. This lets you write a grammer, compile the grammer to a file, and then use an engine to parse the grammer.
As recommended above, I would recommend targeting a byte code of some kind, like IL. This will allow you to leverage the enormous amounts of existing frameworks.
If you don't want to get into writing a compiler to reduce your language to assembly/machine, then your next option is to write a compiler to a byte-code language virtual machine, such as the JVM, PVM or .NET.
Of course, if you don't even want to do that - you just want to create your own "domain specific language", I would build it in Common Lisp. Lisp macros provide a rather straight-forward method of creating whatever syntax you want and parsing it into Lisp. And you don't have worry about byte-code or assembly. Of course, you need to learn Lisp.
发布评论
评论（10）
估计类似的事情可能需要多长时间取决于许多不同的因素。 例如，经验丰富的程序员可以通过单元测试在几个小时内轻松完成一个简单的算术表达式计算器。 但是新手程序员可能必须学习解析技术、递归下降、表达式树的抽象表示、树遍历策略等等。 仅对于算术表达式来说，这很容易需要数周或更长时间。
不过，不要因此而泄气。 正如 Jeff 和 Joel 在 最近的 Stack Overflow 播客 上与 Eric Sink 讨论的那样，编写编译器是一种学习编程许多不同方面的好方法。 我已经构建了一些编译器，它们是我最难忘的编程项目之一。
关于构建编译器的一些经典书籍有：
Estimating how long something like that might take is dependent on many different factors. For example, an experienced programmer can easily knock out a simple arithmetic expression evaluator in a couple of hours, with unit tests. But a novice programmer may have to learn about parsing techniques, recursive descent, abstract representation of expression trees, tree-walking strategies, and so on. This could easily take weeks or more, just for arithmetic expressions.
However, don't let that discourage you. As Jeff and Joel were discussing with Eric Sink on a recent Stack Overflow podcast, writing a compiler is an excellent way to learn about many different aspects of programming. I've built a few compilers and they are among my most memorable programming projects.
Some classic books on building compilers are:
Dave Hanson 与 Chris Fraser 花了 10 年时间构建了世界上最精心制作的编译器之一，有一次告诉我，他从这次经历中学到的主要事情之一就是不要尝试用 C 或 C++ 编写编译器。
如果你想快速开发一些东西，不要生成本机代码； 以现有虚拟机为目标，例如 CLR、JVM 或 Lua 虚拟机。 使用 maximal munch 生成代码。
如果您正在编写解释器，另一个不错的选择是使用底层编程语言的内存管理和其他设施。 解析为 AST，然后通过 AST 的树遍历进行解释。 这会让你快速起步。 性能不是最好的，但也可以接受。 （使用这种技术，我曾经在 Modula-3 中编写了一个 PostScript 解释器。第一个实现花了一周的时间，尽管后来经历了一些性能调整，主要是在词法分析器中，但它从来没有被替换过。）
避免使用 LALR 解析器生成器； 使用可以节省时间的工具，例如 ANTLR 或 Elkhound GLR 解析器生成器。
Dave Hanson, who with Chris Fraser spent 10 years building one of the world's most carefully crafted compilers, told me once that one of the main things he learned from the experience was not to try to write a compiler in C or C++.
If you want to develop something quickly, don't generate native code; target an existing virtual machine such as the CLR, JVM, or the Lua virtual machine. Generate code using maximal munch.
Another good option if you're writing an interpreter is just to use the memory management and other facilities of your underlying programming language. Parse to an AST and then interpret by tree walk of the AST. This will get you off the ground fast. Performance is not the greatest, but it's acceptable. (Using this technique I once wrote a PostScript interpreter in Modula-3. The first implementation took a week and although it later underwent some performance tuning, primarily in the lexer, it never had to be replaced.)
Avoid LALR parser generators; use something that saves your time, like ANTLR or the Elkhound GLR parser generator.
关于编译器设计的经典书籍是
Alfred V. Aho和Jeffrey D. Ullman的《编译器设计原理》。 它已经存在相当长一段时间了，它的粉红骑士和绿龙至少为几代计算机科学学生所熟知。
另外...
“编译器：原理、技术和工具”，作者：Alfred V. Aho、Monica S. Lam、Ravi Sethi、Jeffrey D. Ullman
如果您有兴趣编写编译器，那么这些无疑是最好的起点。
The classic books on compiler design are
"Principles of Compiler Design" by Alfred V. Aho and Jeffrey D. Ullman. It's been around quite some time now and its pink knight and green dragon are well known to at least a couple of generations of CS students.
Also...
"Compilers: Principles, Techniques, and Tools" by Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman
If you're interested in writing a compiler then these are undoubtedly the best places to start.
不要这样做。 （或者至少在这样做之前仔细考虑一下！）
如果您尝试编写一种脚本语言来公开某些自定义编写的对象的方法/属性，那么最好用 Java（或 .NET/ VB 或所有那些讨厌的 Microsoftisms），然后使用 Bean 脚本框架 语言之一作为脚本语言。 （无论微软端有什么等价的东西。）
Don't do it. (or at least think long and hard before you do!)
If you're trying to write a scripting language to expose the methods/properties of some custom-written objects, it would be better to implement those in Java (or .NET/VB or all those icky Microsoftisms) and then use one of the Bean Scripting Framework languages as your scripting language. (with whatever the equivalent is on the Microsoft end.)
任何有关编译器的问题都会在几分钟内得到答案“去读龙书，读那本书，这本书......”，无论内容如何。 所以我跳过了这一部分（就像我一开始所说的那样）。 阅读这些书籍来学习如何使用您想要的工具，与阅读角动量来学习如何骑自行车一样有用。
因此，为了回答您的问题，在不质疑您的意图的情况下，我可以轻松地为初学者推荐 antlr 和 antlrworks。 您可以轻松生成 AST（我认为真正的魔法发生的地方）并直观地调试语法。 它为您生成了工作编译器的很大一部分。
如果你了解自己的东西并且想要更多的控制或者不喜欢antlr，你可以使用 lemon< /a> 解析器生成器和 ragel 状态机编译器（对词法分析有特殊支持）在一起。
如果您不需要太多性能并且计划生成 C/C++ 代码，则可以跳过自己进行任何优化，并将这些内容留给 C/C++ 编译器。
如果您可以忍受缓慢的运行时，则只需进行解释就可以进一步缩短开发工作量，因为这种方式通常更容易实现动态功能。
Any questions about compilers will have an answer "go read dragon book, read that book, this book..." on SO regardless of their content in a few minutes. So I skip that part (like I was telling in the first place). Reading these books to learn how to use the tools you want, is about as useful as reading about angular momentum to learn how to ride a bike.
So, to answer what you asked, without questioning your intention, I can easily recommend antlr and antlrworks for starters. You can generate your AST easily (where the real magic happens, I think) and debug your grammar visually. It generates a good portion of a working compiler for you.
If you know your stuff and want to have more control or don't like antlr, you can use lemon parser generator and ragel state machine compiler (have special support for lexing) together.
If you don't need too much performance and since you plan to generate C/C++ code, you can skip doing any optimizations yourself and leave that stuff to your C/C++ compiler.
If you can live with a slow runtime, you can further shorten your development effort just doing interpretation, since it is often easier to implement dynamic features this way.
我认为每个人都忽略了一个非常重要的一点。
为什么你想写一个编译器/解释器/解析器等吗？
这将严重决定你所做的很多事情。
我已经研究了相当多的语言实现，有些相当奇怪，有些特定于领域，有些只是通过命令环境编写脚本（通常命令环境后来被隐藏）。 每个都需要不同水平的技能。
很多书都可以找到。 我喜欢的是一本 BYTE 书：Threaded Interpreted Languages - 我敢打赌它已经绝版了。
简单的脚本引擎可以通过几个晚上的思考和一些尝试和错误来制作。
但我敢打赌现在有在线课程可以节省你大量的时间。
I think everybody is missing one very important point.
WHY do you want to write a compiler / interpreter / parser etc.
This will seriously determine a lot of what you do.
I have worked on quite a few language implementations, some rather weird, some domain specific, some simply scripted progress through command environments (often where the command environment was later hidden). Each required different levels of skill.
Many books available. One I loved was a BYTE book : Threaded Interpreted Languages - bet it's out of print.
Simple script engines can be crafted with a few evening's thinking and a bit of trial and error.
But I bet there are online courses now that will save you a ton of time.
我强烈建议查看现有的字节码解释器。 如果您可以使您的语言适合 CIL (.NET) 或 Java（甚至其他语言，例如 Python 或 Parrot），那么您将节省创建可行支持环境的所有精力，并且可以继续尝试语言概念。
I'd strongly recommend looking at existing bytecode interpreters. If you can make your language fit into CIL (.NET) or Java (or even others such as Python or Parrot), you'll save yourself all the effort of making a workable supporting environment and can get on with experimenting with language concepts.
如果您打算编写解释器或编译器，请不要因为您想编写下一个大产品而这样做。 写下它是因为你已经有了一个目的或学习目的。 如果你这样做，你可能会发现你不小心写出了下一件大事。
If you're planning on writing an interpreter or compiler, don't do it because you want to write the next big thing. Write it because you already have a purpose for it in mind or to learn. If you do this you may find that you've accidentally written the next big thing.
我用于 LALR 的一个好工具是 GOLD 解析系统。 它是免费的，语法是 Backus-Naur Form，并且有多个示例，包括用 C#、VB.NET、Java 等编写的引擎。 这使您可以编写语法，将语法编译为文件，然后使用引擎来解析语法。
正如上面所建议的，我建议以某种字节代码为目标，例如 IL。 这将使您能够利用大量现有框架。
祝你好运
A good tool that I've used for LALR is the GOLD Parsing System. It's free, the grammer is Backus-Naur Form, and there are multiple examples, including engines written in C#, VB.NET, Java and others. This lets you write a grammer, compile the grammer to a file, and then use an engine to parse the grammer.
As recommended above, I would recommend targeting a byte code of some kind, like IL. This will allow you to leverage the enormous amounts of existing frameworks.
Good Luck
如果您不想编写编译器来将语言简化为汇编语言/机器语言，那么您的下一个选择是编写字节码语言虚拟机的编译器，例如 JVM、PVM 或 .NET。
当然，如果您甚至不想这样做 - 您只想创建自己的“领域特定语言”，我会用 Common Lisp 构建它。 Lisp 宏提供了一种相当直接的方法来创建您想要的任何语法并将其解析为 Lisp。 而且您不必担心字节码或汇编。 当然，你需要学习Lisp。
If you don't want to get into writing a compiler to reduce your language to assembly/machine, then your next option is to write a compiler to a byte-code language virtual machine, such as the JVM, PVM or .NET.
Of course, if you don't even want to do that - you just want to create your own "domain specific language", I would build it in Common Lisp. Lisp macros provide a rather straight-forward method of creating whatever syntax you want and parsing it into Lisp. And you don't have worry about byte-code or assembly. Of course, you need to learn Lisp.