Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

I've already made a very simple compiler with limited functionality. Now I'm getting more on it to make it more like a real-world compiler. I definitely need to start over because I've much more experience and ideas in this area than I did a few years ago.

Which tasks/features for the new compiler should be implemented first and which tasks have a lower priority?

For example, first I'd decide about the object-oriented structure for the new language, but you might say, hey, just go for a compiler that could define a variable, when you finished that, then start thinking about OOP designs ...

I prefer to hear the pros and cons for your suggestions also. Actually I like to start from Bottom to Top, where I could add simplest tasks first, and later adding more complex ones, but I'm totally open for any new ideas, and really appreciate that.

Also please consider that I'm thinking about the design concepts. Actually I expect answers like:

Priority from Highest to Lowest:

  1. variables, because ....
  2. functions, because ....
  3. loops, because ....
  4. ...

Not:

define a syntax for your new language, and start parsing your source code ...

share|improve this question
1  
Invitations for discussion or collections of thoughts are off-topic on the SE network. Also "hard questions" don't get downvote. Off-topic or ill-formed questions get downvotes. – Joachim Sauer Oct 17 '12 at 9:43
1  
My input: priority #1 must be "what are you trying to achieve with the new language that can't equally well be achieved with an existing one". Unless you can answer that question, everything else is idle musing. – Joachim Sauer Oct 17 '12 at 9:44
1  
Implement macros first, then you'll be able to do the rest of the work from within your language instead of increasing your compiler complexity. – SK-logic Oct 18 '12 at 7:30
1  
And another tip - don't think of your frontend language at this stage. Implement your intermediate representations from the bottom all the way up. And you'll need many of them, see GCC for inspiration. LLVM is quite the opposite approach with its only two major intermediate languages, but it would not recommend going this way without a crystal clear understanding of the requirements of the whole stack of languages you're going to design. – SK-logic Oct 18 '12 at 7:33
1  
@Mahdi, my comments are too short and specific for the proper answers. "Frontend" as in GCC terminology, the language your users will operate directly. The language which is ultimately transformed through a sequence of intermediate languages into the native code. And the syntax is the least important thing you have to think about, you can add it when everything else is ready. – SK-logic Oct 18 '12 at 7:44
show 3 more comments

closed as not constructive by Joachim Sauer, Walter, ChrisF♦ Oct 20 '12 at 10:36

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

2 Answers

up vote 1 down vote

Function calls are #1. You need OS/API function calls to perform I/O and you can't know if anything is working if you can't I/O, unless your language came forth with a working debugger for v1.0. In addition, you can't implement whatever libraries you decide to ship with without OS API. So focus on what you need to start making calls into the operating system API.

After that, you'll want to start with the simple stuff that's mostly already solved- for example, flow control or variables, those constructs are already well-understood and tend to have direct representations in the final product.

Then you're gonna want to start on your libraries, and implement features as you need them. The basic reason for this is because language and library design are complementary and you might discover that it doesn't work as well as you think.

share|improve this answer
Thanks! it sounds good! I'd go to see how I could make a debugger for the very first version! I never thought about it, shame on me! That should save lot's of time and headaches! It's strange, but I never seen anyone notice that it's good to start writing your own debugger, when/before you start writing your own compiler! :) – Mahdi Oct 17 '12 at 10:14
Well, if you base on something like LLVM, in theory LLDB can work on virtually any LLVM-based implementation. – DeadMG Oct 17 '12 at 10:16
oh no, it's not gonna be based on LLVM, but thanks, I never thought about making any debuggers, so I guess that's the time to start reading about them ... – Mahdi Oct 17 '12 at 10:23
up vote 0 down vote

It's doubtfully possible to start from "simple" features and add the necessary functionality later.

The language design usually requires a subset of features to be implemented in order to compiler to be workable. And this subset is, well, almost equal to the whole language. And these features are tightly coupled together. The rest is something unimortant and easy to implement, some syntactic sugar may be (if not - then such feature is good candidate for removal).

So, the only possible way to implement a new programming language I know is an iterative process, forcing you to go back and force, implement new features and the refactor them again and again, as new features usually depends on existing ones in the way you didn't predict from the beginning.

share|improve this answer
2  
Wrong, it is possible indeed to implement a very simple language first and then let it grow on its own. Just add a proper macro metaprogramming to a language at a very early stage. It should not be an iterative process (you don't have to go back) but rather an incremental one. Of course, having the guts of your compiler exposed to the language runtime is highly beneficial for such an approach. – SK-logic Oct 18 '12 at 7:29
I agree with SK-logic. My first compiler has only a single function to output the Binary equivalent of a given HEX cpu instruction. I made a boot-loader with that without any other feature. So, it's possible somehow, huh? – Mahdi Oct 18 '12 at 7:45
1  
@SK-logic Ah, ok. I am wrong. It is indeed possible. It makes macros part of the language then. What if it's not what the language needs? A good language design should eliminate redundancies, not only bring new features. Otherwise the language may become a monster (someone calls it "multiparadigm"). – lorus Oct 18 '12 at 8:35
1  
@lorus, you can disable an access to all the "too powerful" features at later stages when you build a language incrementally. It is quite a common practice. You can even start with an ad hoc typing (or no typing at all) and then grow a powerful and restrictive type system on top (see Shen for example). – SK-logic Oct 18 '12 at 8:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.