[Caml-list] RE: OCaml on CLR/JVM?

[Caml-list] RE: OCaml on CLR/JVM?

[Dave Berry]

I think Microsoft should be congratulated on their outreach to programming
language researchers.  I for one would certainly welcome a widely
distributed VM that is a good target for compiling ML.  Interoperability
with other languages on the same VM would be a bonus.

That said, interoperability is still hard.  You're making it easier, for a
single platform (a hardware-independent platform, which is good, but still a
single platform).  I'm not out to rubbish your work, or your goals; but
there is no general solution to the problem, and interoperability with C
(etc.) will still be needed, unless and until the .NET CLR is the de facto
standard everywhere.

Regarding threads, I have encountered problems mixing Java threads with
native Windows threads, and with mixing Dylan threads with native Windows
threads, and mixing MLWorks threads with native Windows threads.  With care,
simple cases should work fine, and this is often sufficient.  But there
always seem to be dark corners to trap you if you attempt more complicated
uses.  Again, I don't want to knock attempts to improve this situation.  I
just think it's fundamentally hard to resolve all cases.

Dave.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] RE: OCaml on CLR/JVM?

[Marcin 'Qrczak' Kowalczyk]

Fri, 16 Feb 2001 19:06:31 -0000, Dave Berry <dave@kal.com> pisze:

> interoperability with C (etc.) will still be needed, unless and
> until the .NET CLR is the de facto standard everywhere.

Will it be used on other OSes than Windows?

I don't know the answer, but from my point of view this is an important
question which needs to be answered before I can think if I like it
or not, and before I can decide to be interested in it or not. Very
important.

On Unix most libraries are written in C, as are runtime systems for
most languages. All other languages are far less popular. Will another
common (= used for interoperability) language be common (= popular)
after five years?

There are two separate questions: can an idea similar to CLR work
well at all? and is this concrete Microsoft's product good?

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] RE: OCaml on CLR/JVM?

[Arturo Borquez]

Hi all folks:
Perhaps I am wrong, but let me state what I believe
about this stuff. Microsoft .NET strategy is an intra
Microsoft issue to scale-up VB they are trying stop
VB app developers to switch to java. C# is not really
important as it will never reach the 'mass' of VB.
The real issue is continuity of the actual Client/
Server model that holds distributed processes and a
more and more sophisticated (complicated) middleware layer. In my oppinion this model has no future, the 
real battle is at the server side, so clients would
become minimal-device support to interface server
apps across the net (ultra-thin-client), with a
diverse and broad family of client devices (terminals).
So OS interoperability (independence) is very important
because the real (active) apps will reside in the
Server side (they will drive terminals as has being 
done in the past [minitel, VTs, CICS ...]) and Caml
is doing it yet (UNIX, WINDOWS IBM mainframes OSes
missing?). I think this is the 'confuse age' that
will be clarified in the next few years. We need a new
enhanced version of TCP/IP (or something similar), a
standard message system and protocols as simple and
effective as possible (deal only with data) to do
client to host and host to host interactions. Message
translations (mappings) redundant service resolving and
assignment, load balancing can be performed much more
effective with dedicated communication front-ends than
language interoperability or ORB's and stubs in both
sides apps. Perhaps new versions of OSes will embbed this issues.
My conclusion is CLR/JVM, CORBA RPC ... are not
important for the future of Caml, as all will die.
Caml will need only some library updates to match the
communication tech upgrades.
The big argument is cost. Actual Client/Server costs
a factor ~ 1.5 (develop, maintenance, deployment) 
compared with old dinosuar mainframe (CICS), and that
why some important enterprises still deploying these
systems.
The technical argument is that in the actual Client/
Server model the NET is inserted in the wrong position
so your app becomes broken in somewhat the 'middle'.
To correct this mistake you must put the NET outside
the app (or the app inside the Server), and the Client
device only runs the 'client-applet' the server sends
for that particular app (Client request).
Regards.
Arturo Borquez


Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] RE: OCaml on CLR/JVM?

[John Max Skaller]

Chris Tilt wrote:
 
> On the subject of who leads long term research (industry vs.
> institutions), I am dissapointed with the lack of functional
> programming exposure taught in undergraduate studies. It is
> very difficult to find programmers who have any history at
> all with this approach.

	I agree. I'm an example.
 
> Until institutions give equal time to functional, industry
> will be unaware of it.

> The process of adopting long-term a functional approach is
> going to be slow, but can be sped up if institutions produce
> graduates who have higher expectations of productivity
> through exposure to modern languages. I will help in any way
> that I can as I feel much appreciation to this community
> for our success, however it must start in education.

	Actually, I don't think it is 'functional' programming
