[Mono-list] Novel Proposal for Mono Compiler Implementation

[David Gardner]

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 7/11/01, 1:20:45 AM, "Frank Laub" <flaub@dev.virtuoso.com> wrote 
regarding RE: [Mono-list] Novel Proposal for Mono Compiler Implementation:


> 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.

Surely there has to be some reasonable limit to this. I can't quite 
imagine writing code in C++ and reading it in Prolog and LISP :)

Also, how would you deal with preconditions/postconditions/invariants 
written in Eiffel? More generally, how do you deal with any feature in 
one language not present in another (eg single/multiple inheritance, 
early/late binding, contracts/no contracts, strongly/weakly typed, 
functional/imperative) 

> - 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.

Now the graphical view idea really does sound good. I've always wanted to 
use software components like electronic components, ie like drawing a 
schematic diagram. I would imagine it would be easier for a 
non-programmer to make a custom application using this schematic/graphic 
approach, rather than edit 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 think it's an excellent idea to solve a problem by dividing it into two 
pieces, each less than half the size of the original problem!

Dave