Bidirectional Compiler

A compiler (or any program processing tool) which modifies/annotates the source code. Programmer writes code, passes it to the compiler. Compiler adds annotations (error messages, suggestions for clarification, perhaps optimization decisions, profiling information) which the programmer considers for next pass through. Allows, arguably, for greater interaction between the human and the tool.

On the other hand, may cause problems:

• Complicates the case of multiple persons editing the same file; you have to make sure that different modifications by different invocations of the tool don't clobber each other.
• Even ignoring that, the tool might clobber the file anyway, though an automated backup can help.
• One can achieve similar advantages with a good IDE or an ImageBasedLanguage.

---

I've never heard it called this, and there are zero google hits. The term suggests an integrated compiler plus decompiler.

Somebody uttered the phrase, so I started a WikiPage. Feel free to rename if appropriate; though the original utterer of the phrase (on FutureOfProgrammingLanguages) ought to weigh in...

More commonly there are source-to-source transformers/compilers, program transformers, etc.

For instanced, ccured/cil at http://www.cs.berkeley.edu/~necula/

---

A compiler is normally a unidirectional tool which is capable of parsing source text, and producing a symbol table, object deck, comments list, etc. (Comments need to be preserved if you want to work it both ways.)

The ability to edit the symbols and/or object and then get a new version of the source back would greatly aid in refactoring programs. The concept could further be extended to aid in translation of source code between two languages which both have a bidirectional compiler available.

Combine this concept with RichSource, and you get closer to the FutureOfProgrammingLanguages. -- MikeWarot

---

The problem with decompilation is of course, that usually information is lost when compiling due to

• Preprocessing
  • Comment elimination
  • ConditionalCompilation?
• Optimization
  • ConstantPropagation?
  • DeadCodeElimination?
  • CodeInlining?
  • LoopOptimization? (loop unrolling, loop fusion, ...)
  • RegisterAllocation
  • et cetera
• Obfuscation
  • removal of local variable tables or
  • scrambling of non-external identifiers
• Ambiguity
  • syntactical ambiguity (indentation, order of CaseStatements?)
  • semantical ambiguity
    • "a=a+1", "a+=1", "a++"
    • "if (c) a else b", "if (not c) b else a"
    • et cetera

If the original code is annotated, this may be no problem, but if the original form is not available or in another language this limits this approach.

---

One question is do you want the code back in the same general form that you compiled it in? There are some cases in which you probably don't care (white space and style issues) and other cases where you might. If you do want to preserve some idiom that can be decompiled in different ways, it seems easy to me to have the compiler write a file containing instructions for the decompiler.

If done in a human readable and flexible manner you could probably use this file for automatically refactoring code as well. -- DavidShockley?

---

I just discovered RefactoringBrowser, which does some of what this concept is all about. I cut to the core of the problem, however, and intend to use the compiler as a tool in both directions, parsing and regenerating source code. If you can transform a program from source to symbols, object code, and comments, then back, you end up with an incredibly powerful tool. Refactoring programs from C++ to Pascal and back can be done, with comments, automatically. (The only gum in the works is Macros)

I'm finding that this wiki is much larger than I thought it was, there's no quick efficient way to browse the whole thing, which I assume is by design, because it forces contemplation, and discourages quick edits in and out. -- MikeWarot

---

This is one of the things which I think could be useful in a language that does TypeInference. You could write the code and if it type-checks, the compiler would back-annotate the inferred types on all public interfaces. -- StephanHouben

Though that could defeat some of the purpose of type inference, such as being able to change a type more easily without changing a zillion declarations all over the place. This is a keen idea though; it would be useful even if all it did was spit out a source file with notes on the various optimizations that got performed at various parts of the code. Being able to, in a way, profile your optimizer would be neat. -- SimonHeath

---

See DeCompiler

CategoryRefactoringBrowser CategoryRefactoring CategoryCompilers