that is really so important as the _approach_ to programming,
as exemplified by the Ocaml team.

	Programming involves 'compromises': Ocaml, for example,
isn't a functional programming language: it provides facilities
for functional, procedural and object oriented development.
Thus, referential transparency is lost,
but what the developers have refused to compromise is the 
static type system.

	What is important here, in my opinion, is that the
decisions are not made entirely by guessing, or by consensus,
or by experience, although these factors surely count,
but instead, where possible, decisions are informed and rational: 
based on having done some actual theory.

	It is this basis in theory which, in my opinion,
is the strength of 'functional' languages, rather than
the functional paradigm itself.

	Another example of similar work is the logic programming
language Mercury.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] RE: OCaml on CLR/JVM?

[Chris Tilt]

 This is a valuable discussion and I appreciate both views
on the subject. I am using OCAML in a commercial development
with great success and continue to benefit from the excellent
work by the research community. The OCAML team and it's
contributors have always been friendly and helpful to industry.

In addition, we have employed recently a prominent researcher
in functional programming. It was very valuable for both our
commercial entity and the visiting researcher to share perspectives
in a collaborative environment. We gained insight and high
quality code while the researcher gained an inside view into
the needs and activities of a recent commercial effort where
functional programming has strong merit.

On the subject of who leads long term research (industry vs.
institutions), I am dissapointed with the lack of functional
programming exposure taught in undergraduate studies. It is
very difficult to find programmers who have any history at
all with this approach.

Until institutions give equal time to functional, industry
will be unaware of it. Further, research funding in that
area will suffer. Microsoft, etc., will have no pressure to
support it in work such as .NET. To my understanding, there
were functional programmers employed on that project, but
the pressure from industry is too small to influence the
outcome.

The process of adopting long-term a functional approach is
going to be slow, but can be sped up if institutions produce
graduates who have higher expectations of productivity
through exposure to modern languages. I will help in any way
that I can as I feel much appreciation to this community
for our success, however it must start in education.

Thank you for listening.

-Chris

http://www.webcriteria.com

-----Original Message-----
From: John Max Skaller
To: fabrice.le_fessant@inria.fr
Cc: caml-list@inria.fr
Sent: 2/16/01 8:54 AM
Subject: Re: [Caml-list] RE: OCaml on CLR/JVM?

Fabrice Le Fessant wrote:

> There is an HUGE difference between open source and standards. The
> first one can always freely evolve, while being used freely by many
> users. Standardized ones cannot evolve anymore, or need the company
> agreement to be modified. Compatible software will always have to
> follow the company new developments, and thus will never be truely
> achieved. This is one of the -many- drawbacks of Java.

	I do not agree, although you seem to be using a wrong example.
Standardised systems can and do evolve. The evolution consists of
experiment, discussion and consensus formation, followed by
implementation
by many parties, followed by error reporting (Note I mean
errors in the specification: the 'standard')

	But what you describe as drawbacks of Java (with which I might
agree), but Java is _not_ a Standardised language, at least in the
sense of being approved by a standards processes within a recognized
standards body (such as ISO, IEC, ...).

> The problem is that .NET is a commercial product. So, the question is:
> should we spend our time porting Ocaml to all new commercial VMs (not
> only MS ones, of course) ? 

	Of course not. But .NET is being sponsored by a major player
and we can expect a significant number potential of Ocaml users.

	Please do not forget that programming is principally
a commercial activity, and that those of us who
indulge -- even part-time -- in research activities, is 
relatively small (and lucky :-)

 
> One time again, commercial issues have dominated scientific
> reasons.

	Of course: science requires funding: it too
is a commercial activity, it must compete, and it doesn't
always win the competition. :-)

> CLR has been released too early, and will be standardized too
> early, while big problems are still remaining: no polymorphism,
> object-oriented approach in the bytecode, ... This should have been
> discussed first, not in the next version !

	I agree.

> Of course, it won't change my mind. I will always think that public
> research and commercial research have different goals...

	Of course they do, because they differ in their funding models.
Generally, public institutions can be more long sighted than commercial
ones, whereas commercial ones have more dynamic growth patterns and
so must be more short-sighted.

	However, one should be rightly annoyed at larger corporations,
since they rival public institutions in size and stability, but seem
still
to lack the capacity for long term research. And perhaps this is partly
the fault of the public institutions for remaining too aloof from
the commerical world.

	I believe this creates a tension in which the commercial players
put pressure on public institutions (like ISO, academia), for a more
'commerical' approach. And perhaps one could ask how to best direct
pressure on those companies, to take a more long sighted view in return,
and work with the public intitutions better in the area of research.

	The only way I know how to do this is for those who see 
commerical merit in research to work in and for the commercial entities,
since they are organisations of people too. :-)

	To put this argument another way: we will do better to 
