[Mono-devel-list] Reuse parts of MCS in Class Libraries?

[Jonathan Pryor]

On Sun, 2004-05-09 at 00:20, Mark wrote:
> Mono hackers,
> 
> First, I apologize for the length. Because of this I'm going to try to 
> keep it in sections to make skimming it easier.
> 
> Summary:
> ====================
> I have a question about the Mono compiler and re-using some of the MCS 
> code in the class libraries. Can we use parts of the MCS in the Class 
> Libraries to parse C# to the CodeDom through the ICodeParser interface? 
> My concern is really about the licenses. I would also like feedback on 
> how it could best be accomplished.

Every now and then I think we should split up the CVS repositories more,
so that the C# class library is in a different module than MCS.  It
would certainly clear up the licensing questions...

To answer an unstated question: The C# class libraries (mscorlib.dll,
System.dll, etc.) are under the MIT/X11 license (like BSD without the
advertising clause), NOT GPL/LGPL.  The mcs compiler *is* GPL.  The
tools in the "tools" directory have a variety of licenses, mostly GPL.

It's the mono runtime libraries (libmono.so and related; basically the
JIT, internal calls, and anything written in C) which are LGPL.

> CodeDom Interest:
> =====================
> To be up front, I have plans for creating CodeDom-based projects in both 
> GPL and commercial markets. That said, I am very interested in the 
> .NetFramework's CodeDom objects. I have some great ideas for how it 
> could really be taken advantage of. I've also noticed that MS has not 
> provided any implementations of the ICodeParser interface. Additionally, 
> I don't know of any such thing in Mono. So, in order to use the CodeDom, 
> you must either provide a text parser for a given language or create the 
> CodeDom objects at runtime. Once created you can convert to code or an 
> assembly.

You should be very careful about what you expect to be able to do with
CodeDom.  What you've stated shows that you might know what it's
presently capable of, but I'm not entirely sure.

To clarify, CodeDom is not used to parse existing code.  It's used to
generate source code, which can then be handed to an external compiler
to be compiled into an assembly.

> License Issues?
> ======================
> I would like to reuse the work done in the Mono compiler to provide an 
> implementation of the ICodeParser. However, I believe there is an issue 
> with licenses because the Mono compiler is GPL and the class libraries 
> are LGPL. Am I wrong on this? I don't know of any way to satisfy the 
> needs of both and still use any MCS code.

As stated above, the class libraries are MIT/X11.  Mcs is GPL.

Regardless, you could use mcs to implement the ICodeParser interface,
but the resulting ICodeParser implementation could only be used in GPL
projects.  It would also likely be frowned upon by some of the
developers.

> CodeDom Sample Usage:
> =======================
> I believe that the existing system of CodeDom can be a foundation for 
> things like the "Compilers for dynamic languages" listed on the 
> mono-todo list <http://www.go-mono.com/mono-todo.html>. Most scriping 
> languages can easily be condensed to the things in CodeDom. Wouldn't it 
> be neat if you could convert from Perl to Python to Ruby and vise versa?

This suggests a mis-understanding of CodeDom's intent.

CodeDom is used by e.g. VisualStudio for generating templates: you
would describe, via CodeDom, that you want a class (MyClass), with a
method (Main), and some comments ("Do something here").  This CodeDom
description could then be used to generate the template code in VB.NET,
C#, JavaScript...  Anything that has a CodeDom provider.  It's to
generate *human readable* source code.

This was discussed -- in excruciating depth because of perceived GPL
"backdoor" -- in May 2002, when miguel noted:

        The System.CodeDOM API is a mechanism to "build" source code 
        through an API.  It is just an abstraction so that ASP.NET can
        "create" pages built on a number of languages.

        Once you have constructed your "CodeDOM", it is written into a
        file, and an external compiler is invoked.  So there are no
        licensing problems.

See:    http://lists.ximian.com/archives/public/mono-list/2002-May/005929.html

As is, CodeDom could only be used by dynamic language compilers if the
dynamic language compiler were to translate the language into C# and
execute the resulting C# code.  This would likely not be a performance
optimal solution, given that you'd be generating source code and
compiling it before you could begin execution.  There would be lots of
latency in such an approach, and it likely wouldn't perform well.

System.Reflection.Emit is a better bet for dynamic languages, and some
of the enhancements in .NET 2.0 such as DynamicMethods will make this
easier:

	http://longhorn.msdn.microsoft.com/lhsdk/ref/ns/system.reflection.emit/c/dynamicmethod/dynamicmethod.aspx

See:
	http://lists.ximian.com/archives/public/mono-devel-list/2004-February/004016.html
	http://lists.ximian.com/archives/public/mono-devel-list/2004-February/004021.html

Optimization of the Reflection classes would likely also help dynamic
languages.

> Reuse or Recode?
> ========================
> I would love to be able to build on the great work that has already been 
> done. I don't want to recreate all the logic for parsing and tokenizing 
> a language if an existing solution can either be built on or extended to 
> satisfy the issue.

As stated before, this is fine as long as the licensing conditions can
be met.  As you're looking for something that can be used in proprietary
software, you can't use mcs for this.

 - Jon