[Mono-list] Mixing languages within
Michal Moskal
Michal Moskal <michal.moskal@gmail.com>
Fri, 10 Dec 2004 17:01:25 +0100
On Fri, 10 Dec 2004 14:49:44 +0000, Colin JN Breame
<colinb@chameleonnet.co.uk> wrote:
> Michal Moskal wrote:
>
> >The problem is cross references -- that is if part in language A needs
> >part in language B and vice versa. Then the compilers need to agree
> >much more -- upon some internal APIs, which seems quite difficult in
> >general.
> >
> Not that I'm an expert, but the 'common' parts would probably be
> something like:
> - a shared symbol table
> - shared intermediate representation (does mcs or the vb compiler use
> an intermediate representation? how about ironpython and nemerle?)
> - shared error reporting mechnism
The last one seems easy :)
As for the shard symbol table -- you would also need to share
information about partially built types (that is without all method
already compiled and so on). This could have been
System.Reflection.Emit stuff, but... If I checked correctly even mcs
doesn't use S.R.E.TypeBuilder as the internal class representation.
This is even less the case for Nemerle, as we need type system
features absent from .net 1.1 and 2.0 (like algebraic types, and
function types). Dunno about IronPython.
As for the intermediate representation -- mcs uses syntax trees, that
are later modified during the compilation. Nemerle compiler uses 3
kinds of trees during the compilation, and 2 more are in the plans.
Yet another problem is the scale -- you need to expose lots of
previously internal API, which makes all your compilers one big
compiler and this isn't any good.
So the bottom line is: the only way to merge two existing compilers is
to write them from the beginning... OTOH designing the compiler to be
extensible from the beginning seems possible ;)
--
: Michal Moskal ::: http://nemerle.org/~malekith/ :: GCS !tv h e>+++ b++
: ::: Logic is a nice contrast to the Real World. :: UL++++$ C++ E--- a?