convince the commercial programmers of the world that the Ocaml way is
better if it is actually available on the platform they use to
implement commercial solutions. 

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives:
http://caml.inria.fr
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Re: OCaml on CLR/JVM?

[Dave Berry]

> From: Sven LUTHER [mailto:luther@dpt-info.u-strasbg.fr]
> Sent: Thursday, February 15, 2001 12:13 
> 
> On Wed, Feb 14, 2001 at 08:30:51PM +0100, Xavier Leroy wrote:
> > ...it is possible to automate fully the generation of
> > stub code for interfacing with Java or .NET, while this is not
> > possible in C.

I was thinking of the sort of interoperability problems that Xaview listed
in other recent messages.  But he is of course right that generating stub
code for interoperability with C is a hard problem, and is much simplified
in Java, COM (with type libraries) and .NET.
 
> > - types of function arguments and results, and of data structure
members;
> 
> This can be automated by a basic parser tool, isn't it ?
> This is what i started to do with c2caml, but i have no time 
> to continue work on it.

The parser part is relatively straightforward, but there are many
complications.
-- #include files: do you translate each header file separately?  How do you
refer to items translated in #include'd headers?  How do you resolve name
clashes.
-- #ifdef's
-- macros
-- typedefs
-- proprietary extensions
-- pointer types: e.g. is a char* an array, a null-terminated string, a
sequence of null-terminated strings, or an output parameter?

> > - memory protocol (who frees dynamically-allocated memory and when?)
> > - error reporting protocol 

> Anyway, automating this kind of things would perhaps not gain you a lot
for
> the initial stub writing, since you have to provide some info at first to
help
> an automated tool, but once that is done, it would help a lot to keep
track of
> various versions of the same library.

This is true.  If you can specify the necessary interpretations in a file
separate from the headers.  E.g. you could specify that all the char*
pointers in a given header file are strings, except for certain parameters
of certain functions.

The Dylan community have investigated this in some depth, although I don't
know that they have a finished tool.  Harlequin's Dylan implementation
benefited hugely from code that was automatically generated from C header
files.  Although the translations were highly specific to particular header
files, it was still quicker than translating all the code by hand,
especially when it came to regenerating the code.

It would be useful to have a tool that interpreted C header files and
produced IDL files, not just for OCaml, but for all advanced programming
languages.  If this was sufficiently portable, many projects could benefit.

Dave.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] RE: OCaml on CLR/JVM?

[John Max Skaller]

Fabrice Le Fessant wrote:

> There is an HUGE difference between open source and standards. The
> first one can always freely evolve, while being used freely by many
> users. Standardized ones cannot evolve anymore, or need the company
> agreement to be modified. Compatible software will always have to
> follow the company new developments, and thus will never be truely
> achieved. This is one of the -many- drawbacks of Java.

	I do not agree, although you seem to be using a wrong example.
Standardised systems can and do evolve. The evolution consists of
experiment, discussion and consensus formation, followed by
implementation
by many parties, followed by error reporting (Note I mean
errors in the specification: the 'standard')

	But what you describe as drawbacks of Java (with which I might
agree), but Java is _not_ a Standardised language, at least in the
sense of being approved by a standards processes within a recognized
standards body (such as ISO, IEC, ...).

> The problem is that .NET is a commercial product. So, the question is:
> should we spend our time porting Ocaml to all new commercial VMs (not
> only MS ones, of course) ? 

	Of course not. But .NET is being sponsored by a major player
and we can expect a significant number potential of Ocaml users.

	Please do not forget that programming is principally
a commercial activity, and that those of us who
indulge -- even part-time -- in research activities, is 
relatively small (and lucky :-)

 
> One time again, commercial issues have dominated scientific
> reasons.

	Of course: science requires funding: it too
is a commercial activity, it must compete, and it doesn't
always win the competition. :-)

> CLR has been released too early, and will be standardized too
> early, while big problems are still remaining: no polymorphism,
> object-oriented approach in the bytecode, ... This should have been
> discussed first, not in the next version !

	I agree.

> Of course, it won't change my mind. I will always think that public
> research and commercial research have different goals...

	Of course they do, because they differ in their funding models.
Generally, public institutions can be more long sighted than commercial
ones, whereas commercial ones have more dynamic growth patterns and
so must be more short-sighted.

	However, one should be rightly annoyed at larger corporations,
since they rival public institutions in size and stability, but seem
still
to lack the capacity for long term research. And perhaps this is partly
the fault of the public institutions for remaining too aloof from
the commerical world.

	I believe this creates a tension in which the commercial players
