[Mono-list] Novel Proposal for Mono Compiler Implementations

[Jay Freeman (saurik)]

I do, and I've been working on it with my decompiler technology.  For a
while I thought what I wanted was to have an intermediate XML
representation, but then I decided that it wasn't the best way to do it and
are going back to an object tree representation.

Many of these similar ideas have already been talked about on the DOTNET
mailing list, both due to the work I was doing on my decompiler (which
should support, still working on the core so C# only for now, multiple
languages; will make sure to have a few ready for my talk at the end of this
month when I release the next version).

One of the end goals of my decompiler has always been a more powerful
version of CodeDOM called ILEngineer.  Once I had the intermediate
representation that gets turned into source code, turning it into a compiled
binary didn't seem that hard, so I finally decided on building just what you
guys are talking about (*sigh*, I need to find something that no ones
interested, maybe I should just buy a damned Mac and work on that, people
keep forsaking Mac software so the competition comes later).

I never really liked the idea of source control in multiple languages,
however, as some things don't express well in some languages and you end up
having to go through terrible hoops.  Even some of the things you can do in
VB.NET don't translate to C# without destroying information along the way to
get back to the original version.

Research I've been doing includes getting Java to decompile into the same
intermediate representation, as well as working out better flow-graph
analyzers (something which may be easier now that I have one of the larger
decompiler venders willing to help me on the occasional sticky point).

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

----- Original Message -----
From: "Frank Laub" <flaub@dev.virtuoso.com>
To: <Bob_Salita@SoftworksLtd.com>; <mono-list@ximian.com>
Sent: Tuesday, July 10, 2001 7:20 PM
Subject: RE: [Mono-list] Novel Proposal for Mono Compiler Implementations


> You know, I've thought about this very thing.  I've specifically thought
> about what kind of emitters you could have.  Here are some revalations I
> had when this is the sort of paradigm is used to develop software:
>
> - Source Control
> Currently, source control works (most commonly) by dealing with files.
> Imagine if code was never in a source format, but if it was always
> stored as a parsetree.  An editor for that code would be much like a
> 'viewer' into that parsetree.  Any language could be used to view
> someone else's work.  (i.e. I write a class in VB, another developer
> modifies that class in C#, another developer debugs that code in a C++
> flavor).  Languages won't truly matter when it comes to implementing
> software.
> - Code Reviews
> I'm thinking that the above will make this process easier.
> - Non-Imperative Centric Views
> Instead of emitting code into IL or bytecodes or opcodes, how about
> emitting it as, say database recordsets (organizations can have true
> code repositories, not just shared files of source code), or say the
> output is some graphical representation.  We're now coming closer to the
> idea of editing code visually, not just faking it by using tools that
> generate source code.
>
> The thing I keep thinking is this isn't really a major departure from
> current compiler technology, just an evolution of it.  By seperating the
> phases of a compiler and keeping those pieces truly independent, all
> sorts of possiblities come out.  AND, the biggest side-effect of this
> that I can see is, it makes writing a compiler easier.  Monolithic
> software is a thing of the past, let's setup the tools (compilers) for
> which we build software to also be componentized (which is exactly why
> I'm so interested in .NET).
>
> I guess these ideas might be sort of out there, but can anyone else see
> where I'm headed?
>
> Frank