[Mono-list] Novel Proposal for Mono Compiler Implementations

[Frank Laub]

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

-----Original Message-----
From: Bob Salita [mailto:bsalita@hotmail.com] 
Sent: Tuesday, July 10, 2001 4:51 PM
To: mono-list@ximian.com
Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations


Novel may be too strong a word but certainly a shift in thinking about 
compiler implementation is accurate. I propose a different kind of
compiler 
design for Mono. One that gives significantly more utility to the
compiler, 
and a compelling distinction between Mono and Microsoft's compiler 
implementations. One that is ideally suited to the open source
philosophy.

State of the Art
Having spent quite a few years thinking about compilers and virtual
machine 
technology, it occurred to me that our view of compilers is obsolete. 
Current compilers read source code and emit machine code, or bytecodes.
This 
is the traditional monolithic approach.

The Problem
When new execution environments are invented, such as in .Net, Java VM
or 
AMD's SledgeHammer, monolithic compilers are difficult to adapt. This is

because the compiler's emitter has a fixed target, either IL or
bytecodes or 
native code. This is too inflexible.

The Solution
Instead, compilers should NOT emit IL, bytecodes, or even native code.
They 
should emit NOTHING. Their task is to merely translate source code into 
information rich parsetrees. Once the parsetrees are built, the
compiler's 
work is done.

Next a user selectable emitter traverses the parsetrees (sort of like 
traversing XML DOM structures). The emitter outputs any of a multitude
of 
targets. The targets could be IL, bytecodes, native code, XML,
obfuscated 
code, lint messages, documentation, or even other languages (e.g. VB6 
compiler builds a parsetree, emitter outputs C#).

The benefits are obvious. Combinations of compiler and emitters still 
produce traditional code. Nothing changes there. The compiler becomes
much 
simpler to write and the emitters are even simpler. First year
programmers 
will be able to write emitters that effectively generate code for whole
new 
architectures. Emitter technology would be highly reusable between
disparate 
compiler implementations or languages. Call it Open Compiler Technology.

Contrast this solution to our current discussions about the vexing
problem 
of adapting gcc to .Net. Or the discussions about how to take existing 
useful Java applications and them in Mono. Open Compiler Technology
makes 
these discussions moot because the solution and implementation method
are 
obvious.

I propose that Open Compiler Technology be the architecture of compilers

used in Mono, furthermore we should demand this style of compiler 
architecture from all our compiler vendors. The benefits of an Open
Compiler 
are unlike any that we have experienced.

Bob.






_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list