put pressure on public institutions (like ISO, academia), for a more
'commerical' approach. And perhaps one could ask how to best direct
pressure on those companies, to take a more long sighted view in return,
and work with the public intitutions better in the area of research.

	The only way I know how to do this is for those who see 
commerical merit in research to work in and for the commercial entities,
since they are organisations of people too. :-)

	To put this argument another way: we will do better to 
convince the commercial programmers of the world that the Ocaml way is
better if it is actually available on the platform they use to
implement commercial solutions. 

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] RE: OCaml on CLR/JVM?

[John Max Skaller]

Anton Moscal wrote:
> 
> On Fri, 9 Feb 2001, Don Syme wrote:
> 
> > Java/.NET component building seriously right from the start I feel you're
> > always just going to end up with a bit of a hack - an interesting, usable
> > hack perhaps, but not a really _good_ language.
> >
> > Probably the greatest recurring technical problem that I see in this kind of
> > work is that of type inference, and the way both the Java and .NET models
> > rely on both subtyping and overloading to help make APIs palatable.  Type
> > inference just doesn't work well with either subtyping or oveloading.  This
> > is a great, great shame, as it's obviously one of the main things ML has to
> > offer to improve productivity.
> 
> I think, subtyping probably isn't serious problem: O'Caml already have
> subtyping relations (between objects and also between variant types).


> I think, there is more serious problem:
> 
> O'Caml have structural subtyping relation between objects, whereas .NET
> type system have subtyping relation based on explicitly declared
> inheritance:

> ----------------------
> class point1 (x:int) = object method x = x end
> class point2 (x:float) (y:float) = object method x = x method y = y end
> 
> let get_x p = p#x
> 
> let _ = Printf.printf "%d\n" (get_x (new point1 1))
> let _ = Printf.printf "%g\n" (get_x (new point2 10.0 20.0))
> ----------------------
> 
> function get_x has type <x: 'a; ..> -> 'a and can works with the any
> object, which have method "x". I see no ways to map this into .NET
> framework except using reflection (which is overkill).
  
> Also, point2 is subtype of point1, but there isn't explicit
> inheritance declaration here. Moreover point1 and point2 can be defined
> in independent modules and don't know each other.

	The converse problem is to reflect the C++ signature matching
in Ocaml, which may be required to access C++ libraries. 

	1. 'Const' is probably impossible to model in the Ocaml type system,
		(does .NET support that?)
	2. multiple inheritance may be possible with polymorphic variants
		(?)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: OCaml on CLR/JVM?

[Sven LUTHER]

On Wed, Feb 14, 2001 at 08:30:51PM +0100, Xavier Leroy wrote:
> > To look at it another way, OCaml already shares a platform with C
> > (at least with the native-code compiler), so all the C libraries are
> > already available.  Yet it can still be a lot of effort to link with
> > a C library.  Why should Java and .NET be any easier?
> 
> In short, because it is possible to automate fully the generation of
> stub code for interfacing with Java or .NET, while this is not
> possible in C.  To generate stub code, you need to know quite a lot
> about the library you're interfacing with: 
> - types of function arguments and results, and of data structure members;

This can be automated by a basic parser tool, isn't it ?

This is what i started to do with c2caml, but i have no time to continue work
on it.

> - memory protocol (who frees dynamically-allocated memory and when?)

More difficult, C has no standard way of doing this, but often libraries have
a standard way of handling this.

> - error reporting protocol (e.g. return "impossible" results, or
>     longjmp() somewhere, or call a user-provided error callback, or ...)

Same as above ...

> For C, most of this information is implicit or written down in English
> only.  E.g. the function prototypes you find in .h files are wholly
> inadequate to generate stub code because the C types are not
> informative enough: is "char **" an array of strings or a string

Yes, this is difficult, just the char * argument type can be a problem, since
it is not possible to know if it is a 0 terminated string or somethign else.

> result passed as an "out" parameter?  what about macros (they are in

Just expand them before analysing the code and writting the stubs. 

You could keep them, and have a special preprocessor that sees if it is
possible to use polymorphic functions instead, as it is often possible, but
for straight 1-1 stub writting, expansion is the right way of doing this.

> effect untyped)?  As for memory management and error reporting, the .h
> file doesn't say anything at all.  

Well, memory management is not easy to do. maybe the addition of a per
function manual intervention, or the fixing of a per .h file or per library
convention should help.

Going beyond that would need the analysis of the whole source code, which i
guess is feasible also (for open source projects), but a bit long and heavy.

That said, this apply only to pointer argument types, as the rest of them are
copied around.

Anyway, automatissing this kind of things would perhaps not gain you a lot for
the initial stub writing, since you have to provide some info at first to help
an automated tool, but once that is done, it would help a lot to keep track of
various versions of the same library.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] RE: OCaml on CLR/JVM?

