* Developer FAQ
** New classes
Q: Should we write classes which are not part of the .NET or ECMA specs?
A: Yes. The ECMA and .NET specifications are far from complete, and
to produce a complete platform we will need a number of other
classes and components.
Any new classes that are not part of .NET or ECMA should be
designed to be reusable on anyone's CLI implementation. So that
Windows developers can also use any new classes that we come up
with.
We have a few existing Ideas on missing
classes
** Language Compatibility
Q: What is the magic that allow multiple languages to co-exist?
A: From Fergus Henderson:
There are different levels of interoperability.
The ECMA spec defines different categories of
CLS (Common Language Specification) conformance.
There are also some useful categories that don't
correspond to any of the levels defined in the ECMA spec.
In increasing degree of difficulty, your language implementation
can
** PInvoke
Q: What are the two major initiatives to implement PInvoke?
A: Fergus Henderson answers:
* (a) just generate IL
* (b) be a CLS "consumer", which means that it can read in
meta-data describing component interfaces,
and that it provides a way to declare variables of
CLS-complaint types and to call CLS-complaint methods.
* (c) be a CLS "extender", which means that it can in addition
derive from CLS-compliant classes
and implement CLS-compliant interfaces
* (d) be able to produce components with *any* CLS-compliant
component interface.
Supporting some of these may require extending your language. However,
you can get quite a lot of interoperability by just putting appropriate
functionality in your compiler, without extending your language.
For some things, e.g. ASP.NET, your language implementation also needs to be
able to
* (e) consume CodeDom trees. CodeDom trees are an abstract
representation of programs in a form similar to a C# parse
tree, with embedded code snippets (unparsed strings).
Given a CodeDom tree, with the snippets in your language,
your language implementation needs to generate a (i) .NET
assembly and possibly also (ii) a source file in your language.
* (f) produce CodeDom trees. For some applications,
your language implementation also needs to be able to
round-trip from CodeDom -> your language -> CodeDom.
and for some things it needs to
* (g) generate *verifiable* IL
So when you hear all the hype about how language XYZ is a
".NET language", make sure you ask which of these different
things are supported.
[For the record, Mercury currently supports (a). We're working on
(b) and (g), and on parts of (c) and (e). We're never going to do (f), I very
strongly doubt we'll ever do (d), and for (c) we might only ever support
implementing interfaces, not deriving from classes.]
Many of the .NET APIs will need to be implemented using code that calls C/Unix
APIs, such as stat(). The standard way of interfacing with native code from
.NET code is to use "PInvoke". However, there is a difficulty: many of
these APIs are defined in terms of types such as C's `long' or `size_t'
or the Posix `struct stat' whose representation varies depending on the
platform (architecture/OS/C compiler). There's no *portable* way of
accessing those from .NET managed code.
So, there are a couple of different approaches.
One possibility is to access such routines by writing a wrapper, e.g. in C,
that provides the same functionality without using types with a system-dependent
representation. The wrapper can then be directly accessed from portable
.NET code. The .NET code remains both source- and binary-portable;
the wrapper code is source-portable, but needs to be compiled
seperately for each target platform. The drawback of this approach is
that you have to write a lot of cumbersome wrapper code.
Another possibility is to extend the .NET VM with support for an
additional custom attribute, e.g. "[PosixType]". The VM would then
represent types tagged with this attribute in the same way that the
underlying system represents those types. With this approach, no
wrapper code would be needed. A drawback of this approach is that it
pushes quite a bit of complexity into the VM; the VM would have to know
the native representation of all types annotated with this attribute.
Another drawback is that code using this extension might not work on
different VMs.
There have also been some other suggestions, but those are the two that
I think are the best.
Q: What is the problem implementing PInvoke?
A: Again, from Fergus Henderson:
There's no problem implementing PInvoke as specified in the ECMA
specs and/or MS documentation. It's just that PInvoke by itself
doesn't solve all of the problems; in particular it doesn't solve
the problem of C types whose representation is different on different
systems.
** CVS use
Q: Why do we keep ChangeLogs and make the CVS commit messages be the
same? One could be generated from the other
A: There are a number of reasons for keeping ChangeLog files as well as
CVS commit files: