Become familiar with the technology. You can't create a programming language if you don't know how to use a computer.
Become familiar with the terminology. Compiler writers often use unfamiliar terminology. Read up on compilers before proceeding. Be sure to know everything that you need to know.
Decide what problem your language is solving. Is it addressing a domain-specific problem, or is it a general-purpose language?
Think about the semantics of your language and the concepts of it. Are you going to allow direct pointer access or not? What are the data types of your language? Is it a static or dynamic language? What is your memory model? Are you going to use a garbage collector or manual memory management? (If you use a garbage collector, prepare to write one or adapt an existing one to your language.) How are going to handle concurrency? Are you going to use a simple threading/locking model or something more complex like Linda or the actor model? (Since nowadays computers have multiple cores.) Are there primitive functions embedded in the language or will everything come from a library? What is the paradigm or paradigms of your language? Functional? Object-oriented? Prototype (like JavaScript)? Aspect-oriented? Template oriented? Or something entirely new? How is your language going to interface with existing libraries and languages (mainly C)? This point is important if you're building a domain-specific language. Finally, some of the answers to these questions are going to be answered by the second step and will help you answer the next step.
Think of some specific tasks that someone would want to be able to perform with your language. For example, 'they may want to direct a robot to follow a line' or 'they may want to create relatively portable desktop programs in it' or 'they may want to create web applications with it'.
Experiment with syntax ideas (the text of the language) for the above examples. Be careful to keep your language in the context-free language category or something inside it. Your parser generator and you will appreciate it later on.
Write out a formal grammar for the syntax.
Decide whether the language will be interpreted or compiled. Meaning that in the interpreted world your user will typically edit your program in an editor, and run it directly on the interpreter; while in the compiled world, your user will edit your program, compile it, save the resulting executable somewhere and run it.
Write the front end scanner and parser or find a tool that helps you with this. Also, think about how your compiler/interpreter will warn your user about erroneous programs and syntax errors.
Use the parser information to write the object code or an intermediate representation. Have the parser create an AST, then create your object code from the AST using three address code or its big brother SSA, then create a symbol table to define your functions, global variables, etc. Also, depending on your language, you may also want to create virtual pointer tables or information tables for your classes (in order to support reflection or RTTI).
Write the executor or code generator that will bind everything together.
Write many test programs to test the language. You want to create programs that stress the burdens of your formal grammar in order to see that your compiler accepts everything that is inside your definition and rejects everything that is outside of it.
Consider how the user will debug their own programs.
If your language uses a standard library, you will want to write it. Along with a garbage collector or other runtime features if you need it. Specifically, if you write a compiler, you will need the code that the operating system will execute in order to begin running the user code (for example, allocating all global variables).
Publish your language, along with the specification for it and some examples of what you can do in it. Don't forget to document how you can integrate with existing libraries, languages and how to use the runtime features and/or standard library.
Comments
0 comment