[Fabrice Le Fessant]

In previous messages, I forgot to say that these mails are only
expressing my views and opinions, not those of the INRIA Institute,
nor those of the Cristal project (Ocaml developpers team), of which
I'm not a member.

- Fabrice

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] RE: OCaml on CLR/JVM?

[Fabrice Le Fessant]

Hi Don, 

  Thanks for your replies. Here are some more comments ...

>  > Is the .NET VM open source ? Which part is Microsoft-independent ?
>  
>  The MS implementation of the Common Language Runtime is not open source.
>  The Common Language Runtime, C# and aspects of the .NET Frameworks are being
>  standardized by ECMA.  If the standardization committees do their job, the
>  standards will be sufficient to allow others to implement a compatible CLR.

There is an HUGE difference between open source and standards. The
first one can always freely evolve, while being used freely by many
users. Standardized ones cannot evolve anymore, or need the company
agreement to be modified. Compatible software will always have to
follow the company new developments, and thus will never be truely
achieved. This is one of the -many- drawbacks of Java.

>  You'll be glad to know that MS and Microsoft Research has been doing what
>  you say for the last two years and has been porting difficult research
>  languages (e.g. ML and Haskell) to the CLR, and working with other academic
>  groups to help this kind of effort move beyond the "hack it up and get it
>  working" phase that characterises efforts to target langauges at new
>  platforms.  This has led to many improvements to the CLR, including a
>  proposal for the CLR to support polymorphism in the next release in order to
>  better support languages such as OCaml.

The problem is that .NET is a commercial product. So, the question is:
should we spend our time porting Ocaml to all new commercial VMs (not
only MS ones, of course) ? Even if we can find some way to share the
work, to standardize the interfaces, etc ... There will always be
someone who doesn't want to follow the standard, and wants to have its
own proprietary one. This was done by MS several times (COM vs CORBA,
CLR vs JVM, etc...)

Moreover, CLR was only designed as a concurrent of the Java
VM. Otherwise, why didn't Microsoft choose to port all his languages
to the Java VM (other languages did that) or modify the Java VM for
their needs ? (of course, you can't use the argument that Java was not
free, since this is not a problem, from your first point...)

One time again, commercial issues have dominated scientific
reasons. CLR has been released too early, and will be standardized too
early, while big problems are still remaining: no polymorphism,
object-oriented approach in the bytecode, ... This should have been
discussed first, not in the next version !

>  I hope this answers your questions (though I'm sure it won't change your
>  mind!)

Of course, it won't change my mind. I will always think that public
research and commercial research have different goals...

Regards,

- Fabrice

PS: Xavier, Pierre, please, don't vote me out !
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] RE: OCaml on CLR/JVM?

[Xavier Leroy]

> If you're compiling to bytecode you can
> also ensure more compatibilities of representations, e.g. make sure ML
> int64's are exactly representationally equivalent to C's int64s.  Note if
> you don't compile to a bytecode then you even have to marshal integers
> across the interop boundary in Caml, though this could be automated.

The point I'd like to argue is that compiling to bytecode doesn't
guarantee that Caml's int64's (or any other data structure) are
representationally equivalent to C's int64s.

What you're describing is the favorable case where the source language
can be compiled to bytecode with a "natural mapping" (little or no
encoding at all) of the data types and data structures.  This is
indeed a boon for interoperability: data doesn't need to be marshalled
across language boundaries, objects can be physically shared, funny
things like cross-language class inheritance become possible, etc.

But: this can be impossible to achieve if the source language doesn't
fit the assumptions of the target virtual machine.  This is what
happens with Caml and .NET (or the JVM, for that matter).

Parametric polymorphism is the most well-known issue (.NET and the JVM
support only object-based subtyping polymorphism, meaning that a
method cannot operate both on objects and on integers or floats).
Your work on building parametric polymorphism on top of .NET (an
amazing feat of engineering, by the way) shows that this can be
overcome.

But what about other nasty features of Caml?  E.g. functors, row
polymorphism on objects, the Caml class system?  None of these map
naturally to the .NET intermediate language.  I estimate that a
"natural mapping" of these features would require two or three more
"tour de force" of the kind you did with parametric polymorphism...

(I can make these statements with some confidence, since at INRIA Bruno
Pagano spent one whole year, with significant input from Luc Maranget
and I, struggling with these issues.)

So, when the source language isn't quite what the VM designers had in
mind, the "natural mapping" doesn't work and one has to revert to
encodings of data structures.  For instance, integers and floats may
have to be boxed (wrapped inside an object) most of the time.
Source-level objects may have to be mapped to VM objects that manage
themselves their own vtable of methods, bypassing that of the VM.
Source-level classes map to even more complicated encodings.  (I'm
describing what Bruno Pagano did here.)  Etc.

