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

[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

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

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?

[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?

[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

[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?

[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

[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?

[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

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: OCaml on CLR/JVM?

[Don Syme]

> > 
> > > Now I have to say the obvious: wouldn't it be wonderful if Caml
interfaced
> > > with either Java or the .NET Common Language Runtime seamlessly so we
> > > wouldn't have to keep facing these kinds of questions and problems,
and
> > > could just leverage existing libraries?   
> 
> Although this view is understandable, I think it is rather naive.  

Well, I didn't exactly propose a technical solution...  

Of course there's hard work to be done to realise this vision, but in
principle a clean interop story sure beats the endless rehashing of other
people's code in language X as a library in language Y.  Myself and others
involved in the Microsoft Project 7 are working on one approach to achieve
this interop, i.e. compiling languages directly to .NET MS-IL, in the style
of MLj, often adding extensions to the language in order to improve the
interop.  We are also working on improving the .NET infrastructure,
proposing support for features such as parametric polymorphism in MS-IL.  

Xavier is also working on a solution for OCaml, as he mentioned, though the
problem of how to reflect the constructs of an object model into ML, Haskell
or OCaml remains similar whichever approach you take to actually running the
stuff.

> 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?  Also, look at the effort that went into
making
> an ML/Java system with MLj.

There are several reasons why it is easier: exceptions, for example, can be
propogated across the interop boundary, without any effort at all if you
compile to MS-IL of Java bytecode.  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.

You can also transfer objects more consistently, as the semantics of the
object models of Java and .NET are fairly simple in contrast to C, e.g. no
need to have an IDL to help interpret pointers as "in-out", "in", "out"
parameters.

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?  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.

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.

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.  

Cheers,
Don

P.S. As for threads - I don't think the story is half as bad as you might
think.  After all, OCaml threads map down to Windows threads at some point,
and I just don't see that there are that many special logical properties of
typical ML and Caml threading libraries that make it semantically ridiculous
to share threads between languages (though it is true asynchronous
exceptions can make things hard when compiling to a bytecode).  But I'll
admit I'm not an expert on this.

[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

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: OCaml on CLR/JVM?

[Dave Berry]

> From: Xavier Leroy [mailto:Xavier.Leroy@inria.fr]
> 
> > Now I have to say the obvious: wouldn't it be wonderful if Caml
interfaced
> > with either Java or the .NET Common Language Runtime seamlessly so we
> > wouldn't have to keep facing these kinds of questions and problems, and
> > could just leverage existing libraries?   

Although this view is understandable, I think it is rather naive.  As Xavier
said:

> One thing I learnt is that the real problem with language
> interoperability is not how to compile language X to virtual machine Y
> (this can always be done, albeit more or less efficiently), but rather
> how to map between X's data structures and objects and those of all
> other languages Z1 ... Zn that also compile down to Y.  

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?  Also, look at the effort that went into making
an ML/Java system with MLj.

(To be fair, I've never tried linking OCaml to C myself; I'm only judging
the
difficulty by traffic on this mailing list.  It seems to be simpler than
many
other ML compilers, but still with potential pitfalls). 

Threads are another area of potential problems.  In fact they can be a total
minefield.  

Xavier also wrote:
> These Haskell guys sure are
> at the bleeding edge of language interoperability. 

I don't entirely agree with this -- they may be at the leading edge of
publicly
documented implementations, but I know of commercial Lisp and Dylan
implementations
that are notably more sophisticated.  Unfortunately the techniques that
those
implementations use are proprietary, so I guess this doesn't have much
practical
impact for anyone else.

That said, I was pleased (if a little envious) when the Haskell people
successfully
published some papers about foreign-language interfaces.  I had rather
assumed that the
academic community wouldn't be interested in such mundane engineering
issues.
I did notice that some of the papers still used greek letters and
denotational
semantic-style equations to describe a fairly straightforward translation -
perhaps
these softened the blow to the readers?  ;-)  (I hope this doesn't sound
harsh; I 
intend it mainly in jest). 

[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

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

OCaml on CLR/JVM? (RE: OCaml <--> ODBC/SQL Server)

[Don Syme]

Now I have to say the obvious: wouldn't it be wonderful if Caml interfaced
with either Java or the .NET Common Language Runtime seemlessly so we
wouldn't have to keep facing these kinds of questions and problems, and
could just leverage existing libraries?   

I'm very interested to know if there are people with some time to spare who
would be keen to work with me toward a .NET version of OCaml.  I've talked
this over from time to time with Xavier, and have done a lot of foundational
work for the core language when building a .NET compiler for Haskell.  If
you think would be interested, or would simply like to join a mailing list
devoted to talking about getting Caml running and interoperating on .NET,
then please let me know!

Cheers,
Don Syme


------------------------------------------------------------------------
At the lab:                                     
Microsoft Research Cambridge                  
St George House                             
Cambridge, CB2 3NH, UK
Ph: +44 (0) 1223 744797                        
http://research.microsoft.com/users/dsyme
email: dsyme@microsoft.com
------------------------------------------------------------------------




-----Original Message-----
From: Vincent Leleu [mailto:me@vleleu.com]
Sent: 05 February 2001 08:52
To: caml-list@inria.fr
Subject: OCaml <--> ODBC/SQL Server


*** Version Francaise a la fin ***

Hello,

I'd like to use OCaml as a CGI scripting language that process forms AND
especially query a SQL Server DB (7.0 or 2000).
I came across a library to easily manage the CGI forms & query strings in
OCaml. This is no probs.

What I cannot find around is a way to easily interrogate and interface in
OCaml with an ODBC data source OR a direct way to send/receive queries
from/to the DB.

If anyone has any idea or even a little clue on where to go, any comment is
welcome.

Thanks a lot

*******

Bonjour,

J'aimerais utiliser OCaml comme language acteur de script CGI qui traiterait
les 'forms' ET surtout interrogerait une base de donnee SQL Server 7.0 ou
2000.
J'ai pu trouver une bibliotheque afin de gerer facilement les forms CGI et
ligne de parametres URL. Pas de probleme avec ca.

Ce que je ne trouve pas est une solution pour facilement interroger et
communiquer d'OCaml avec une source de donnees ODBC OU directement une facon
d'envoyer/recevoir les requetes/donnees vers/de la base de donnees.

Si vous avez la plus petite idee ou piste a me communiquer, tout commentaire
sera le bien venu.

Merci enormement


Vincent Leleu
---
AB Productions
105-A Devonshire Sq.
Jackson, TN 38305
US
---

Re: OCaml on CLR/JVM?

[Xavier Leroy]

> Now I have to say the obvious: wouldn't it be wonderful if Caml interfaced
> with either Java or the .NET Common Language Runtime seemlessly so we
> wouldn't have to keep facing these kinds of questions and problems, and
> could just leverage existing libraries?   

I've been working on and off (mostly off, lately) on an OCaml/Java
interface that works by coupling the two systems at the C level via
their foreign-function interfaces (Java's JNI and OCaml's C
interface).  This was strongly inspired by the work of Erik Meijer et
al on a similar Haskell/Java interface.  (These Haskell guys sure are
at the bleeding edge of language interoperability.  This is the second
interop idea I steal from them, after the IDL/COM binding.)

The low-level coupling is surprisingly easy, including making the two
garbage collectors cooperate: both the JNI and OCaml's C interface
provide enough functionality to get the couping to work without *any*
modification on either of the implementations.  How nice!
The only limitation is that a cross-heap cycle (a Java object pointing
to a Caml block pointing back to the Java object) can never be
reclaimed... (Thanks to Martin Odersky for pointing this out.)

(Actually, the main problem is working around the bugs in Sun's JDK
1.2.2 for Linux.  These guys must be kidding.  Does anyone has a
recommendation for a solid, complete Java implementation (including
Java 2 and of course the JNI) for Linux?)

Of course, the low-level interface is type-unsafe, so the real fun is
to build a type-safe view of Java classes and objects as Caml classes
and objects, and conversely.  I'm still struggling with some of the
issues involved.  For instance, it turns out to be much simpler (for
the implementation, not for the final user!) to map Java objects to
values of abstract Caml types, and treat methods as functions over
these abstract types, than mapping Java objects to Caml objects.  That
was quite unexpected!

One thing I learnt is that the real problem with language
interoperability is not how to compile language X to virtual machine Y
(this can always be done, albeit more or less efficiently), but rather
how to map between X's data structures and objects and those of all
other languages Z1 ... Zn that also compile down to Y.  This is obvious
in retrospect, but I think many (myself included) often overlook this
point and believe that compiling to the same virtual machine is
necessary and sufficient for interoperability.  It is actually neither
necessary nor sufficient...

While this work started with the JVM, I'm pretty sure it can be made
to work with the .NET CLR, as soon as it will have a foreign-function
interface with features comparable to those of the JNI.  (And I'm sure
this will happen eventually, not only because it makes sense, but also
because Java has it, so .NET must too :-)

Stay tuned for further developments.

- Xavier Leroy

Re: OCaml on CLR/JVM?

[David Mentre]

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

[ about Caml and Java GC cooperation ]
> The only limitation is that a cross-heap cycle (a Java object pointing
> to a Caml block pointing back to the Java object) can never be
> reclaimed... (Thanks to Martin Odersky for pointing this out.)

Regarding GC cooperation, some work has been done on the MALI memory
system [Bekkers86-0:confs]. As Olivier Ridoux explained to me and as far
as I remember, they consider 4 kinds of pointer, some of them to let
garbage reclamation be done latter by the other GC. However, I don't
know if their scheme would solve your inter-GC cycle reclamation. Maybe
you should ask Olivier.Ridoux@irisa.fr directly.

I would be interested to know the solution you applied to this issue. 

>  it turns out to be much simpler (for the implementation, not for the
> final user!) to map Java objects to values of abstract Caml types, and
> treat methods as functions over these abstract types, than mapping
> Java objects to Caml objects.  That was quite unexpected!

Of pure curiosity, why is it so difficult to map Java to Caml objects?
Is it the way control flow evolves between object methods that is
different? Is the typing of OCaml constraining too much the kind of
programs that can be written compared to Java?


Best regards,
d.


@InProceedings{Bekkers86-0:confs,
  author =       "Y. Bekkers and B. Canet and O. Ridoux and L. Ungaro",
  title =        "{MALI}: {A} Memory with a Real-time Garbage Collector
                 for Implementing Logic Programming Languages",
  booktitle =    "Proceedings of the International Symposium on Logic
                 Programming",
  organization = "IEEE Computer Society,",
  year =         "1986",
  month =        sep,
  publisher =    "The Computer Society Press",
  pages =        "258--265",
  ISBN =         "0-8186-0728-9",
}

There is also a "Publication interne" #611, IRISA, 1991, by Olivier
Ridoux : ftp://ftp.irisa.fr/local/lande/or-tr-irisa611-91.ps.Z

-- 
 David.Mentre@inria.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.

[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