On Fri, 10 Dec 2004 14:49:44 +0000, Colin JN Breame <[EMAIL PROTECTED]> 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? _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list