All this can be made to work, and Bruno managed to do it.  But
it totally misses the point of interoperability: since your data
structures are not represented "like everyone else's", conversions are
again required at language boundaries, thus losing most of the
benefits of the .NET approach: no cross-language sharing of objects or
inheritance; need to generate the conversion code at boundary points;
etc.

And if one has to convert the data structures at boundaries anyway,
why bother generating VM code?  (And putting up with all the issues
that Bruno had to deal with.)  Why not just keep the existing
Caml implementation, which already manages its own things quite well,
thank you, and call into the JVM or the .NET machine (via a
foreign-function interface) for cross-language calls?  Conversion stub
code still needs to be generated, but is not much more complex than if
we were already in the VM, and the other problems just go away!

At the very least, I think one should understand the conversion issues
*before* embarking on generating VM code.  The opposite approach of
what we did with Bruno :-)  Using the foreign-function interface
approach allows to test the conversion issues first.

> While at a certain level I like Xavier's approach, i.e. maintaining two
> runtimes, garbage collectors etc., I have troubles seeing it scaling to the
> multi-language component programming envisioned as part of .NET approach
> (and indeed currently in practice with C#, C++, VB.NET and other .NET
> langauges).  Two GC's are already trouble enough (performance might suck as
> they will both be tuned to fill up the cache), but if you have components  
> from 10 languages in one process?  10 GCs competing for attention?

Why not?  When you have 10 functions in your program, they are already
competing for the attention of the cache.  From a hardware standpoint,
10 GCs are just 10 functions :-)  

More seriously, I agree that there is certainly a performance penalty
on cross-language calls.  But there is a performance gain on
inter-language calls: the Caml code can run at full speed, without
paying the price of the data encodings into someone else's ideas of
"primitive" data structures.  And most of the libraries we're
interested with do quite a lot of work on most calls (think GUIs,
Fortran numerical libraries, or database interfaces).  A serious
performance investigation of the two approaches would be very
interesting indeed.

> Maybe it
> can be made to work, but there's a certain conceptual clarity in just
> accepting that a GC should form part of the computing infrastructure, and
> share that service.  These are the aspects of the .NET approach that I find
> quite compelling.

And these are the aspects that frighten me :-)  I think GC's are
"haute couture": tailor-made clothing, hand-fitted on the body of the
customer... err, I meant, the source language.  .NET is
"prêt-à-porter": mass-produced, one-size-fits all clothes.  It might fit
many customers, but probably not all, or not all well.  

(At this point of the discussion, readers might find it useful to
picture themselves a regular Saharian camel wearing a pair of Levis'
and a Gap baggy sweatshirt, and trying to get its four hooves into a
pair of brand-new Nike :-)

> As an aside, I think it would be an interesting question to say "OK, let's
> take it for granted that the end purpose of our language is to produce
> components whose interface is expressed in terms of the Java or .NET type  
> systems, but which retains as many of the features and conceptual simplicity
> of OCaml and ML as possible."  I'm not sure exactly what you'd end up with,
> but whatever it was it could be the language to take over from C# and/or
> Java (if that's what you're interested in...)  But without really taking 
> Java/.NET component building seriously right from the start I feel you're
> always just going to end up with a bit of a hack - an interesting, usable
> hack perhaps, but not a really _good_ language.

This is one direction for research; the MLj folks, for instance,
started to do something like this, lifting Java classes and objects as
straightforwardly as possible into SML.

However, it is also a bit frightening, as evidenced by Fabrice Le
Fessant's inflammatory reply, because it means that all languages will
start to look more and more the same: object-oriented, class-based,
single inheritance with multiple interfaces -- Java clones, in short.

Actually, we already see some evidence of this in the .NET world: C# is C++
mixed with Java; the new Visual Basic is the old Visual Basic with a
solid dash of Java in it; etc.  My mental picture of .NET is a
vortex with Java at the center and all .NET languages spiraling around
it and getting closer and closer to the center...

One could argue that it is actually beneficial to the programmers that
all languages share a basic model, thus interoperating well; then
each language can have some added value in other areas.  But I don't
feel this appealing from a language designer's point of view.  I feel we
researchers in this area have a duty to promote more diversity.  But
cynics could say that we think so because we feel our jobs being
threatened :-)

I think I should stop here and not even mention the "Windows only"
controversy around .NET.  Dang!  I did it!  Briefly, then: the Caml
party line is that we've supported Unix and Windows (and a few others)
for almost 10 years now, and are commited to continue doing this in
the future.  If Microsoft shows similar commitments for .NET, that is
great; if not, that is a real show-stopper.

Apologies for this long rant.

