1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
* 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 <a href="ideas.html">Ideas on missing
classes</a>
** Language Compatibility
Q: What is the magic that allow multiple languages to co-exist?
A: From Fergus Henderson:
<i><blockquote>
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
<ul>
* (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.
</ul>
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
<ul>
* (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.
</ul>
and for some things it needs to
<ul>
* (g) generate *verifiable* IL
</ul>
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.]
</blockquote></i>
** PInvoke
Q: What are the two major initiatives to implement PInvoke?
A: Fergus Henderson answers:
<i><blockquote>
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.
</blockquote></i>
Q: What is the problem implementing PInvoke?
A: Again, from Fergus Henderson:
<i><blockquote>
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.
</blockquote></i>
** 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:
<ul>
* Offline programming: when people are traveling, CVS logs are
not available.
* Slow CVS access: Many people work over modem lines (very
typical for contributors in Europe, Asia, Latin America)
using CVS is slow and might not be available to you (cvs
server down, no anoncvs server available).
* ChangeLogs travel in a released tarball package, so it is
possible to study the rationale of changes even after a
project is long "released", or you only have the sources for
the code.
* ChangeLog are not metadata for each file, they are live
files that you can browse in the package that is being
distributed.
</ul>
Making the CVS commit message be the same as the ChangeLog has other
benefits:
<ul>
* You can track down with `cvs log' what things were changed,
and match those to meaningful reports on the intentions of
the commit.
* When reading the commits-list, you can get a glimpse of the
changes without having to diff out or cvs update your tree.
* You can read off-line the changes that are being made
(asyncrouns operation).
</ul>
This mechanism works very well for GNOME and other projects.
Q: Should I use any of the special RCS keywords like $Id: devel-faq,v 1.1 2001/07/31 21:13:05 miguel Exp $, $Author: miguel $,
$Date: 2001/07/31 21:13:05 $, or $Revision: 1.1 $?
A: Please avoid using those in the source code in the CVS. They
are not really useful, and they cause a lot of conflicts when
people have separate CVS trees.
It was a nightmare with the Linux kernel when two people had their
private CVS trees and were submitting patches to the core.
|
