/
README.DotNet
231 lines (162 loc) · 8.26 KB
/
README.DotNet
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
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
-----------------------------------------------------------------------------
INTRODUCTION
This release of Mercury contains an incomplete port to the Microsoft.NET
Common Language Runtime (CLR). This port is very new, so there are still
many unimplemented features. Currently (2002-10-28) it passes about half
of the tests in the Mercury test suite.
The port is currently targetted at the Microsoft .NET SDK version 1.
The Mercury compiler will generate code in Microsoft's Intermediate
Language (IL) that can be assembled into bytecode suitable for running
in the .NET runtime system. In addition, much (but not all) of the
Mercury library has been ported to use the .NET Frameworks.
In order to try this system you will need
- The Microsoft .NET Framework SDK version 1, which can be
downloaded for free from
<http://msdn.microsoft.com/net/>
If you are an MSDN Universal subscriber you can also order
CDs as part of your subscription.
It might also work with later versions, but we haven't tested
with those.
- A windows system suitable for development with Microsoft .NET.
According to Microsoft, the .NET Framework SDK runs on:
Microsoft Windows NT 4.0 (SP 6a required)
Microsoft Windows 2000 (SP 2 recommended)
Microsoft Windows XP Professional
We have tested only on Windows 2000 (with SP 2).
- Cygwin (see README.MS-Windows for how to install).
The Mercury compiler still runs as a native compiler, built
with gcc by default -- although see README.MS-VisualC for how
to build with VC++ if you wish.
Mercury still relies upon the Cygwin environment for
development environment tools such as `mmake'.
You need the following Cygwin packages:
- gcc
- binutils
- make
- If you have installed the .NET SDK as part of Visual
Studio .NET, you will need to put the Visual Studio
binaries in your path, and set appropriate environment
variables. The easiest way to do this is to put the line
call "C:\Program Files\Microsoft Visual Studio.NET\Common7\Tools\vsvars32.bat"
into your cygwin.bat file (installed on the desktop by cygwin),
after the line that says @echo off.
Substitute your Visual Studio installation path for the default path
given here.
- The Mercury distribution -- installed as usual. Make sure
the installation is run after the Microsoft .NET SDK is installed
(run it again if necessary) so that the configuration scripts
detect the installation path of the SDK. If `configure' finds
`ilasm' and `cl' then this has been successful. You can install
from either the source or binary distribution.
If you're reading this file from somewhere other than the
Mercury distribution, try the Mercury homepage at
<http://www.cs.mu.oz.au/mercury/>
-----------------------------------------------------------------------------
THE IL GRADE
The Mercury compiler currently supports the grade 'il' to target the
Microsoft.NET CLR. Support for building and installation of this grade
is still somewhat rudimentary.
To run a Mercury program using the il grade, you need to build the
library and runtime in the il grade, using the Mercury source distribution.
If configure finds the .NET SDK installed on your machine, the il grade
will be added to the list of default grades to be installed, so simply
running
mmake install
from the Mercury source distribution will install the il grade.
You can now build programs such as hello.m or calculator.m in the samples
directory.
cd samples
mmc --make --grade il hello
Now you can run hello
./hello.exe
Alternatively, if you prefer, you can use mmake rather than `mmc --make':
mmake hello.depend GRADE=il
mmake hello GRADE=il
./hello.exe
You can also set the grade in an Mmakefile, by adding the line
GRADE=il
to the Mmakefile; then you can leave the "GRADE=il" part off the mmake
commands.
-----------------------------------------------------------------------------
USING DOTNET
The Mercury standard library has not been fully ported to .NET yet.
The use of unimplemented procedures will result in a run-time error,
with a message such as "Sorry, not implemented: foreign code for this
function", and a stack trace.
If you find missing functionality, you can interface to the .NET
Frameworks using C# and Mercury's foreign language interface.
For example:
:- pred to_string(T::in, string::out) is det.
:- pragma foreign_proc("C#", to_string(T::in, Str::out), [],
"{
Str = T.ToString();
}").
The implementation will put this C# in a separate file, which will be
compiled with Microsoft's C# compiler. Mmake will automatically
generate dependencies for this file and invoke the C# compiler with the
appropriate options.
You can also use the C# interface to interface with any .NET language
(Implementations have been announced or are under development for
C++, C#, Visual Basic, Cobol, Eiffel, SmallTalk, ML, Haskell, Scheme,
Python, Perl, Component Pascal and others).
Add a
MS_CSCFLAGS-<modulename>_csharp_code=/reference:<foreignmodulename>.dll
or
MS_CSCFLAGS-<modulename>_csharp_code=/addmodule:<foreignmodulename>.dll
to your Mmakefile to pass the appropriate flag to the C# compiler so
that you can reference another DLL from the C# code.
<modulename> is the name of your Mercury module, and <foreignmodulename> is
the name of the dll you want to use from Mercury via C#.
We are working on a tool that automatically generates a Mercury interface
for any .NET component, but it is not yet ready for public use.
Currently each top level Mercury module is placed into its own assembly.
For example, module.m will be placed into the assembly `module', while
module.sub.m will also be placed into the assembly `module'.
To create a strongly named assemblies in Mercury you need to pass the
--sign-assembly flag to the Mercury compiler. Note that this flag needs
to be also passed when generating the dependencies for the module being
compiled. Currently we use the same strong name as used by the mercury
standard library to sign all the Mercury modules, at a later date we
hope to lift this restriction.
-----------------------------------------------------------------------------
RESOURCES
You might find the following pages useful:
http://www.cs.mu.oz.au/research/mercury/dotnet.html
http://msdn.microsoft.com/net/
http://www.gotdotnet.com/
-----------------------------------------------------------------------------
FREQUENTLY ASKED QUESTIONS (FAQS)
Q. What are the advantages of using the .NET back-end?
A. The main advantage is easy access to the wide range of libraries for the
.NET platform.
Q. Does it work with other .NET Common Language Runtime implementations,
such as Mono, Portable.Net, or Rotor?
A. Some parts of the Mercury standard library implementation for .NET
are implemented using Managed C++ (Microsoft's extensions to C++
to support .NET). So you need the Microsoft .NET SDK (which includes
the command-line version of Microsoft's C++ compiler) to build the
Mercury standard library in the `il' grade.
In theory, once you have done that, it should be possible to
build Mercury programs in the `il' grade using any ECMA-compliant
IL assembler that provides the same command-line interface as
the Microsoft ilasm.exe program, and to execute them using any
ECMA-complaint .NET CLR implementation. However, we have not yet
tried using other .NET CLR implementations.
Q. How does it compare in efficiency with the usual Mercury implementation?
A. Our paper "Compiling Mercury to the .NET Common Language Runtime",
which is available from the Mercury web site, has some benchmark
results. As usual, your mileage may vary.
Q. What features are not yet implemented?
A. The following standard library procedures are not yet implemented:
- io__command_line_arguments
- io__set_environment_variable
- io__read_file_as_string
- builtin__copy
The following are only partly implemented:
- string__format ignores most of the formatting flags
- support for standard library routines that involve
run-time type identification is very patchy
In addition, there is a Mercury compiler bug which causes problems
for procedures with mode "unused" (a.k.a. "free>>free").
The lists above are probably incomplete.
-----------------------------------------------------------------------------