Cheers,

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Re: OCaml on CLR/JVM?

[Xavier Leroy]

> [The MALI memory system.]  I would be interested to know the solution
> you applied to this issue.

Currently, none: the cycle is never deallocated.  But thanks for the
interesting references.

> Of pure curiosity, why is it so difficult to map Java to Caml objects?

There are a zillion sources of mismatches; some are easy to solve,
some not so.  For instance:

- Static overloading: Java has it, Caml doesn't.  So what do you do
  when your Java class has several definitions of method m,
  distinguished only by their argument types?  My current solution is to 
  have distinct methods on the Caml side, named m, m', m'', m'3, m'4, etc.
  (Thanks God, the quote is not valid in Java identifiers!)  Of course
  this sucks because the programmer has to refer to an automatically-generated
  documentation to find the Caml name of a Java method used at a particular
  type.

- Type equivalence and subtyping policy: Java is by name, Caml is by
  structure.  Actually not a big deal, since abstract data types in
  Caml can be used in creative ways to simulate Java's by-name behavior.

- "null" objects: any Java object reference can be "null"; Caml
  objects are never "null".  One can map Java object references to
  a Caml "option" type, but this is quite heavy-handed on the Caml
  client side.  My current solution is to map a Java "null" to special
  Caml objects that raise exceptions whenever one of their methods is called.

- Publically-accessible fields: in Java, fields are accessible from
  the outside of an object; in Caml, only the object's methods can see them.
  Moreover, the Caml object is distinct from the Java object: it just
  delegates its methods to the Java object.  Solution: map Java fields
  to get/set methods on the Caml side.  In the reverse direction,
  it's harder: basically, a Caml object can only implement a Java interface
  (only methods, no fields).

- Recursion between classes: in Java, classes can be arbitrarily recursive,
  even across packages.  And they are: for instance, java.lang.Object
  (the root of the Java class hierarchy) is actually mutually
  recursive with about 20 classes spanning 4-5 packages!  In Caml,
  only classes defined simultaneously in the same module can refer
  recursively to each other.  This is my current show-stopper.
  The initial approach was to map a Java package to one Caml module,
  allowing inter-package recursion, but not cross-package recursion.
  But that is not enough!  One actually needs to do a "connected
  components" analysis on the Java classes, map each component to
  a Caml module, then re-assemble the modules per-package in order
  to give a nice user view...

In summary: it's hard.  But stay tuned for further news.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Re: OCaml on CLR/JVM?

[Xavier Leroy]

> To look at it another way, OCaml already shares a platform with C
> (at least with the native-code compiler), so all the C libraries are
> already available.  Yet it can still be a lot of effort to link with
> a C library.  Why should Java and .NET be any easier?

In short, because it is possible to automate fully the generation of
stub code for interfacing with Java or .NET, while this is not
possible in C.  To generate stub code, you need to know quite a lot
about the library you're interfacing with: 
- types of function arguments and results, and of data structure members;
- memory protocol (who frees dynamically-allocated memory and when?)
- error reporting protocol (e.g. return "impossible" results, or
    longjmp() somewhere, or call a user-provided error callback, or ...)

For C, most of this information is implicit or written down in English
only.  E.g. the function prototypes you find in .h files are wholly
inadequate to generate stub code because the C types are not
informative enough: is "char **" an array of strings or a string
result passed as an "out" parameter?  what about macros (they are in
effect untyped)?  As for memory management and error reporting, the .h
file doesn't say anything at all.  

So, interfacing with a C library requires quite a lot of manual
intervention to supply the missing info.  This can take the form of
writing the stubs entirely by hand, or writing a higher-level
description of the library interface in an IDL-like interface from
which the stubs can be generated automatically.  The latter means less
typing, but is not actually significantly easier: the programmer still
has to get the intended behavior from the English documentation, and
then shape it into an IDL file that the stub generator will
understand.

Interfacing with Java or .NET is a completely different story:
- Libraries always come with detailed type annotations (descriptors
  in Java .class files; metadata in .NET) that are high-level enough
  to support the automatic generation of stub code.
- These systems are garbage-collected, so there is no concern about
  manual deallocation.
- These systems have built-in exceptions, which most libraries use
  consistently to report errors.

So, the goal of generating stub code entirely automatically can be
achieved with Java or .NET, but not with C.  (Or so I hope; we'll see
how it goes.)

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] RE: OCaml on CLR/JVM?

[Anton Moscal]

On Fri, 9 Feb 2001, Don Syme wrote:

> Java/.NET component building seriously right from the start I feel you're
> always just going to end up with a bit of a hack - an interesting, usable
> hack perhaps, but not a really _good_ language.
> 
> Probably the greatest recurring technical problem that I see in this kind of
> work is that of type inference, and the way both the Java and .NET models
> rely on both subtyping and overloading to help make APIs palatable.  Type
> inference just doesn't work well with either subtyping or oveloading.  This
> is a great, great shame, as it's obviously one of the main things ML has to
> offer to improve productivity.  

I think, subtyping probably isn't serious problem: O'Caml already have
subtyping relations (between objects and also between variant types). And
only problem arisen is necessity of the explicit type specification in
some constructions.

O'Caml haven't overloading, but probably overloading can be implemented
in the same way as subtyping: by requirement of the explicit type
specifications in case of ambiguities (SML have some builtin
overloaded operators and resolve emerging problems in this way).

I think, there is more serious problem:

O'Caml have structural subtyping relation between objects, whereas .NET
type system have subtyping relation based on explicitly declared 
inheritance:

----------------------
class point1 (x:int) = object method x = x end 
class point2 (x:float) (y:float) = object method x = x method y = y end

let get_x p = p#x 

let _ = Printf.printf "%d\n" (get_x (new point1 1)) 
let _ = Printf.printf "%g\n" (get_x (new point2 10.0 20.0))
----------------------

function get_x has type <x: 'a; ..> -> 'a and can works with the any
object, which have method "x". I see no ways to map this into .NET
framework except using reflection (which is overkill). 

Also, point2 is subtype of point1, but there isn't explicit
inheritance declaration here. Moreover point1 and point2 can be defined
in independent modules and don't know each other.

Anton
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] RE: OCaml on CLR/JVM?

[Don Syme]

Hi Fabrice,

I will attempt to answer your questions without becoming involved in a flame
war.  Please let me start by saying that I believe that OCaml is a fantastic
language and has a good chance of becoming a very significant (even the
leading) programming language amongst the open source community.  And being
an OCaml fan I think this would be a great thing.

> Is the .NET VM open source ? Which part is Microsoft-independent ?

The MS implementation of the Common Language Runtime is not open source.
The Common Language Runtime, C# and aspects of the .NET Frameworks are being
standardized by ECMA.  If the standardization committees do their job, the
standards will be sufficient to allow others to implement a compatible CLR.

> Ocaml is not a _hack_, as I have read in some recent mails, but a
> _good_ independent language.

I did not call OCaml a hack - and I never would!!  Please read my email
again.  I was referring to existing extensions to ML and other languages for
JVM or .NET interoperability (and I even regret saying that, as I only
wished to imply that syntactically they felt "added on" to the language,
which is hardly surprising at all).  OCaml itself is a wonderful, elegant
language.

I have to add that the OCaml backends are wonderful, and I know it would be
hard to produce a CLR-based backend that could really be as fast for
existing OCaml programs.  So I would not suggest that OCaml switch to using
the CLR as its primary backend.   However there are problems with the
existing backend, the complexity of implementing interoperability being one
of them.

> It should not change to follow a
> commercial standart, which will itself change for commercial
> reasons, as soon as the market is captured ...

No one has suggested changing OCaml.  Of course, balancing the "purity" of a
language against interoperability requirements is always difficult, and, for
example, I wouldn't be surprised if proposals appear from Xavier's work to
help ease the complexity of writing code to interoperate.  The would, I'm
sure, be tools and/or extensions and not breaking changes.

> If Microsoft wants its new product to be used, it is Microsoft problem
> to port more languages to its VM, and not only say: "We have ported
> our homemade languages to it (C#, C++, VB.NET) [because it was
> designed for them], so, you see, we have proved it's the universal
> VM. Now, do the same for your languages, or your language will not be
> used anymore by our customers..."

You'll be glad to know that MS and Microsoft Research has been doing what
you say for the last two years and has been porting difficult research
languages (e.g. ML and Haskell) to the CLR, and working with other academic
groups to help this kind of effort move beyond the "hack it up and get it
working" phase that characterises efforts to target langauges at new
platforms.  This has led to many improvements to the CLR, including a
proposal for the CLR to support polymorphism in the next release in order to
better support languages such as OCaml.

> So, why do we really need a .NET port of OCaml ? OCaml is
> working fine on
> Windows, and on many other OS ...

To me, this thread is about how to access JVM and .NET libraries from OCaml,
which many perceive as a real and substantial problem.  Compiling down to
MS-IL is one way to achieve this relatively easily for .NET libraries - as
Xavier says it is neither necessary nor sufficient to do this, but it sure
makes interoperability far, far easier to implement.  I have been careful to
point out it is not the only way - for example Xavier's multi-garbage
collector approach also makes a lot of sense in many situations.

I hope this answers your questions (though I'm sure it won't change your
mind!)

Yours,
Don Syme
Microsoft Research, Cambridge
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr