[Caml-list] Alternative Bytecodes for OCaml

[Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

Hello,

I come to OCaml from a Python background, and one of the most 
interesting bits of technology for Python is Jython[1].  Jython is a 
pure Java implementation of the Python interpreter and native-code 
libraries.  It allows Python programs to run unmodified in a Java 
environment.  More powerfully, though, Python programs can use Java 
classes as if they were native classes.  No glue code is required for 
this; it Just Works.  To a somewhat more limited extent, Python classes 
can also be made available to Java classes.  This makes Python an 
interesting choice to add more dynamic capabilities to Java code, and 
it expands the set of available libraries to Python programs to include 
anything available for Java.  I've used these capabilities for several 
purposes -- one of the more recent is the zxJDBC module, which exposes 
a Python DB-API interface to any database that has a JDBC 
implementation.

One of my continuing complains about OCaml is the breadth of libraries 
available for it.  It is getting better thanks to the hard work of 
many, but IMHO, still lags behind Python, Perl, and Java.

So one of the things I've been thinking about lately is integrating 
OCaml with either Java or the .NET CLI in a manner similar to Jython.  
I've done some googling on the topic and it seems nobody is working on 
this yet.  I just wanted to check and see if that's true.

I see several possibilities with both of those paths:

 * An ocamlc/ocamlrun that execute under Java or .NET and compile/run 
normal OCaml bytecode

 * An ocamlopt-equivolent that would compile OCaml code directly to Java 
or .NET bytecode 

I have found a language called Nemerle[2] that seems to be very similar 
to OCaml, though with a different syntax.

[1] http://www.jython.org/
[2] http://nemerle.org/

Thanks!

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:
>  * An ocamlc/ocamlrun that execute under Java or .NET and compile/run 
> normal OCaml bytecode

This interesting project was posted on the Wiki yesterday.  It
generates code which runs on the .NET CLR.  I'm not exactly sure how,
whether it's a modified compiler, or a translator of OCaml bytecode:

http://www.pps.jussieu.fr/~montela/ocamil/

What will be interesting will be to see how well it allows one to call
.NET libraries, and how well it works on Mono.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
"One serious obstacle to the adoption of good programming languages is
the notion that everything has to be sacrificed for speed. In computer
languages as in life, speed kills." -- Mike Vanier

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 09:38 am, Richard Jones wrote:
> On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:
> >  * An ocamlc/ocamlrun that execute under Java or .NET and
> > compile/run normal OCaml bytecode
>
> This interesting project was posted on the Wiki yesterday.  It
> generates code which runs on the .NET CLR.  I'm not exactly sure how,
> whether it's a modified compiler, or a translator of OCaml bytecode:
>
> http://www.pps.jussieu.fr/~montela/ocamil/

That is indeed interesting.  It looks like they have a good start.  
Unfortunately, there's one huge problem: there is no source code at 
all.  (Doesn't that violate the OCaml license?)

They are working in a pure Windows environment and have yet to port some 
libraries such as Str and Unix.  These are both things I can help with, 
but without the source code, it's completely useless to me.

> What will be interesting will be to see how well it allows one to
> call .NET libraries, and how well it works on Mono.

Indeed.  (And how well it allows other .NET programs to call OCaml 
code.)

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

[ I'm CCing the people listed as contacts on the OCamil page; I hope you 
don't mind ]

On Wednesday 25 August 2004 09:50 am, John Goerzen wrote:
> On Wednesday 25 August 2004 09:38 am, Richard Jones wrote:
> > On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:
> > >  * An ocamlc/ocamlrun that execute under Java or .NET and
> > > compile/run normal OCaml bytecode
> >
> > This interesting project was posted on the Wiki yesterday.  It
> > generates code which runs on the .NET CLR.  I'm not exactly sure
> > how, whether it's a modified compiler, or a translator of OCaml
> > bytecode:
> >
> > http://www.pps.jussieu.fr/~montela/ocamil/
>
> That is indeed interesting.  It looks like they have a good start.
> Unfortunately, there's one huge problem: there is no source code at
> all.  (Doesn't that violate the OCaml license?)

This is a very important point, BTW.

I have been able to take their binaries and see at least something 
happen with Mono:

$ mono ocamiltop.exe

** ERROR **: Invalid IL code at IL0096 in Nativeint.Top:start (): 
IL_0096: shl

Well, it's a start.  With source, I could probably do a lot more.

> They are working in a pure Windows environment and have yet to port
> some libraries such as Str and Unix.  These are both things I can
> help with, but without the source code, it's completely useless to
> me.
>
> > What will be interesting will be to see how well it allows one to
> > call .NET libraries, and how well it works on Mono.
>
> Indeed.  (And how well it allows other .NET programs to call OCaml
> code.)
>
> -- John
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
> http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs
> FAQ: http://caml.inria.fr/FAQ/ Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Raphael Montelatici]

Hi all,
Here are some explanations on OcamIL.
OcamIL compiles Ocaml programs to verifiable MSIL bytecode.
I  have not advertised at all about it so far because I still consider it is
not mature yet.

Some implementation details:
OcamIL is a modified ocamlopt compiler. Modifications are made as late as
possible in order to achieve maximum compatibility with ocamlc/opt. One big
issue is the compilation of an untyped intermediate language to a typed
runtime.

Two tracks have been followed : 1) type reconstruction and 2) type
propagation
1) The current OcamIL distribution relies on the first approach. It gives
enough good results to allow to bootstrap OCamIL and build an Ocaml
toplevel for .NET. Interoperability with C# has been successfully tested.
2) However, it leads to unadequate data representations that entail poor
performance. I'm currently working on the second approach.
This involves a lot of code restructuration. Source files (as a patch to
ocaml sources) together with a correct license will appear in the next
release (expected late october ?)

About interoperability:
We do not want to add weird FFI features to the Ocaml syntax. We prefer an
IDL approach, inspired by what have been done for Caml and Java by the
OJacare project ( http://www.pps.jussieu.fr/~henry/ojacare/index.en.html ).

About mono:
OcamIL is developped and tested on windows, but I'm willing to make it
compatible with Mono.
However, mono still lacks .NET compatibility. OcamIL relies on parts of the
Reflection library that are not available yet.
Moreover, the mono bytecode interpreters behaves strangely: some executables
produced by OcamIL don't run in the bytecode interpreter, but do run when
previously compiled by the mono bytecode-to-nativecode compiler.
Please Mono users wait for the next OcamIL release, which will be announced
on this list.

Raphael Montelatici





----- Original Message ----- 
From: "John Goerzen" <jgoerzen@complete.org>
To: <caml-list@inria.fr>
Cc: <Emmanuel.Chailloux@pps.jussieu.fr>;
<Raphael.Montelatici@pps.jussieu.fr>
Sent: Wednesday, August 25, 2004 5:02 PM
Subject: Re: [Caml-list] Alternative Bytecodes for OCaml


> [ I'm CCing the people listed as contacts on the OCamil page; I hope you
> don't mind ]
>
> On Wednesday 25 August 2004 09:50 am, John Goerzen wrote:
> > On Wednesday 25 August 2004 09:38 am, Richard Jones wrote:
> > > On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:
> > > >  * An ocamlc/ocamlrun that execute under Java or .NET and
> > > > compile/run normal OCaml bytecode
> > >
> > > This interesting project was posted on the Wiki yesterday.  It
> > > generates code which runs on the .NET CLR.  I'm not exactly sure
> > > how, whether it's a modified compiler, or a translator of OCaml
> > > bytecode:
> > >
> > > http://www.pps.jussieu.fr/~montela/ocamil/
> >
> > That is indeed interesting.  It looks like they have a good start.
> > Unfortunately, there's one huge problem: there is no source code at
> > all.  (Doesn't that violate the OCaml license?)
>
> This is a very important point, BTW.
>
> I have been able to take their binaries and see at least something
> happen with Mono:
>
> $ mono ocamiltop.exe
>
> ** ERROR **: Invalid IL code at IL0096 in Nativeint.Top:start ():
> IL_0096: shl
>
> Well, it's a start.  With source, I could probably do a lot more.
>
> > They are working in a pure Windows environment and have yet to port
> > some libraries such as Str and Unix.  These are both things I can
> > help with, but without the source code, it's completely useless to
> > me.
> >
> > > What will be interesting will be to see how well it allows one to
> > > call .NET libraries, and how well it works on Mono.
> >
> > Indeed.  (And how well it allows other .NET programs to call OCaml
> > code.)
> >
> > -- John
> >
> > -------------------
> > To unsubscribe, mail caml-list-request@inria.fr Archives:
> > http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs
> > FAQ: http://caml.inria.fr/FAQ/ Beginner's list:
> > http://groups.yahoo.com/group/ocaml_beginners
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Thursday 26 August 2004 04:05 am, Raphael Montelatici wrote:

Hi Raphael,

> This involves a lot of code restructuration. Source files (as a patch
> to ocaml sources) together with a correct license will appear in the
> next release (expected late october ?)

I would be very pleased to see source files or CVS access as soon as 
it's possible.  I may be able to help out on this, and I suspect others 
may be able to do so also.

> About mono:
> OcamIL is developped and tested on windows, but I'm willing to make
> it compatible with Mono.

If you publish the source code, I'd be willing to look into it.

I'm also willing to host an Arch or Subversion repository for the 
project if that would be useful for you.  (Arch preferred!)

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Thursday 26 August 2004 08:20 am, John Goerzen wrote:
> > About mono:
> > OcamIL is developped and tested on windows, but I'm willing to make
> > it compatible with Mono.
>
> If you publish the source code, I'd be willing to look into it.

I also forgot to add that there is another Free .NET project: DotGNU 
Portable .NET.  Perhaps it will fare better than Mono in this regard.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Lars Nilsson]

On Wed, 25 Aug 2004 15:38:28 +0100, Richard Jones <rich@annexia.org> wrote:
> On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:
> >  * An ocamlc/ocamlrun that execute under Java or .NET and compile/run
> > normal OCaml bytecode
> 
> This interesting project was posted on the Wiki yesterday.  It
> generates code which runs on the .NET CLR.  I'm not exactly sure how,
> whether it's a modified compiler, or a translator of OCaml bytecode:
> 
> http://www.pps.jussieu.fr/~montela/ocamil/
> 
> What will be interesting will be to see how well it allows one to call
> .NET libraries, and how well it works on Mono.
> 
> Rich.

I guess one can always mention F# in this context.

http://research.microsoft.com/projects/ilx/fsharp.aspx

Regarding ocamil, I notice there is no source download option and the
binary distribution does not contain any license/copying file. Since
it is based on (L)GPL software, presumably this will be corrected as
soon as possible (at the very least include the license in the
distribution along with instructions on how to get the source).

Lars Nilsson

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Jason Smith]

> I guess one can always mention F# in this context.
>
> http://research.microsoft.com/projects/ilx/fsharp.aspx

Yes I was just going to bring that up. I'd be interested in knowing if they
target the same ILX instruction set that F# does. If not, I'd like to find
out there compilation model, e.g. how they deal with partial applications
etc..

Jason.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 10:06 am, Jason Smith wrote:
> > I guess one can always mention F# in this context.
> >
> > http://research.microsoft.com/projects/ilx/fsharp.aspx
>
> Yes I was just going to bring that up. I'd be interested in knowing
> if they target the same ILX instruction set that F# does. If not, I'd
> like to find out there compilation model, e.g. how they deal with
> partial applications etc..

I took a look at F#, but unfortunately its license means that it will be 
unusable for the stuff I'm working on.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 9:55 am, Lars Nilsson wrote:
>
> I guess one can always mention F# in this context.
>
> http://research.microsoft.com/projects/ilx/fsharp.aspx

Also, it appears there is a SML version for .NET:

http://www.cl.cam.ac.uk/Research/TSG/SMLNET/

-- 
John Goerzen
Auther, Foundations of Python Network Programming
http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Thu, 2004-08-26 at 00:26, John Goerzen wrote:

> I come to OCaml from a Python background, and one of the most 
> interesting bits of technology for Python is Jython[1].

Curious though why you'd want to... interfacing to C
I can understand. But why bother with the JVM or Java?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Lars Nilsson]

On 26 Aug 2004 01:05:45 +1000, skaller <skaller@users.sourceforge.net> wrote:
> On Thu, 2004-08-26 at 00:26, John Goerzen wrote:
> 
> > I come to OCaml from a Python background, and one of the most
> > interesting bits of technology for Python is Jython[1].
> 
> Curious though why you'd want to... interfacing to C
> I can understand. But why bother with the JVM or Java?

Gain [easy] access to Java libraries? Also, with Java possibly being
deployed more widely than Python (looking at users of software, not
developers). It might in some cases make sense to target the JVM
instead of requiring an installation of Python. This makes Scala[1] at
least mildly interesting if one wants to experiment with functional
programming and be able to deploy to a wide user-base. Some may also
be intrigued by compile once run everywhere (no need for anyone to
pick this statement to pieces).

Lars Nilsson

[1] http://scala.epfl.ch/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Jason Smith]

> > I come to OCaml from a Python background, and one of the most
> > interesting bits of technology for Python is Jython[1].
>
> Curious though why you'd want to... interfacing to C
> I can understand. But why bother with the JVM or Java?

Some possible reasons that suggest themselves:

1. You don't need to implement your own runtime environment, no more fussing
around with garbage collection etc..
2. You now can run python on every platform that supports a Java Virtual
Machine
3. More so with .NET then the JVM, because .NET specifically touts this as a
feature, but now u've got a standard type model from which you can interface
with any other language that compiles to it.

there are prob heaps of others...

Jason

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 10:22 am, Jason Smith wrote:
> > > I come to OCaml from a Python background, and one of the most
> > > interesting bits of technology for Python is Jython[1].
> >
> > Curious though why you'd want to... interfacing to C
> > I can understand. But why bother with the JVM or Java?
>
> Some possible reasons that suggest themselves:
>
> 1. You don't need to implement your own runtime environment, no more
> fussing around with garbage collection etc..
> 2. You now can run python on every platform that supports a Java
> Virtual Machine

Yes, this is a key benefit, and would apply to both Python and OCaml.

Let's say you've got an Python program and you'd like to make it easily 
runnable for as many people as possible.  You know that most of them 
have a JVM available.  So you could just distribute a .JAR file and 
poof -- instant app.  Runs on OS X, Windows, Linux, BSD, etc.

Now, s/Python/OCaml/ and perhaps s/JVM/.NET/.  You get the idea.

For OCaml developers, that means no compiling necessary for users.  No 
new environment installation.  An app can be, on Windows, 
double-click-and-run just like any other.

> 3. More so with .NET then the JVM, because .NET specifically touts
> this as a feature, but now u've got a standard type model from which
> you can interface with any other language that compiles to it.

And that is, in my mind, the key benefit.  I am just learning 
about .NET, so let's talk about Java first.

Java's type system is less rich than Python, but it is very strict and 
defined.  There are a few basic types (ints, arrays, etc.) that map 
directly into Python with no problem.  A few of the other types 
(Strings, etc.) map into Python with a little glue from Jython.  
Everything else is a class, which maps into Python with no problem at 
all.  Since every class method carries type information with it, Jython 
knows what is supposed to go in and what is supposed to come out.  In 
many cases, the whole process is completely transparent to the Python 
programmer as I demonstrated with my earlier message on the topic.

That means that, by running my Python code in Jython, I instantly get 
access to all the libraries available for Java, in addition to all the 
pure-Python libraries already out there for Python (most of them fall 
under that category).  I get all the features I like from Python, and 
can mix and match Java calls in with my code seamlessly.  I can access 
JDBC, Swing, Soap, Enhydra, whatever.  And I can still use my normal 
Python ftplib, os, sys, etc.

The best part is: NO GLUE.  That's the nasty part of interfacing to C.  
Output parameters, pointers, garbage collection, etc.  It's a lot of 
work.  There is no work to do that with Java.

Say I want to be able to create a .ZIP file from my OCaml program.  I 
could: 1) write a deflate algorithm and storage algorithm in OCaml; 2) 
develop an interface to some C library that does this (possibly taking 
almost as much time due to pointers, memory, and stuff); or 3) open 
java.util.zip.ZipFile and go to work.

(One interesting side-effect: Java enforces private methods at the 
compiler, not the bytecode, level.  Jython programs can actually access 
private Java class methods.)

And you're right, with .NET this benefit grows even more.  I can access 
not just Java stuff there, but also C#, some C++, Python, Perl, 
whatever else.  It's a lot to draw on, and no glue.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Jason Smith]

> And that is, in my mind, the key benefit.  I am just learning
> about .NET, so let's talk about Java first.

*snip cool python stuff*

> And you're right, with .NET this benefit grows even more.  I can access
> not just Java stuff there, but also C#, some C++, Python, Perl,
> whatever else.  It's a lot to draw on, and no glue.

Yes, I have little experience with python but I've written a functional
language compiler for .NET for the language Mondrian[1]. Expect a new
release soon, as soon I as I finish it with hopefully non-structural
subtyping and recursive types (website is a little behind the times).

In Mondrian I can bind to C# simply by doing:

invoke System.Random.Next(Integer) <obj instance>

At the moment you have to supply the parameter type because the original
implementation couldn't resolve overloadings, Integer is the return type.
Currying affords a form of dynamic binding here as I can delay supplying the
<obj instance> untill later in this case because Next does not expect a
argument the objc instance is the next argument bound. invoke uses the
reflection libraries to check if the object instance bound later is really
carrying a member with System.Random.Next defined on it. Obviously
realistically the only object carrying this method is going to be a instance
of System.Random but the idiom is easily extendable. If we are interested in
making sure we do not get any dynamic exceptions then we can constrain the
type variable bound to invoke with the constraint a <: { System.Random.Next
(Integer) }, so that we can check it statically.

Some immediate benefits over the JVM are an official release with support
for Generics, parameteric polymorphism is now directly expressible in byte
code and now *finally* we have contra/covariant delegate types which allows
me to express proper subtype semantics over function types (where functions
are passed using delegates, a natural homomorphism).

Incidentally the above syntax has been adopted by Hugs98.NET [2], mostly
because the original guy who worked on Mondrian, Eric Meijor, is development
lead for Hugs98.

Cheers, J.

[1] www.mondrian-script.org
[2] http://galois.com/~sof/hugs98.net/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Jason Smith]

> invoke System.Random.Next(Integer) <obj instance>

sorry, I was only half concentrating when I wrote this, in this case the
binding is:

invoke System.Random.Next() <obj instance>

Cheers, Jason.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Ville-Pertti Keinonen]

John Goerzen wrote:

>>2. You now can run python on every platform that supports a Java
>>Virtual Machine
>>    
>>
>
>Yes, this is a key benefit, and would apply to both Python and OCaml.
>
>Let's say you've got an Python program and you'd like to make it easily 
>runnable for as many people as possible.  You know that most of them 
>have a JVM available.  So you could just distribute a .JAR file and 
>poof -- instant app.  Runs on OS X, Windows, Linux, BSD, etc.
>
>Now, s/Python/OCaml/ and perhaps s/JVM/.NET/.  You get the idea.
>
Whaat?

I use far more platforms that don't have Java available (at least a 
decent version thereof) than platforms that don't support Python and OCaml.

In fact, name a single platform that has a complete, up-to-date Java 
implementation available but doesn't have Python or OCaml available.  
I'll name one that has Python and OCaml but not Java, which I'm using 
right now to write this - FreeBSD/amd64 (ok, an i386 FreeBSD native or 
Linux emulated JDK might work in compatibility mode, but Python and 
OCaml are both amd64 native on this machine).

The other reasons for targeting JVM or .NET are valid (I can add one - 
in the case of Python, getting a non-reference-counting garbage 
collector might be a significant advantage), but every time I hear 
someone arguing in favor of Java for portability, I think of the many 
times I've been able to natively compile all C programs I might need but 
have had to give up on using Java programs...

Sure, it may be that a JRE is already installed for most of your users, 
but this isn't really relevant when the alternative could be natively 
pre-compiled (having one distribution file for all architectures is a 
pretty minimal advantage), and I regularly run into programs written in 
Java that are platform-specific and are shipped with their own copy of a 
JRE...  Sometimes because of the specific version required, sometimes 
for no reason, sometimes because the official JREs have bugs that the 
vendor had to fix themselves to get their software to work.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Jason Smith]

> In fact, name a single platform that has a complete, up-to-date Java
> implementation available but doesn't have Python or OCaml available.

Do u consider a JVM supporting the Java 2 Platform Micro Edition a "complete
up-to-date Java" implementation?

If so, how many Ocmal ports exist for smart-cards, PDA's, cellular
telephones, VCR's etc...? As an example

http://www.mips.com/content/PressRoom/TechLibrary/Backgrounders/smartcard

smartcards support the JavaCard JVM.

Cheers, J.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 11:49 am, Ville-Pertti Keinonen wrote:
> John Goerzen wrote:
> Whaat?
>
> I use far more platforms that don't have Java available (at least a
> decent version thereof) than platforms that don't support Python and
> OCaml.

That is *NOT* what I said.  I didn't imply that the Python or OCaml 
support was not available.  I simply implied that it was not 
*INSTALLED*.

[ snip rest of red herring argument ]

> In fact, name a single platform that has a complete, up-to-date Java
> implementation available but doesn't have Python or OCaml available.
> I'll name one that has Python and OCaml but not Java, which I'm using
> right now to write this - FreeBSD/amd64 (ok, an i386 FreeBSD native
> or Linux emulated JDK might work in compatibility mode, but Python
> and OCaml are both amd64 native on this machine).

For my purposes, all of the following work fine:

 * kaffe
 * gij
 * gcj

At least two of those should be available for FreeBSD/amd64.

I rarely need Java features newer than 1.1.

> someone arguing in favor of Java for portability, I think of the many
> times I've been able to natively compile all C programs I might need
> but have had to give up on using Java programs...

You do make a valid point about the availability of JVMs implementing 
Java 1.3 or above.  I am not talking about that, though.

> Sure, it may be that a JRE is already installed for most of your
> users, but this isn't really relevant when the alternative could be
> natively pre-compiled (having one distribution file for all
> architectures is a pretty minimal advantage), and I regularly run

Speak for yourself.  I don't have 20 different machines from all sorts 
of different platforms that I'd like to support.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Thu, 2004-08-26 at 01:52, John Goerzen wrote:

> > 2. You now can run python on every platform that supports a Java
> > Virtual Machine
> 
> Yes, this is a key benefit, and would apply to both Python and OCaml.

Python probably runs on more platforms than Java.
I have Python -- and I don't have Java or any OS level JVM.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Brian Hurt]

On 26 Aug 2004, skaller wrote:

> On Thu, 2004-08-26 at 00:26, John Goerzen wrote:
> 
> > I come to OCaml from a Python background, and one of the most 
> > interesting bits of technology for Python is Jython[1].
> 
> Curious though why you'd want to... interfacing to C
> I can understand. But why bother with the JVM or Java?
> 

Better interfacing with other Java components.  I know of at least one 
programmer who is currently using Jython, who would love to switch over to 
Ocaml- but can't, because he needs to talk to stuff written in Java.

Wether or not it's a good replacement for the main virtual machine is open 
to debate.  I comment that Jython hasn't become the main Python 
environment either.  But that doesn't mean it's a bad idea.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Christophe TROESTLER]

On Wed, 25 Aug 2004, Brian Hurt <bhurt@spnz.org> wrote:
> 
> interfacing with other Java components.  I know of at least one 
> programmer who is currently using Jython, who would love to switch over to 
> Ocaml- but can't, because he needs to talk to stuff written in Java.

The translation will not be automatic but maybe
http://cristal.inria.fr/~xleroy/software.html#camljava can help?

My 2¢,
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Daniel Ortmann]

Why not CORBA?  I must be missing something.

Brian Hurt <bhurt@spnz.org> writes:

> On 26 Aug 2004, skaller wrote:
> 
> > Curious though why you'd want to... interfacing to C I can
> > understand. But why bother with the JVM or Java?

[...]

> Better interfacing with other Java components.  I know of at least one 
> programmer who is currently using Jython, who would love to switch over to 
> Ocaml- but can't, because he needs to talk to stuff written in Java.
> 
> Wether or not it's a good replacement for the main virtual machine is open 
> to debate.  I comment that Jython hasn't become the main Python 
> environment either.  But that doesn't mean it's a bad idea.

-- 
Daniel Ortmann, LSI Logic, 3425 40th Av NW, Suite 200, Rochester MN 55901
work: Daniel.Ortmann@lsil.com / 507.535.3861 / 63861 int / 8012.3861 gdds
home: dortmann@charter.net 507.288.7732, 2414 30Av NW #D, Rochester MN 55901
gpg/pgp public key: http://wwwkeys.us.pgp.net
jabber: daniel_ortmann@jabber.org / dortmann@jabber.co.lsil.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Sat, 2004-08-28 at 00:26, Daniel Ortmann wrote:
> Why not CORBA?  I must be missing something.

You're not. I worked on a heavy duty C++ telco
project and that's exactly what they did.
The management and visual monitoring code was
Java and connected to the embedded C++ engine via Corba.

However this kind of interfacing isn't really
that good for lower level interoperability.
For example adding new primitive operations
to a programming system still seems to 
require an FFI approach -- you don't really
expect such primitives to reach across network
layers -- more likely you'd be using them to
*define* networking layers :)
.
-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Brian Hurt]

On 27 Aug 2004, Daniel Ortmann wrote:

> Why not CORBA?  I must be missing something.
> 

Because the idea was to make it easier to whip out throw-away code than 
writting said code in Java would be.  CORBA is many things, but "light 
weight" is not one of them.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 10:05 am, skaller wrote:
> On Thu, 2004-08-26 at 00:26, John Goerzen wrote:
> > I come to OCaml from a Python background, and one of the most
> > interesting bits of technology for Python is Jython[1].
>
> Curious though why you'd want to... interfacing to C
> I can understand. But why bother with the JVM or Java?

Because you need to do *NOTHING* to get access to Java classes.  The 
Java type system is rich/strict enough (depending on your perspective) 
to be usable directly from Python, with no glue whatsoever.

Also because there are some interesting Java libraries that do not exist 
for C, or are not as easily usable.  JDBC is a common one.

And because Python is cross-platform, Java is, but compiled C is not.  A 
Jython program still can "run anywhere".

Example:

$ jython
Jython 2.1 on java1.4.1 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import java.lang.System
>>> p = java.lang.System.getProperties()
>>> for key in p.keySet().toArray():
...    print "%-30s: %s" % (key, java.lang.System.getProperty(key))
...
java.runtime.name             : Java(TM) 2 Runtime Environment, Standard 
Edition
python.cachedir               : /home/jgoerzen/.jython-cache
sun.boot.library.path         : /usr/lib/j2se/1.4/jre/lib/i386
java.vm.version               : Blackdown-1.4.1-beta
java.vm.vendor                : Blackdown Java-Linux Team
java.vendor.url               : http://www.blackdown.org/
path.separator                : :
java.vm.name                  : Java HotSpot(TM) Client VM

etc.

I wrote no glue code for this.  It just worked.  And that is the case 
with almost all Java APIs and libraries.  Jython can be used, in fact, 
as an interactive Java environment.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Thu, Aug 26, 2004 at 01:05:45AM +1000, skaller wrote:
> On Thu, 2004-08-26 at 00:26, John Goerzen wrote:
> 
> > I come to OCaml from a Python background, and one of the most 
> > interesting bits of technology for Python is Jython[1].
> 
> Curious though why you'd want to... interfacing to C
> I can understand. But why bother with the JVM or Java?

In UK government projects (my area of knowledge last year) you'll find
some closed-source Java libraries which are required for interfacing
to various network protocols and file formats.  This locks you in to
using the "90s COBOL" for all your work.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
NET::FTPSERVER is a full-featured, secure, configurable, database-backed
FTP server written in Perl: http://www.annexia.org/freeware/netftpserver/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Alternative Bytecodes for OCaml

[Nicolas Cannasse]

> I see several possibilities with both of those paths:
>
>  * An ocamlc/ocamlrun that execute under Java or .NET and compile/run
> normal OCaml bytecode
>
>  * An ocamlopt-equivolent that would compile OCaml code directly to Java
> or .NET bytecode

I started some weeks ago a library to enable the OCaml programmer to
manipulate Java bytecode, so it can :
- generate valid .class files
- read .class files and interpret them in OCaml

The library already have a full .class parser but still need the
corresponding printer and a small OCaml JVM in order to be able to interpret
java bytecode. That might be added easily, people interested in helping or
getting informations can contact me directly.

Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 10:40 am, Nicolas Cannasse wrote:
> The library already have a full .class parser but still need the
> corresponding printer and a small OCaml JVM in order to be able to
> interpret java bytecode. That might be added easily, people
> interested in helping or getting informations can contact me
> directly.

That does sound mighty interesting.  FWIW, I just packaged up IKVM for 
Debian.  IKVM is a JVM written in C# that runs under Mono.

I think there is nothing but good that can come out of these things.

One of the classic, common, and often still valid arguments against 
functional languages is that there are far fewer modules available for 
them than for a l
anguage like Perl, Python, or Java.  I'm talking about text-processing, 
network interaction, etc.  OCaml is probably the best out there from 
what I've seen for a functional language, but it still has a ways to go 
to catch up.

Painless integration with other languages means that this problem 
suddenly drops away if you can take the performance hit and one-time 
setup complexity.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Sat, 2004-08-28 at 03:55, John Goerzen wrote:

> One of the classic, common, and often still valid arguments against 
> functional languages is that there are far fewer modules available for 
> them than for a l
> anguage like Perl, Python, or Java.  I'm talking about text-processing, 
> network interaction, etc.  

The way to get a library of important utilities
for Ocaml is to (a) make interfaces to C and (b) write the code
in Ocaml.

The main argument for interoperability isn't to get commonly
available modules from other languages -- its to get access
to *custom* code written for other systems.

Apart from Swing .. well what common Java library
would be remotely interesting in Ocaml?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Friday 27 August 2004 01:37 pm, skaller wrote:
> The way to get a library of important utilities
> for Ocaml is to (a) make interfaces to C and (b) write the code
> in Ocaml.

Why is C so much better?  It's actually pretty darn difficult to 
interface to C from a higher-level language.

And (b) is sometimes just NOT an option, either because of time 
constraints or because you don't know what the original code does to 
start with.

> The main argument for interoperability isn't to get commonly
> available modules from other languages -- its to get access
> to *custom* code written for other systems.
>
> Apart from Swing .. well what common Java library
> would be remotely interesting in Ocaml?

That's way too easy: JDBC.  (Not because OcamlDBI sucks but because so 
many databases have JDBC available.)

How about the JavaMail API, which includes nice IMAP support and stuff?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Sat, 2004-08-28 at 04:49, John Goerzen wrote:
> On Friday 27 August 2004 01:37 pm, skaller wrote:
> > The way to get a library of important utilities
> > for Ocaml is to (a) make interfaces to C and (b) write the code
> > in Ocaml.
> 
> Why is C so much better?  It's actually pretty darn difficult to 
> interface to C from a higher-level language.

Two reasons. One: C is the portable interface
to almost all operating systems -- there are
ISO Standards governing compliance (both for C and Posix)
and interface specs from people like Microsoft.

Two: there are a lot of libraries written
in C with C interfaces, which are either
compliant with some standard or open source.

In particular most programming languages, 
such as Python, have C level APIs.

So binding to C does really have a particular importance.
Ocaml already has reasonable facilities to do it
(including documentation)

> And (b) is sometimes just NOT an option, either because of time 
> constraints or because you don't know what the original code does to 
> start with.

I agree. But an off-the-shelf guarranteed interface to
Java isn't currently available either. Where should you
put your energy?

> That's way too easy: JDBC.  (Not because OcamlDBI sucks but because so 
> many databases have JDBC available.)

Surely enhancing OcamlDBI is a viable option?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Friday 27 August 2004 03:39 pm, skaller wrote:
> On Sat, 2004-08-28 at 04:49, John Goerzen wrote:
> > On Friday 27 August 2004 01:37 pm, skaller wrote:
> > > The way to get a library of important utilities
> > > for Ocaml is to (a) make interfaces to C and (b) write the code
> > > in Ocaml.
> >
> > Why is C so much better?  It's actually pretty darn difficult to
> > interface to C from a higher-level language.
>
> Two reasons. One: C is the portable interface
> to almost all operating systems -- there are

This means that you could write an OCaml interface to syscalls.  
Granted, that's an advantage, but one I rarely need.

> Two: there are a lot of libraries written
> in C with C interfaces, which are either
> compliant with some standard or open source.

That's true.  At the same time, binding to C is just about the most 
difficult language I could imagine to bind to.  There are all sorts of 
issues to consider.  Pointers cause trouble all over the place -- is 
this bit of data allocated, returned from a static place in a function, 
a global variable that never should be freed?  Is this variable input, 
output, or both?  When do I allow the memory to be freed?  What if the 
C side is using garbage collection too?  How do I represent this union 
in OCaml?

Now, I've written plenty of C code.  It's tough enough to use several 
libraries in a pure-C project, let alone with other languages.

> In particular most programming languages,
> such as Python, have C level APIs.

True, though most are also getting .NET CLI-level APIs these days.

> So binding to C does really have a particular importance.
> Ocaml already has reasonable facilities to do it
> (including documentation)

I'm not disputing that at all.  Obviously this is true.  I'm just 
suggesting that other approaches have utility, too, because they're 
superior in some situations.

> > And (b) is sometimes just NOT an option, either because of time
> > constraints or because you don't know what the original code does
> > to start with.
>
> I agree. But an off-the-shelf guarranteed interface to
> Java isn't currently available either. Where should you
> put your energy?
>
> > That's way too easy: JDBC.  (Not because OcamlDBI sucks but because
> > so many databases have JDBC available.)
>
> Surely enhancing OcamlDBI is a viable option?

I have to talk to several databases who provide drivers only for Windows 
ODBC and Java JDBC.  There is no hope of OCamlDBI supporting them, 
ever.

-- 
John Goerzen
Author, Foundations of Python Network Programming
http://www.complete.org/pynet

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Fri, Aug 27, 2004 at 03:56:43PM -0500, John Goerzen wrote:
> I have to talk to several databases who provide drivers only for Windows 
> ODBC and Java JDBC.  There is no hope of OCamlDBI supporting them, 
> ever.

Is it possible to go via the ODBC driver (dbi_odbc.cmo)?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
NET::FTPSERVER is a full-featured, secure, configurable, database-backed
FTP server written in Perl: http://www.annexia.org/freeware/netftpserver/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Friday 27 August 2004 5:05 pm, Richard Jones wrote:
> On Fri, Aug 27, 2004 at 03:56:43PM -0500, John Goerzen wrote:
> > I have to talk to several databases who provide drivers only for
> > Windows ODBC and Java JDBC.  There is no hope of OCamlDBI
> > supporting them, ever.
>
> Is it possible to go via the ODBC driver (dbi_odbc.cmo)?

Not in this case; they have provided ODBC drivers only for Windows.

Alas.

>
> Rich.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Keith Wansbrough]

> On Friday 27 August 2004 5:05 pm, Richard Jones wrote:
> > On Fri, Aug 27, 2004 at 03:56:43PM -0500, John Goerzen wrote:
> > > I have to talk to several databases who provide drivers only for
> > > Windows ODBC and Java JDBC.  There is no hope of OCamlDBI
> > > supporting them, ever.
> >
> > Is it possible to go via the ODBC driver (dbi_odbc.cmo)?
> 
> Not in this case; they have provided ODBC drivers only for Windows.

Presumably JDBC -> JNI -> OcamlDBI would be possible, with some glue
code in Java and more glue code in C, but I'm sure it would be
painful.  Worth it, though, if it's the only way to achieve the
desired result.

--KW 8-)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Sat, 2004-08-28 at 06:56, John Goerzen wrote:

> > Two reasons. One: C is the portable interface
> > to almost all operating systems -- there are
> 
> This means that you could write an OCaml interface to syscalls.  
> Granted, that's an advantage, but one I rarely need.

Like when you read from a in_channel in Ocaml?

You don't need to access the system. But the
Ocaml team did, to give you that feature .. :)

> > Two: there are a lot of libraries written
> > in C with C interfaces, which are either
> > compliant with some standard or open source.
> 
> That's true.  At the same time, binding to C is just about the most 
> difficult language I could imagine to bind to.  

Yeah? Just try interfacing two diffent memory management
systems -- eg Ocaml and JVM garbage collectors :)
[At least C doesn't really *have* any memory management system :]

> I'm not disputing that at all.  Obviously this is true.  I'm just 
> suggesting that other approaches have utility, too, because they're 
> superior in some situations.

And I'm not disputing that -- in general. I'm just questioning
the utility of accessing inferior technology just
to interface inferior libraries.

My suggestion was the maximum utility would actually come
from this when needing to access *custom* codes -- that
is one off applications not worth rewriting, or, proprietary
codes you cannot rewrite.

> > Surely enhancing OcamlDBI is a viable option?
> 
> I have to talk to several databases who provide drivers only for Windows 
> ODBC and Java JDBC.  There is no hope of OCamlDBI supporting them, 
> ever.

Hmm .. but Windows ODBC is just another C API for databases isn't it?
So OcamlDBI can talk to it -- Ocaml does run on Windows :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Marcin 'Qrczak' Kowalczyk]

W liście z sob, 28-08-2004, godz. 10:25 +1000, skaller napisał:

> > That's true.  At the same time, binding to C is just about the most 
> > difficult language I could imagine to bind to.  
> 
> Yeah? Just try interfacing two diffent memory management
> systems -- eg Ocaml and JVM garbage collectors :)

This is easy, as long as you don't mind not collecting cross-language
object cycles. Of course you do such thing via C glue.

After the basic infrastructure of wrapping and unwrapping objects works,
you don't have to think about memory management of data processed by
each function separately. It's much easier to use a foreign library
written in such language than one written in C, because memory
management of a C library is informally described in documentation only.

In general, if both languages are dynamically typed, or if the library
caller is dynamically typed and the library provider supports
reflection, then you might not need any glue specific to a library.
A generic wrapper might be convenient enough.

Exceptions are also doable, in such a way that they are wrapped and
unwrapped automatically.

I haven't tried threads.

I haven't tried Scheme continuations. It's not clear how they should
look like in the other language.

Tail call optimization across languages is out of reach even if both
languages support efficient tail calls, because converting the result
(or just wrapping or unwrapping) prevents any cross-language calls from
being tail calls.

I don't know if or when it's doable to tie garbage collectors such that
cross-language cycles are collected too. What hooks should they provide,
assuming both are mark & sweep or copying?

> And I'm not disputing that -- in general. I'm just questioning
> the utility of accessing inferior technology just
> to interface inferior libraries.

The libraries are not inferior even if they are written in an inferior
language.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Marcin 'Qrczak' Kowalczyk]

W liście z sob, 28-08-2004, godz. 11:35 +0200, Marcin 'Qrczak' Kowalczyk
napisał:

> Exceptions are also doable, in such a way that they are wrapped and
> unwrapped automatically.

I meant: except in C++, which doesn't provide a way to generically wrap
an exception of an unknown type in an object of a known representation.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Sat, 2004-08-28 at 19:50, Marcin 'Qrczak' Kowalczyk wrote:
> W liście z sob, 28-08-2004, godz. 11:35 +0200, Marcin 'Qrczak' Kowalczyk
> napisał:
> 
> > Exceptions are also doable, in such a way that they are wrapped and
> > unwrapped automatically.
> 
> I meant: except in C++, which doesn't provide a way to generically wrap
> an exception of an unknown type in an object of a known representation.

The problem here is: if you have a universal architecture,
such as JVM or CLR -- it defeats some of the most important
reasons to choose one language over another, which is often
the novel architecture.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Marcin 'Qrczak' Kowalczyk]

W liście z sob, 28-08-2004, godz. 20:41 +1000, skaller napisał:

> The problem here is: if you have a universal architecture,
> such as JVM or CLR -- it defeats some of the most important
> reasons to choose one language over another, which is often
> the novel architecture.

There is a good reason to be able to choose languages: to access
libraries written for these languages.

It's nice if accessing a library doesn't force to use a particular
language. Especially if we want to access two libraries written for
different languages in the same program.

And especially as most libraries are written for low-level languages
which are not pleasant to write big applications directly in.

* * *

While C and C++ have more important libraries to access, bridging to
other languages can be much easier. It creates another opportunity to
use C/C++ libraries if someone has gone the trouble of wrapping them for
some high level language.

I made a bridge between my language Kogut and Python (quite nice), and
between Kogut and Perl (not nice because the Perl object model is
unusual). This allows to use Gtk+ via PyGTK or Gtk2-Perl without any
Gtk-specific glue on my side. Hello-world-type Gtk+ applications work
in both cases (I haven't tried anything more serious yet).

I will try to make a bridge with OCaml, but I'm not quite sure how it
should look like, because OCaml is statically typed.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Basile Starynkevitch [local]]

On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:

John> I come to OCaml from a Python background, and one of the most 
John> interesting bits of technology for Python is Jython[1].  Jython is a 
John> pure Java implementation of the Python interpreter and native-code 
John> libraries.  It allows Python programs to run unmodified in a Java 
John> environment.  More powerfully, though, Python programs can use Java 
John> classes as if they were native classes. [....]

I see several reasons against using the JVM in eager functional
languages like Ocaml (I'm recalling some papers, but I forgot the
references)

   The garbage collector has different requirements in Java (JVM) and
   in Ocaml. Java is multi-threaded (in the sense that several threads
   are executing Java bytecode simultanously), but Ocaml is not really
   multi-threaded (in the sense of simultanous bytecode
   execution). Also, Java style favors big mutable objects, while
   functional style suggests many small immutable tuple blocks (i.e. tuples or
   records in Ocaml source language) with quick allocation.

   IIRC, the minimal Java overhead for any Java objects is 2 words
   (one for the class pointer, one for a serial number), while the Ocaml
   memory overhead is usually one word (for the block header, containing
   the tag & the block size).

   Ocaml runtime (and GC) is optimized for fast allocation of tuple
   (in the runtime sense) block values, and for quick tag inspection
   (useful for pattern matching) - allocating such a tuple is much
   faster than allocating a Java object (because there is no
   synchronisation issues)

   The JVM bytecode specification does not support tail-calls (which
   is really needed in functional languages) and do not provide quick
   closures (closures could be emulated by inner classes instances in
   JVM, but they would be much slower)

The substantial differences in the GC, and the lack of closure &
tailcall support in JVM is a well known barrier against using the JVM
for functional language implementations. In other words, even if some
Java enthusiasts tell otherwise, the JVM is not the universal UNCOL of
our time!

Even if the JVM specification was extended (for tail calls &
closures), the resulting implementation[s] would very probably be
slower than Ocaml (because Java requires different trade-off than
Ocaml).

Regards.
-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
other email : basile at starynkevitch dot net
Project cristal.inria.fr - temporarily 
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On Wed, Aug 25, 2004 at 07:37:45PM +0200, Basile Starynkevitch [local] wrote:
> The substantial differences in the GC, and the lack of closure &
> tailcall support in JVM is a well known barrier against using the JVM
> for functional language implementations. In other words, even if some
> Java enthusiasts tell otherwise, the JVM is not the universal UNCOL of
> our time!

It's not really an issue of speed.  It's got a lot more to do with
compatibility.  For example, an implementation like Nicolas Cannasse's
which would allow you to run the Java bytecode in a "sandbox JVM",
while keeping the main OCaml code as OCaml bytecode or native code,
would be entirely acceptable for me.

Perl4caml works very similarly to this.  Even if your OCaml code is
native, when you call out to Perl, it runs in the Perl interpreter
(in-process).  This is sufficient to provide access to the Perl
libraries.  It's not particularly fast, but you only suffer a penalty
for the small portion of the program where you call out to Perl, and
the main thing is programmer productivity anyhow.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Alternative Bytecodes for OCaml

[Yamagata Yoriyuki]

From: John Goerzen <jgoerzen@complete.org>
Subject: [Caml-list] Alternative Bytecodes for OCaml
Date: Wed, 25 Aug 2004 09:26:28 -0500

> So one of the things I've been thinking about lately is integrating 
> OCaml with either Java or the .NET CLI in a manner similar to Jython.  
> I've done some googling on the topic and it seems nobody is working on 
> this yet.  I just wanted to check and see if that's true.

The conclusion of the F#, and several SML-to-Java bytecode projects is
that JVM and .NET are too restricted to OO paradigm, I remember. 
See the thread begins http://caml.inria.fr/archives/200102/msg00048.html

On the other hand, Perl6's Parrot seems not restricted to OO, so it
would be promising.  Does anyone tried Parrot?

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Wednesday 25 August 2004 5:10 pm, Yamagata Yoriyuki wrote:
> The conclusion of the F#, and several SML-to-Java bytecode projects
> is that JVM and .NET are too restricted to OO paradigm, I remember.
> See the thread begins
> http://caml.inria.fr/archives/200102/msg00048.html

I'm not sure I buy that.  For one, Python already exists for both, and I 
believe it implements all the stumbling blocks commonly mentioned here 
save for tail recursion optimization.  Secondly, there are functional 
languages existing for .NET: Nemerle, SML, Haskell (via both ghc and 
Hugs), Scheme, Lisp.  I hardly think that one could claim that either 
VM is too limited to make an implementation.  We even have preliminary 
OCaml interpreters for Java, and the Nemerle language is *very* similar 
to OCaml.  The syntax is different, but from what I've seen, the 
language is similar enough that it should be possible to make a camlp4 
printer to output in Nemerle.

An *efficient* implementation is another matter, but one I'm not highly 
concerned about.  Those that are going to be doing sophisticated 
numerical analysis can stick with ocamlopt.

Most of my programs are non-interactive and execute in less than 1 
second even if given huge volumes of data.  I don't really care if 
they're 10 times slower.  The development time saved having to write 
Yet Another Glue or more libraries is far more valuable.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] bytecode and native code at once

[Brandon J. Van Every]

John Goerzen wrote:
>
> An *efficient* implementation is another matter, but one I'm
> not highly
> concerned about.  Those that are going to be doing sophisticated
> numerical analysis can stick with ocamlopt.

I do wish bytecode and native code could be combined in the same
application.  This is a typical game development scenario.  One might
wish to edit a Massively Multiplayer Online Game server 'live', for
example.  Some parts must be fast.  Other parts aren't so performance
critical and would be better seen as 'scripting jobs'.  Game development
encompasses both the need for heavy duty number crunching and the need
to script.


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

Is my technical content showing?

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] bytecode and native code at once

[skaller]

On Thu, 2004-08-26 at 14:26, Brandon J. Van Every wrote:

> I do wish bytecode and native code could be combined in the same
> application.  This is a typical game development scenario. 

This applies in many areas not just game development.
I'd very much like to build an extensible compiler ..

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: bytecode and native code at once

[mikel]

skaller wrote:
> On Thu, 2004-08-26 at 14:26, Brandon J. Van Every wrote:
> 
> 
>>I do wish bytecode and native code could be combined in the same
>>application.  This is a typical game development scenario. 
> 
> 
> This applies in many areas not just game development.
> I'd very much like to build an extensible compiler ..

It's doable in principle. For example, the old MacScheme compiler used 
parameters to tune compilation on a per-function basis; low optimization 
settings resulted in generation of bytecode; high optimization settings 
resulted in generation of native code. Both types of function could 
coexist in the same runtime, with the different kinds of closures 
represented by different appliable types.

I don't know what implications such a scheme might have for type safety 
in Ocaml.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mikel!

On Aug 26, 2004, at 8:52 AM, mikel wrote:

> It's doable in principle. For example, the old MacScheme compiler used 
> parameters to tune compilation on a per-function basis; low 
> optimization settings resulted in generation of bytecode; high 
> optimization settings resulted in generation of native code. Both 
> types of function could coexist in the same runtime, with the 
> different kinds of closures represented by different appliable types.
>
> I don't know what implications such a scheme might have for type 
> safety in Ocaml.
>
Is there some reason that asmdynlink, which is part of the Caml 
Development Kit, doesn't address this?

I also think that once MetaOCaml gets its native compiler done that it 
will help answer the question as well, among others. I find MetaOCaml 
very exciting!

> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkEuGUEACgkQbot1wzHBQBVg0ACbB4ho0nrAjFy4rn/bQ6DMYv4f
TH8AnAmwIqi8gjd+52R/skPrGpPhNd3A
=Dqkn
-----END PGP SIGNATURE-----

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[mikel evins]

On Aug 26, 2004, at 10:09 AM, Paul Snively wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Mikel!

Hiya, Paul! What are you up to? (Interesting to see your name floating 
around the Ocaml lists).

>
> On Aug 26, 2004, at 8:52 AM, mikel wrote:
>
>> It's doable in principle. For example, the old MacScheme compiler 
>> used parameters to tune compilation on a per-function basis; low 
>> optimization settings resulted in generation of bytecode; high 
>> optimization settings resulted in generation of native code. Both 
>> types of function could coexist in the same runtime, with the 
>> different kinds of closures represented by different appliable types.
>>
>> I don't know what implications such a scheme might have for type 
>> safety in Ocaml.
>>
> Is there some reason that asmdynlink, which is part of the Caml 
> Development Kit, doesn't address this?

I don't know. All I was saying is that I knew nothing about it, because 
I had devoted no attention to the issue.

>
> I also think that once MetaOCaml gets its native compiler done that it 
> will help answer the question as well, among others. I find MetaOCaml 
> very exciting!

Yeah, I heard the same thing from Adam Megacz. I suppose I oughta check 
it out.

--me

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Aug 26, 2004, at 10:31 AM, mikel evins wrote:

> Hiya, Paul! What are you up to? (Interesting to see your name floating 
> around the Ocaml lists).
>
Day job: conditional access systems for video on demand set-top boxes. 
C++.

Personal: Finally picking up steam on developing Unreal technology 
archive reading/writing libraries in cross-platform C++, with an eye 
towards reimplementing UnrealEd on Mac and Windows (yeah, I know). 
Studying stacks and stacks of books on type theory and language design. 
Gearing up to take some tutelage, and audit some Winter- or Spring-term 
courses at CalTech on <http://www.metaprl.org> with an eye toward its 
use as a language design workbench, as was done for 
<http://mojave.caltech.edu>.

I've been O'Camling off and on (mostly off) for almost three years now. 
Discovered it when I stumbled across 
<http://www.cs.cornell.edu/Info/Projects/Ensemble> back then. Started 
to get more serious about it about a year and a half ago when the Mac 
OS X support seemed to get solid. Did a presentation at the first 
<http://smartfriends.com/u>, which was, I felt, well-received, and 
certainly fell into the you-learn-a-lot-by-teaching category.

Finally, the one thing that's a stumbling block for most folks in our 
circle when talking about O'Caml is the lack of platform bindings. Mike 
Hamburg has taken a good stab at an O'Caml/Objective-C gateway. That 
really needs finishing, and I had begun thinking about how to 
automatically generate actual OS bindings by parsing Objective-C 
headers and providing any necessary external annotations a la the 
Forklift FFI, but I haven't gotten anywhere with that beyond thinking 
about it.

Anyway, I now take O'Caml very, very seriously. I believe it to be a 
perfectly reasonable alternative to C++ for folks who want expressive 
power, safety, reasonable resource consumption, and runtime 
performance. Clearly there are areas in which there's still more work 
to be done, cf. the conversations about floating-point representation 
for high-performance 3D programming, or about memory-mapped files and 
their interaction with the garbage collector. Nothing you're not 
familiar with from your extensive work in Common Lisp and Mac OS X. :-)

Your turn: what's your O'Caml story?

>> Is there some reason that asmdynlink, which is part of the Caml 
>> Development Kit, doesn't address this?
>
> I don't know. All I was saying is that I knew nothing about it, 
> because I had devoted no attention to the issue.
>
Right; fair enough. You can find the CDK, including asmdynlink, at 
<http://pauillac.inria.fr/cdk>.

>>
>> I also think that once MetaOCaml gets its native compiler done that 
>> it will help answer the question as well, among others. I find 
>> MetaOCaml very exciting!
>
> Yeah, I heard the same thing from Adam Megacz. I suppose I oughta 
> check it out.
>
<http://www.metaocaml.org> is the place. I don't know what the status 
of their native-code support is, though; it's been a long time coming.

> --me
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkEuJlMACgkQbot1wzHBQBX3TwCgsxkBLMO4T1lAMFUGkLt6SG3h
T7IAnjRhsCoT1+/zXyOJC5iV9wulwNFe
=t4op
-----END PGP SIGNATURE-----

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[mikel evins]

On Aug 26, 2004, at 11:04 AM, Paul Snively wrote:

> Finally, the one thing that's a stumbling block for most folks in our 
> circle when talking about O'Caml is the lack of platform bindings. 
> Mike Hamburg has taken a good stab at an O'Caml/Objective-C gateway. 
> That really needs finishing, and I had begun thinking about how to 
> automatically generate actual OS bindings by parsing Objective-C 
> headers and providing any necessary external annotations a la the 
> Forklift FFI, but I haven't gotten anywhere with that beyond thinking 
> about it.

You might consider using ffigen to parse the headers and writing a 
simple parser in Ocaml to read its output. This is basically how the 
autogenerated ffi works in OpenMCL (ffigen can be hard to find; I can 
send you a copy of the version used with OpenMCL if you like).

>
> Anyway, I now take O'Caml very, very seriously. I believe it to be a 
> perfectly reasonable alternative to C++ for folks who want expressive 
> power, safety, reasonable resource consumption, and runtime 
> performance. Clearly there are areas in which there's still more work 
> to be done, cf. the conversations about floating-point representation 
> for high-performance 3D programming, or about memory-mapped files and 
> their interaction with the garbage collector. Nothing you're not 
> familiar with from your extensive work in Common Lisp and Mac OS X. 
> :-)

Yep. :-)

>
> Your turn: what's your O'Caml story?

I like languages. I like FP, always have. I've been messing with Caml 
and its variants for too long to remember when I started. For several 
years now I almost always had some small project going in Ocaml. Things 
heated up over the past two years as I found it possible to deploy 
Ocaml tools at work, and now I rely on it extensively for certain 
classes of project.

Basically, I still think best and most fluidly in Lisp, and I explore 
ideas and prototype things there. If I want to deploy a compact, 
single-file native executable that is really fast, I rewrite it in 
Ocaml (which I find quite easy to do most of the time). When I 
absolutely need something in C, for those (rare) cases that Ocaml won't 
do the job, I write it first in Ocaml and then translate it to C, using 
Ocaml as a specification language to make it easier to write correct C 
code.

An example of where I have to -- reluctantly -- do things in C or 
assembler is a virtual machine I'm doing where I really need to control 
register allocation, alignment, and specific bit-patterns in 64-bit 
words. I prototyped it in Ocaml using the Int64 library, then moved to 
C so that my word size was the native word size on AMD64, using GCC's 
extensions to control register allocation and alignment. The VM is 
about 30 times faster in C than in Ocaml and about one twentieth the 
object size, but that's specific to the nature of the project. I've 
also done projects in which Ocaml produced significantly faster code 
than GCC.

Of course, if someone showed me that I could get the same results using 
Ocaml, I'd move right back in a heartbeat. :-)

>
>>> Is there some reason that asmdynlink, which is part of the Caml 
>>> Development Kit, doesn't address this?
>>
>> I don't know. All I was saying is that I knew nothing about it, 
>> because I had devoted no attention to the issue.
>>
> Right; fair enough. You can find the CDK, including asmdynlink, at 
> <http://pauillac.inria.fr/cdk>.
>
>>>
>>> I also think that once MetaOCaml gets its native compiler done that 
>>> it will help answer the question as well, among others. I find 
>>> MetaOCaml very exciting!
>>
>> Yeah, I heard the same thing from Adam Megacz. I suppose I oughta 
>> check it out.
>>
> <http://www.metaocaml.org> is the place. I don't know what the status 
> of their native-code support is, though; it's been a long time coming.

Thanks for the pointers.

--me

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[skaller]

On Fri, 2004-08-27 at 03:09, Paul Snively wrote:

> Is there some reason that asmdynlink, which is part of the Caml 
> Development Kit, doesn't address this?

Its not part of the standard system, requires a patch,
isn't maintained so probably won't work with 1.08:
I also don't know if it's processor specific. 

Its big advantage was compatibility with the bytecode
Dynlink mechanism, which allowed one to fallback to
all-bytecode.

> I also think that once MetaOCaml gets its native compiler done that it 
> will help answer the question as well, among others. I find MetaOCaml 
> very exciting!

Hmm .. I suspect MetaOcaml has the following problem.
Ideally what we need is a functional method of taking
some parameterised program and sending it arbitrary
constraints, which it then uses to specialise itself,
or verify consistency.

Meta-Ocaml requires you to predict in advance what
the next constraint will be, and write an acceptor
for it which generates an acceptor for the next constraint.

EG: you'd like to say 'do X with a linear operator' and then
tell it:

1) dimensions, diagonal, sparse, values
2) sparse, dimensions, diagonal, values

and have the program optimise itself with both orderings.
MetaOcaml seems to let you do (1), or (2), but not
both with the same program?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[Keith Wansbrough]

mikel wrote:
> skaller wrote:
> > On Thu, 2004-08-26 at 14:26, Brandon J. Van Every wrote:
> >>I do wish bytecode and native code could be combined in the same
> >>application.  This is a typical game development scenario. 
> > This applies in many areas not just game development.
> > I'd very much like to build an extensible compiler ..
> 
> It's doable in principle. For example, the old MacScheme compiler used 
[..]
> 
> I don't know what implications such a scheme might have for type safety 
> in Ocaml.

GHCi, the interactive version of the Glasgow Haskell Compiler,
supports both interpreted and compiled code in the same runtime.  You
might want to look at some of their design documents here:

<http://www.haskell.org/ghc/documentation.html>

In particular, the Run-time System document discusses the mixed-mode
evaluation strategy.

--KW 8-)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[David Brown]

On Fri, Aug 27, 2004 at 09:52:33AM +0100, Keith Wansbrough wrote:

> GHCi, the interactive version of the Glasgow Haskell Compiler,
> supports both interpreted and compiled code in the same runtime.

Although, admitedly, the code that does it is fairly non-portable.  They
ended up using their own dynamic linker, which has to be ported to each new
platform you wish to support.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: bytecode and native code at once

[mikel evins]

On Aug 27, 2004, at 8:39 AM, David Brown wrote:

> On Fri, Aug 27, 2004 at 09:52:33AM +0100, Keith Wansbrough wrote:
>
>> GHCi, the interactive version of the Glasgow Haskell Compiler,
>> supports both interpreted and compiled code in the same runtime.
>
> Although, admitedly, the code that does it is fairly non-portable.  
> They
> ended up using their own dynamic linker, which has to be ported to 
> each new
> platform you wish to support.

Nevertheless, it's more portable than the old MacScheme code, which 
only ever ran on MacOS (pre-OS X), and only on the 68K architecture.

--me


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Michal Moskal]

On Wed, Aug 25, 2004 at 07:09:02PM -0500, John Goerzen wrote:
> On Wednesday 25 August 2004 5:10 pm, Yamagata Yoriyuki wrote:
> > The conclusion of the F#, and several SML-to-Java bytecode projects
> > is that JVM and .NET are too restricted to OO paradigm, I remember.
> > See the thread begins
> > http://caml.inria.fr/archives/200102/msg00048.html
> 
> I'm not sure I buy that.  For one, Python already exists for both, and I 
> believe it implements all the stumbling blocks commonly mentioned here 
> save for tail recursion optimization.  Secondly, there are functional 
> languages existing for .NET: Nemerle, SML, Haskell (via both ghc and 
> Hugs), Scheme, Lisp.  I hardly think that one could claim that either 
> VM is too limited to make an implementation.  We even have preliminary 
> OCaml interpreters for Java, and the Nemerle language is *very* similar 
> to OCaml.  The syntax is different, but from what I've seen, the 
> language is similar enough that it should be possible to make a camlp4 
> printer to output in Nemerle.

I guess it would be possible for Caml Light, but not for OCaml. OCaml
has very sophisticated type system with regard to objects and modules.
Neither of these fit with the .NET object oriented model -- it's simply
too restricted. This is one of reasons Nemerle exists.

It's probably possible to implement OCaml's objects using .NET
objects, using one interface per method, or casting everything down
to System.Object, but this doesn't seem a) pretty, b) fast nor c)
interoperable.  And c) is one of the main reasons .NET exists. 
You would at least have to add .NET-like classes and interfaces to OCaml
to make using .NET libraries possible. And if you want to write
libraries in such OCaml.NET, you would be restricted to these types at
the edges. And this in turn means you have to have very good support
for these features, and this turns out not to be so easy -- after one
year of development we still don't have full support for this stuff in
Nemerle.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: ::: Logic is a nice contrast to the Real World. :: UL++++$ C++ E--- a?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Nicolas Cannasse]

> It's probably possible to implement OCaml's objects using .NET
> objects, using one interface per method, or casting everything down
> to System.Object, but this doesn't seem a) pretty, b) fast nor c)
> interoperable.  And c) is one of the main reasons .NET exists.
> You would at least have to add .NET-like classes and interfaces to OCaml
> to make using .NET libraries possible. And if you want to write
> libraries in such OCaml.NET, you would be restricted to these types at
> the edges. And this in turn means you have to have very good support
> for these features, and this turns out not to be so easy -- after one
> year of development we still don't have full support for this stuff in
> Nemerle.

I agree with you here, the main problems OCaml and other functionnal
languages targeting CLR faces here are interoperability and performances.

There is two kind of VM : typeless ones (such as OCaml one) which bytecode
does not contains any RTTI - since all checks are done at compile-time, and
typed VMs (such as .NET CLR and the JVM). Typed VMs are a lot
ObjectOriented, and all performances (for instance GC) are tuned for an OO
type system. This is a real problem for the future of functionnal languages
: if the mainstream technology becomes .NET CLR in the next five years, yes
there will be an open source alternative in Mono but it will still be a pain
and have a performance cost to run a functional language on such an OO VM .
And even if it runs, what about interoperability ? How to expose correctly
(and automaticaly) a functional style API to an OO language, and vice-versa
? Since the type system on the language is directly embedded into the VM,
one need to "forget" functionnal style when generating bytecode.

There is several attempts to fix this problem (LLVM might be one), but none
from Sun or Microsoft. That's why the functionnal languages community should
focus on interoperating its languages in a single runtime system. If we
don't, we might loose to the leverage that the CLR provides. There is
already a big set of languages (Nemerle among them) that are targeting the
CLR because they don't want to get through reinventing the well and writing
a native code generator, an other set of languages (such as Felix) are
generating C code in order to leverage on GCC.

Ocaml is great for writing DSL, and have both very efficient bytecode and
nativecode compilers. However theses two technologies are right now reserved
to OCaml itself.  If they were more "opened" (means : documented, provide
API and tools to ease code generation, ...) , it would enable DSL writters
to leverage on theses great technologies of OCaml and might interest as well
other languages writters. However that goal might require some endorsement
and active support from OCaml team since I guess it will need modifications
in order to support other languages.

Remarks anyone ?

Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Friday 27 August 2004 04:38 am, Nicolas Cannasse wrote:
> I agree with you here, the main problems OCaml and other functionnal
> languages targeting CLR faces here are interoperability and
> performances.

No arguments here, but I would like to expand a but on the performance 
issue.  I have every reason to believe you are right about it, but one 
important thing to remember is that it may not matter to many.  In 
other words, let's not fall prey to premature optimization.

In my experience, my OCaml code is three to five times faster than my 
Python code.  Yet my Python code is still perfectly usable and I'm fine 
with its speed.

While there are plenty of places where every last bit of performance is 
vital, there are also plenty of places (I dare say even more) where 
it's simply not an important consideration, and things like developer 
productivity, bug-free code, or ease of distribution really shine.

[ snip ]

> Ocaml is great for writing DSL, and have both very efficient bytecode
> and nativecode compilers. However theses two technologies are right
> now reserved to OCaml itself.  If they were more "opened" (means :
> documented, provide API and tools to ease code generation, ...) , it

I'm not 100% certain what you're talking about here, but I'll guess and 
try to share my thoughts along those lines :-)

There is a lot of great stuff in camlp4.  It is, in my opinion, the 
single most powerful and unique part of OCaml.  I've dabbled with it 
myself, but there's a lot that's lacking, too.  Despite the tutorial 
and reference, the learning curve is quite steep due in part to the 
syntax and available parsers/lexers, and in part to the academic rather 
than how-to nature of the documents.

Then there's a whole other part of OCaml that is untapped.  For 
instance, the OCaml source includes everything necessary to write, in 
OCaml, the toplevel interpreter.  However, the OCaml modules installed 
on the system don't provide enough for someone to embed an OCaml 
interpreter (aside from the interactive kind) or generic printer in 
their own code.  I think part of the problem could be solved simply by 
installing more bits of the OCaml distribution on people's systems.

As an example, my OfflineIMAP program is written in Python and uses a 
configuration file.  Some options in the configuration file actually 
take snippets of Python code; for instance, those that filter 
selections or perform transformations on folder names.  The latter 
actually takes a full Python function (defined with Python's "lamda" 
form.)  I investigated doing this in OCaml, figuring that since there 
is a toplevel interpreter that can do this stuff, it should be 
possible.  But there seems to be no way to do it.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Brian Hurt]

On Fri, 27 Aug 2004, John Goerzen wrote:

> No arguments here, but I would like to expand a but on the performance 
> issue.  I have every reason to believe you are right about it, but one 
> important thing to remember is that it may not matter to many.  In 
> other words, let's not fall prey to premature optimization.
> 
> In my experience, my OCaml code is three to five times faster than my 
> Python code.  Yet my Python code is still perfectly usable and I'm fine 
> with its speed.
> 
> While there are plenty of places where every last bit of performance is 
> vital, there are also plenty of places (I dare say even more) where 
> it's simply not an important consideration, and things like developer 
> productivity, bug-free code, or ease of distribution really shine.
> 

Bravo.  Especially consider I don't think anyone is advocating Ocaml give 
up it's native compilation abilities.  If speed really is important, 
compile to native.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[skaller]

On Fri, 2004-08-27 at 23:09, John Goerzen wrote:

> While there are plenty of places where every last bit of performance is 
> vital, there are also plenty of places (I dare say even more) where 
> it's simply not an important consideration, and things like developer 
> productivity, bug-free code, or ease of distribution really shine.

So the bottom line is you have to have a high performance
system for those places where you need the performance.

You simply need something BOTH high level and also fast,
and Ocaml provides both, at the expense of breaking
the object model used by C. Python is high level
but not fast or C compatible.

In fact C++ is fast, high level, and C compatible,
and is really the ONLY language that actually achieves
the goal -- however it is ugly enough to seriously
challenge the 'high level' attribute :)

Felix actually tries to get both, and without losing
interoperability -- a high level language which
generates fast C compatible code.

The cost is expected to be -- not as fast or high level
as Ocaml -- higher level than C but slower, more
verbose than Python but faster.

The *worst* compromise is Java -- it isn't C compatible,
isn't fast, and isn't high level. Its called throwing
out the baby with the bath water.

> As an example, my OfflineIMAP program is written in Python and uses a 
> configuration file.  Some options in the configuration file actually 
> take snippets of Python code

> I investigated doing this in OCaml, figuring that since there 
> is a toplevel interpreter that can do this stuff, it should be 
> possible.  But there seems to be no way to do it.

Yeah, there is -- see the Dynlink module in the manual
which is fairly well documented. But your program must be bytecode
to use it, and of course you have to ocamlc the configuration
file -- Python does this automatically, in Ocaml you'd have to
do it manually, but it's no big deal.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Nicolas Cannasse]

> > I agree with you here, the main problems OCaml and other functionnal
> > languages targeting CLR faces here are interoperability and
> > performances.
>
> No arguments here, but I would like to expand a but on the performance
> issue.  I have every reason to believe you are right about it, but one
> important thing to remember is that it may not matter to many.  In
> other words, let's not fall prey to premature optimization.

I agree. I was talking of performances as one of the advanges coming from
technology leverage. But that's true it's not the best one : accessing to
many libraries or interfacing seamlessly with other languages are much more
powerful features that we can get when focusing on a particular runtime
system.

However, my point was that current (to-be-)mainstream runtime systems (.NET
CLR and JVM) are not offering the best executation environements for
functional languages and we are then loosing some of the advanges the OO
languages are getting with no cost because theses VMs have been designed
with OO in mind. In the long term, that might be quite a big handicap for
functional languages not to be able to keep up in terms of performances or
easiness of interoperability when compared to OO languages.

> > Ocaml is great for writing DSL, and have both very efficient bytecode
> > and nativecode compilers. However theses two technologies are right
> > now reserved to OCaml itself.  If they were more "opened" (means :
> > documented, provide API and tools to ease code generation, ...) , it
>
> I'm not 100% certain what you're talking about here, but I'll guess and
> try to share my thoughts along those lines :-)
>
> There is a lot of great stuff in camlp4.  It is, in my opinion, the
> single most powerful and unique part of OCaml.  I've dabbled with it
> myself, but there's a lot that's lacking, too.  Despite the tutorial
> and reference, the learning curve is quite steep due in part to the
> syntax and available parsers/lexers, and in part to the academic rather
> than how-to nature of the documents.
>
> Then there's a whole other part of OCaml that is untapped.  For
> instance, the OCaml source includes everything necessary to write, in
> OCaml, the toplevel interpreter.  However, the OCaml modules installed
> on the system don't provide enough for someone to embed an OCaml
> interpreter (aside from the interactive kind) or generic printer in
> their own code.  I think part of the problem could be solved simply by
> installing more bits of the OCaml distribution on people's systems.

That was part of my thinking. A lot of technologies that are available in
the OCaml compiler sources are not made accessible to the OCaml programmer.
I would like for instance be able to create on the fly Lambda OCaml AST,
generate corresponding ocaml bytecode, and execute it : such a feature would
be great for DSL since it will remove the need to implement an efficient
runtime system (ocaml one will be used in place).

Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Benjamin Geer]

Nicolas Cannasse wrote:
> I would like for instance be able to create on the fly Lambda OCaml AST,
> generate corresponding ocaml bytecode, and execute it : such a feature would
> be great for DSL since it will remove the need to implement an efficient
> runtime system (ocaml one will be used in place).

My limited understanding of MetaOCaml is that this is what it's for; 
have I misunderstood?

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen]

On Fri, Aug 27, 2004 at 10:48:06PM +0200, Nicolas Cannasse wrote:
> That was part of my thinking. A lot of technologies that are available in
> the OCaml compiler sources are not made accessible to the OCaml programmer.
> I would like for instance be able to create on the fly Lambda OCaml AST,
> generate corresponding ocaml bytecode, and execute it : such a feature would
> be great for DSL since it will remove the need to implement an efficient
> runtime system (ocaml one will be used in place).

Just one example of this: AFAIK, there is no way, using camlp4 or any
other standard tools, to implement a custom version of printf complete
with a custom format string parser.

-- 
John Goerzen
Author, Foundations of Python Network Programming
http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Blair Zajac]

Nicolas Cannasse wrote:

>>It's probably possible to implement OCaml's objects using .NET
>>objects, using one interface per method, or casting everything down
>>to System.Object, but this doesn't seem a) pretty, b) fast nor c)
>>interoperable.  And c) is one of the main reasons .NET exists.
>>You would at least have to add .NET-like classes and interfaces to OCaml
>>to make using .NET libraries possible. And if you want to write
>>libraries in such OCaml.NET, you would be restricted to these types at
>>the edges. And this in turn means you have to have very good support
>>for these features, and this turns out not to be so easy -- after one
>>year of development we still don't have full support for this stuff in
>>Nemerle.
>>    
>>
>
>I agree with you here, the main problems OCaml and other functionnal
>languages targeting CLR faces here are interoperability and performances.
>
>There is two kind of VM : typeless ones (such as OCaml one) which bytecode
>does not contains any RTTI - since all checks are done at compile-time, and
>typed VMs (such as .NET CLR and the JVM). Typed VMs are a lot
>ObjectOriented, and all performances (for instance GC) are tuned for an OO
>type system. This is a real problem for the future of functionnal languages
>: if the mainstream technology becomes .NET CLR in the next five years, yes
>there will be an open source alternative in Mono but it will still be a pain
>and have a performance cost to run a functional language on such an OO VM .
>And even if it runs, what about interoperability ? How to expose correctly
>(and automaticaly) a functional style API to an OO language, and vice-versa
>? Since the type system on the language is directly embedded into the VM,
>one need to "forget" functionnal style when generating bytecode.
>
>There is several attempts to fix this problem (LLVM might be one), but none
>from Sun or Microsoft. That's why the functionnal languages community should
>focus on interoperating its languages in a single runtime system. If we
>don't, we might loose to the leverage that the CLR provides. There is
>already a big set of languages (Nemerle among them) that are targeting the
>CLR because they don't want to get through reinventing the well and writing
>a native code generator, an other set of languages (such as Felix) are
>generating C code in order to leverage on GCC.
>  
>

I haven't looked at Parrot too closely, but where does that fit into 
this?  Would that not be considered a VM here?  Wouldn't Parrot be 
pretty good because it supports Python and Perl which have more 
functional aspects in them than C, C++ and Java?

Regards,
Blair

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

On Fri, Aug 27, 2004 at 12:49:45PM -0700, Blair Zajac wrote:
> I haven't looked at Parrot too closely, but where does that fit into 
> this?  Would that not be considered a VM here?  Wouldn't Parrot be 
> pretty good because it supports Python and Perl which have more 
> functional aspects in them than C, C++ and Java?

I'm rather looking forward to Perl6 and Parrot.  In fact, I'm looking
forward even more to Perl5 and Parrot (some discussion here:
http://wiki.cocan.org/ocaml_and_lamp), because Perl5 is what I know,
and Perl6 looks like a radical new language to me and isn't
necessarily a sure thing.

The reason is that interfacing to Perl5 currently is a mess of macros,
sparsely documented reference counting, "magic" references and on and
on (see the source to perl4caml for the gory details).  Being able to
invoke a Parrot interpreter instead and making controlled calls into
the Perl is a much better solution.

In answer to the OP, since Perl tends to do lots of small allocations
and is somewhat functional, it seems like Parrot may be better suited
to functional languages.  More about Parrot & garbage collection,
although I'm still not sure if Parrot will do "proper" GC, or use
reference counting:

http://www.sidhe.org/~dan/blog/archives/000200.html

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MONOLITH is an advanced framework for writing web applications in C, easier
than using Perl & Java, much faster and smaller, reusable widget-based arch,
database-backed, discussion, chat, calendaring:
http://www.annexia.org/freeware/monolith/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Alternative Bytecodes for OCaml

[Yamagata Yoriyuki]

From: Richard Jones <rich@annexia.org>
Subject: Re: [Caml-list] Alternative Bytecodes for OCaml
Date: Fri, 27 Aug 2004 23:18:01 +0100

> More about Parrot & garbage collection,
> although I'm still not sure if Parrot will do "proper" GC, or use
> reference counting:

I only have looked documents in http://www.parrotcode.org, but they
indicates it will not use ref-counting.

"You're not using reference counting. Why not?" in
http://www.parrotcode.org/faq/

The doc is somewhat vague, but Parrot seems to use conservative
mark&sweep GC.  http://www.parrotcode.org/docs/pdd/pdd09_gc.html

There are a lot of people in academia in this list.  Maybe
OCaml->Parrot compiler is a good project for undergraduates?

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[Basile Starynkevitch [local]]

On Sat, Aug 28, 2004 at 08:38:35AM +0900, Yamagata Yoriyuki wrote:
> From: Richard Jones <rich@annexia.org>
> Subject: Re: [Caml-list] Alternative Bytecodes for OCaml
> Date: Fri, 27 Aug 2004 23:18:01 +0100
> 
> The doc is somewhat vague, but Parrot seems to use conservative
> mark&sweep GC.  http://www.parrotcode.org/docs/pdd/pdd09_gc.html
> 
> There are a lot of people in academia in this list.  Maybe
> OCaml->Parrot compiler is a good project for undergraduates?

Unfortunately, I am not sure it would be a good thing - and I think
that it is quite sad that Parrot designers did not consider more
cooperation (or feedback?) with the functional language communities.

I think that Ocaml programs

  use a lot of "tuples", as seen by the runtime system (ie a tagged
  block of value pointers) ; tuples are essential in Ocaml for tuples
  and recorda in the Ocaml source language.

  need to allocate tuples quickly (because functional programming style
  means lots of allocations of small immutable tuples), and to test
  quickly the tuples' tag, and to fetch quieckly the n-th component of a
  tuple (for implementation of pattern matching)

  need to have efficient closures - quickly allocated, and quickly
  applied (both thru ordinary and tail-recursive terminal calls).

Unfortunately, Parrot http://www.parrotcode.org/docs/intro.html
implement all structured objects as PMCs, which are opaque data chunks
on which all operations goes thru a table of functions (similar to C++
vtables). So, using PMCs for tuple implementations would require an
indirect call (even with Parrot JIT technology) for every basic tuple
operations (ie allocation, tag fetching, field fetching). Also, I am
not sure that Parrot has terminal (tail recursive) calls which are
essential to Ocaml (and other functional languages).

So, I would guess that a Parrot-based Ocaml implementation (even using
Parrot JIT technology) would probably be at least two times slower
than the current ocaml byterun implementation (hence about 4 times
slower than my OcamlJitRun implementation, at least on x86).

An alternative not yet considered in this interesting "bytecode"
related thread would be to *extend* a competitive VM (eg Parrot, or
maybe CLR or JVM) to add the few features needed to Ocaml, notably:
quick tuple allocation & access (both to fields and to tag), quick
closure allocation and application, tail-recursive calls.

Alos, note that Ocaml (and other functional languages) need a
performant garbage collector (because immutable tuples and closures
are allocated and accessed a lot), and that conservative GCs (à la
Boehm) have lots of interesting features (in particular,
conservativeness which makes then C-friendly, and multithreading), but
are slower than naive generational copying precise GC (see
http://starynkevitch.net/Basile/qishintro.html for some benches).


So, instead of porting Ocaml to Parrot, I would favor an extension of
Parrot (or any other competitive VM) - by adding the few needed
features suggested above) and then a port of the Ocaml compiler to
this extended VM. I do recognize that it is a big work, and that the
result might be disappointing (in terms of performance at least)
w.r.t. the current Ocaml bytecode VM.


Regards.


NB: in this post, all tuples are (unless explicitly said) in the
runtime sense of a tagged block of GC-ed pointers - not in the Ocaml
source sense. tuples (in the runtime sense) implements both Ocaml
tuples & records.

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
other email : basile at starynkevitch dot net
Project cristal.inria.fr - temporarily
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] (GC issues) Alternative Bytecodes for OCaml

[Nicolas Cannasse]

> Unfortunately, Parrot http://www.parrotcode.org/docs/intro.html
> implement all structured objects as PMCs, which are opaque data chunks
> on which all operations goes thru a table of functions (similar to C++
> vtables). So, using PMCs for tuple implementations would require an
> indirect call (even with Parrot JIT technology) for every basic tuple
> operations (ie allocation, tag fetching, field fetching). Also, I am
> not sure that Parrot has terminal (tail recursive) calls which are
> essential to Ocaml (and other functional languages).

That's the kind of things I was thinking when talking about object oriented
VM . In the OO world, everything is an object and people tends to abstract
everything - even fields, so pure efficient data structures are not
available anymore, only through expensive getter/setter and/or field lookup.
A functionnal VM typicaly need both : efficient direct access data
structures and objects with runtime lookup.

[...]
> Alos, note that Ocaml (and other functional languages) need a
> performant garbage collector (because immutable tuples and closures
> are allocated and accessed a lot), and that conservative GCs (à la
> Boehm) have lots of interesting features (in particular,
> conservativeness which makes then C-friendly, and multithreading), but
> are slower than naive generational copying precise GC (see
> http://starynkevitch.net/Basile/qishintro.html for some benches).

I would like to get your thoughs about the following, since you already
wrote a GC as well as OCamlJIT.
IMHO, having an any way to interface with C is a key feature for any
language. Because the OCaml GC is not scanning the C stack, it is needed to
use a lot of macros to take care that newly allocated blocks are not
garbaged.

What would be the cost of extending the OCaml GC with a C stack scanning
pass ?
Would it be costly/unsafe to move the pointers on the C stack ?
What kind of speed factor can you loose when using for example Boehm GC in
OCaml VM instead of OCaml GC ?
Which would be better of theses two ?
    * a conservative GC everywhere (Boehm GC for example)
    * OCaml GC but with all C allocations made directly into the old
generation (for conservativness)

I'm also of course interested in Damien thoughts about theses questions.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[Basile Starynkevitch [local]]

On Sat, Aug 28, 2004 at 07:03:44PM +0200, Nicolas Cannasse wrote:

Citing me (Basile S.)

> > Unfortunately, Parrot http://www.parrotcode.org/docs/intro.html
> > implement all structured objects as PMCs, which are opaque data chunks
> > on which all operations goes thru a table of functions (similar to C++
> > vtables). So, using PMCs for tuple implementations would require an
> > indirect call (even with Parrot JIT technology) for every basic tuple
> > operations (ie allocation, tag fetching, field fetching). Also, I am
> > not sure that Parrot has terminal (tail recursive) calls which are
> > essential to Ocaml (and other functional languages).
> 
> That's the kind of things I was thinking when talking about object oriented
> VM . In the OO world, everything is an object and people tends to abstract
> everything - even fields, so pure efficient data structures are not
> available anymore, only through expensive getter/setter and/or field lookup.
> A functionnal VM typicaly need both : efficient direct access data
> structures and objects with runtime lookup.

I'm not sure a functionnal VM need objects, except for making more
easy hooks to the external world (like the Custom block of Ocaml
provides). BTW, Ocaml objects (in the Ocaml source sense) are not
implemented as objects with C vtables in the runtime (the equivalent
of the vtable is for Ocaml only -it is not useful to the GC- and
contains Ocaml closures, not C function pointers).


> [...]
> > Alos, note that Ocaml (and other functional languages) need a
> > performant garbage collector (because immutable tuples and closures
> > are allocated and accessed a lot), and that conservative GCs (à la
> > Boehm) have lots of interesting features (in particular,
> > conservativeness which makes then C-friendly, and multithreading), but
> > are slower than naive generational copying precise GC (see
> > http://starynkevitch.net/Basile/qishintro.html for some benches).
> 
> I would like to get your thoughs about the following, since you already
> wrote a GC as well as OCamlJIT.
> IMHO, having an any way to interface with C is a key feature for any
> language. Because the OCaml GC is not scanning the C stack, it is needed to
> use a lot of macros to take care that newly allocated blocks are not
> garbaged.
> 
> What would be the cost of extending the OCaml GC with a C stack scanning
> pass ?

[Damien Doligez would probably answer better than I do]

Ocaml does scan *explicitly* the C stack. Telling *explicitly* what
are the local GC roots of C routines is the task of CAML_param &
CAML_local macros (FWIW, my Qish GC use very similar tricks,and every
exact GC has to do similarily.).

The difference between Ocaml GC's (or Qish) and Boehm's GC is that
Boehm's GC is conservative while Ocaml GC is exact (or precise): it
uses a non-copying scheme (some kind of incremental mark&sweep IIRC)
and scan every word of the C call stack, assuming it could be a GC-ed
pointer (so when you have a bit pattern - say a floating point
constant like pi - which happens to be a valid address it is followed
by Boehm's GC - which may leak this way). Some variants (eg Bartlett'
mostly copying GC) of conservative GC scan conservatively the C stack
and handle exactly the heap.

The Ocaml GC has to work quickly for young GC-ed values (which,
notably in functional programs, tend to die quickly, because a
functional programming style -with no mutable state- favors quick
allocation of many short-lived temporary values). Hence, a copying
scheme is preferable for the young generation. But a GC which work by
copying should move (ie update) pointers, so cannot be conservative:
it has to know which words are GC-ed pointers, and which are not
(otherwise, your floating point pi constant on the stack would change
mysteriously to a bitpattern of a newly forwared pointer).

> Would it be costly/unsafe to move the pointers on the C stack ?

It would be usafe, because a copying GC scheme is preferable (it is
faster for young objects), hence pointers have to be moved on the C
stack

> What kind of speed factor can you loose when using for example Boehm
> GC in OCaml VM instead of OCaml GC ?

I don't know, but I would expect something like several programs
running 2 or 3 times slower at least with a bytecode interpreter using
Boehm's GC instead of the current Ocaml bytecode VM & GC. In my simple
experiments (with Qish), a Boehm allocation is about 10 times slower
than a C malloc, which is at least 10 times slower than the usual
pointer increment of a copying generational GC (like in Ocaml or
Qish). So I would guess (but I didn't test) that a Boehm allocation
might be nearly 100 times slower than an Ocaml tuple allocation.


> Which would be better of theses two ?
>     * a conservative GC everywhere (Boehm GC for example)

I believe it would slow down significantly the OCaml VM.

>     * OCaml GC but with all C allocations made directly into the old
> generation (for conservativness)

You still has to tell the (exact) minor collector about these
allocations (ie something like putting them on the store list) - so
you won't gain much in C coding style, and you'll lose in
performance. The result of C primitives is usually a temporary value
(e.g. because C primitives tend to be wrapped by Ocaml code doing
checking and changing C errors into Ocaml exceptions), so you'll
probably better put then in the young generation.

> I'm also of course interested in Damien thoughts about theses questions.

Of course, Damien Doligez is much more expert than I am. I'll be
delighted to read his thoughts on this.


All my thoughts above are just thoughts, I did not take the time to
experiment it (and putting Boehm's GC inside Ocaml VM is not a trivial
task), so I may be grossly wrong.

This interesting discussion triggers another interesting question:
would Ocaml coders still use Ocaml if its implementation was (say) 3
or 10 times slower than the current implementation? Alternatively, do
people use my OcamlJitRun program which could provide (on several
programs) a speedup of nearly 2 on their bytecode program (which don't
have to be changed neither in their C primitives nor in the byteocde,
hence the Ocaml source code).

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
other email : basile at starynkevitch dot net
Project cristal.inria.fr - temporarily
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[skaller]

On Sun, 2004-08-29 at 06:45, Basile Starynkevitch [local] wrote:
> On Sat, Aug 28, 2004 at 07:03:44PM +0200, Nicolas Cannasse wrote:

> 
> Ocaml does scan *explicitly* the C stack. Telling *explicitly* what
> are the local GC roots of C routines is the task of CAML_param &
> CAML_local macros (FWIW, my Qish GC use very similar tricks,and every
> exact GC has to do similarily.).

The Felix GC does not. You may wonder how this can
possibly work. The answer is -- the GC is called by
the driver, and the driver is not called by the 
program -- the driver *calls* the program.

So the C stack is always empty whilst executing
the driver code, hence the GC does not need to
scan the C stack.

Of course -- your proposition is technically not
contradicted in this architecture -- more precisely
it remains true 'in vaccuo' :)

> This interesting discussion triggers another interesting question:
> would Ocaml coders still use Ocaml if its implementation was (say) 3
> or 10 times slower than the current implementation?

Yes they would. John Goerzen already made that quite clear:
there are plenty of times when performance just isn't the issue.

I am assuming you have two choices -- use the fast Ocaml and
lose interoperability, or use the slow Ocaml to get it.

> Alternatively, do
> people use my OcamlJitRun program which could provide (on several
> programs) a speedup of nearly 2 on their bytecode program.

I have an application which I would like to enhance with
dynamic loading. This application does need to perform well.
I'm using ocamlopt, with bytecode as a fallback, but I 
have to mandate bytecode to use Dynlink.

A decision to do that is likely to be strongly influenced
by the existence of OcamJitRun -- there is huge difference
between a a 5 minute compile and a 15 minute compile:
5 is enough to make a cup of coffee, 15 is enough
to go out for lunch :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[Brandon J. Van Every]

John Skaller wrote:
> > Basile Starynkevitch [local] wrote:
>
> > This interesting discussion triggers another interesting question:
> > would Ocaml coders still use Ocaml if its implementation was (say) 3
> > or 10 times slower than the current implementation?
>
> Yes they would. John Goerzen already made that quite clear:
> there are plenty of times when performance just isn't the issue.

Some would.  Perhaps those who are already converted on the grounds of
type safety or features or so forth.  Those of us shopping around for
various kinds of 'replacement languages' would be using Python.  That
is, if OCaml were indeed that slow and no other OCaml-like options were
available in open source land.  Without performance, I think Python's
critical mass and ease of use will easily beat OCaml in the marketplace.
The promise of OCaml is really performance and scale-up, areas that
Python is weak at.

You can argue all you like about what OCaml does that Python doesn't do;
strategically, it is irrelevant.  Look at the languages the world
actually uses en masse, if you want to understand what I mean.  The
point is that performance does matter.

Not really interested in debating this here, just adding my $0.02.  If
you want to debate what makes languages succeed or fail, we'd welcome
your input on ocaml-biz.
http://cgorski.org/mailman/listinfo/ocaml-biz_cgorski.org


Cheers,                         www.indiegamedesign.com
Brand*n Van Every               S*attle, WA

Praise Be to the caml-list Bayesian filter! It blesseth
my postings, it is evil crap!  evil crap!  Bigarray!
Unboxed overhead group!  Wondering!  chant chant chant...

Is my technical content showing?

// return an array of 100 packed tuples
temps
  int $[tvar0][2*100]; // what the c function needs
  value $[tvar1]; // one int
  value $[tvar2]; // one tuple
  int $[tvar3] // loop control var
oncePre
eachPre
  $[cvar0]=&($[tvar0][0]);
eachPost
  $[lvar0] = alloc(2*100, 0 /*NB: zero-tagged block*/ );
  for(int $[tvar3]=0;$[tvar3]<100;$[tvar3]++) {
    $[tvar2] = alloc_tuple(2);
    $[tvar1] = Val_int($[cvar0][0+2*$[tvar3]]);
    Store_field($[tvar2],0,$[tvar1]);
    $[tvar1] = Val_int($[cvar0][1]);
    Store_field($[tvar2],1,$[tvar1+2*$[tvar3]]);
    Array_store($[lvar0],$[tvar3],$[tvar0]);
  }
oncePost

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[John Goerzen]

On Sat, Aug 28, 2004 at 10:04:48PM -0700, Brandon J. Van Every wrote:
> Some would.  Perhaps those who are already converted on the grounds of
> type safety or features or so forth.  Those of us shopping around for
> various kinds of 'replacement languages' would be using Python.  That
> is, if OCaml were indeed that slow and no other OCaml-like options were
> available in open source land.  Without performance, I think Python's
> critical mass and ease of use will easily beat OCaml in the marketplace.

Frankly, there is more to a language than who wins in the "marketplace".
If that is all that matters, we should all just go home now, because
VB, Java, C++, and C# have far more share of the marketplace than Python.

Incidentally, I'm a long-time Python user.  I still use it.  I am moving
towards OCaml, though, and not because of performance.  I'm going to
OCaml because it provides the benefits of a strongly-typed language
without sacrificing the flexibility I love in Python.  In some ways,
thanks to things like camlp4, OCaml is more flexible.  OCaml also is
functional at its heart, something I like.  While Python keeps wishing
it's a functional language, OCaml *is*.

> The promise of OCaml is really performance and scale-up, areas that
> Python is weak at.

I'd say Python is far better at the latter than some others, such as
Perl.  But yes, OCaml beats it at both.

> You can argue all you like about what OCaml does that Python doesn't do;
> strategically, it is irrelevant.  Look at the languages the world
> actually uses en masse, if you want to understand what I mean.  The
> point is that performance does matter.

*cough* Java?  VB?  I think that goes a long way to showing that
performance is not as critical to some as you may think.

I've never said that performance matters to nobody.  I'm just saying
that there are lots of people, myself included, that don't care about it
very much.

> Not really interested in debating this here, just adding my $0.02.  If
> you want to debate what makes languages succeed or fail, we'd welcome
> your input on ocaml-biz.

I've had this argument with you before on freeciv-dev, and want to just
reiterate this here: in my book, a language doesn't succeed or fail
based on how well it does in "the marketplace".  If we went by that,
we'd conclude that Linux is a failure, Ada is a failure, Prolog, Lisp,
OCaml, Python, Perl, and perhaps C are all failures too.

Yet a strong case could be made for each of those that they're a
success.

Let's keep things in perspective, please.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[Brian Hurt]

On Sun, 29 Aug 2004, John Goerzen wrote:

> Frankly, there is more to a language than who wins in the "marketplace".
> If that is all that matters, we should all just go home now, because
> VB, Java, C++, and C# have far more share of the marketplace than Python.

20 years ago, it would have been C, Fortran, Cobol, and Pascal.  The thing 
marketplace adherents miss is that the marketplace changes.  20 years ago, 
Basic was a toy for kids, C++ had maybe two users one of who was named 
Bjarne, and Java wasn't even a twinkle in Gosling's eye.  

Things can change.  Things will change.  The only question left is how 
will things change.

One of my big hopes for Ocaml is actually open source development.  Open
source is attacking a lot of the same problems as commercial software- but
without the pointy haired bosses to maneuver around.  An increasing number
of developers are disgusted with C++ and are looking for alternatives.  
Perl is just as bad for application development.  Java has performance
issues and even more importantly, it has religous issues- it's not open
source and it's controlled by Sun.  Python and Ruby have performance
problems.  C# is controlled by Microsoft (I think the Mono project is
doomed- the question is not if Microsoft will yank the rug out from under
them, it's when.  Following Microsoft's tail lights is self defeating in
multiple ways).  There's been an upsurge in projects based on C, and 
Objective C (a language that was dead in 1990) has enjoyed a 
"renaissance".

I think it's quite possible for Open Source to adopt Ocaml en masse.  And 
that, with Open Source driving Ocaml popularity, business will start 
adopting it.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[Radu-Mihail Obada]

On Sun, 29 Aug 2004 10:06:56 -0500 (CDT), Brian Hurt <bhurt@spnz.org> wrote:
> I think it's quite possible for Open Source to adopt Ocaml en masse.  And
> that, with Open Source driving Ocaml popularity, business will start
> adopting it.
New user (both to Ocaml and to the list), but I definitely agree.
:-)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[Nicolas Cannasse]

> >     * OCaml GC but with all C allocations made directly into the old
> > generation (for conservativness)
>
> You still has to tell the (exact) minor collector about these
> allocations (ie something like putting them on the store list) - so
> you won't gain much in C coding style, and you'll lose in
> performance. The result of C primitives is usually a temporary value
> (e.g. because C primitives tend to be wrapped by Ocaml code doing
> checking and changing C errors into Ocaml exceptions), so you'll
> probably better put then in the young generation.

Since old generation collection is mostly conservative (compaction taken
appart) , allocating *by default* into the old generation and having a C
stack scanner could be a good compromise. The cases where the GC would not
be 'exact' is when the C code is calling back OCaml code, this might leave
several C values on the stack that might be mistaken with GC pointers.
Previous stack (before the interpreter loop) would not be scanned, neither C
globals so in most of the cases, no C stack would have to be scanned . That
leaves open the problem of distinction of C stacks vs OCaml stacks in native
mode... For performances issues, still using the CAML* macros and allocation
directly into the young generation would still be available.

> This interesting discussion triggers another interesting question:
> would Ocaml coders still use Ocaml if its implementation was (say) 3
> or 10 times slower than the current implementation? Alternatively, do
> people use my OcamlJitRun program which could provide (on several
> programs) a speedup of nearly 2 on their bytecode program (which don't
> have to be changed neither in their C primitives nor in the byteocde,
> hence the Ocaml source code).

The applications I'm writting are mainly speed critical (compilers,
generators), and deployed on box which does not have OCaml installed. Being
able to compile standalone native executables is a great thing and help a
lot for deployment.

Best Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[Basile Starynkevitch [local]]

On Sun, Aug 29, 2004 at 12:12:05PM +0200, Nicolas Cannasse wrote:
> > >     * OCaml GC but with all C allocations made directly into the old
> > > generation (for conservativness)
> >
> > You still has to tell the (exact) minor collector about these
> > allocations (ie something like putting them on the store list) - so
> > you won't gain much in C coding style, and you'll lose in
> > performance. The result of C primitives is usually a temporary value
> > (e.g. because C primitives tend to be wrapped by Ocaml code doing
> > checking and changing C errors into Ocaml exceptions), so you'll
> > probably better put then in the young generation.
> 
> Since old generation collection is mostly conservative (compaction taken
> appart) , allocating *by default* into the old generation and having a C
> stack scanner could be a good compromise. [....]

No, Ocaml's major GC (the garbage collection of the old generation) is
not conservative; it is precise (it knows exactly where the pointers
are), but is an incremental mark&sweep - with occasionnal call to the
compactor whichs compacts the whole heap (including old stuff) by
moving values & updating pointers.

So I don't think Ocaml's GC could be easily patched to have the old GC
work conservatively - hence avoiding the requirement of telling the
runtime what are the pointers (ie CAMLlocal* & CAMLparam* macros).

(I'm not sure that Nicolas Cannasse uses the "conservative" word in
the established sense of the GC experts - perhaps my previous
explanations where not clear enough).

There is no way to conservatively scan the C stack, because the Ocaml
GC may move pointers (and it has to, in order to be performant).

(Damien Doligez would probably explain better than I could)

Regards.

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
other email : basile at starynkevitch dot net
Project cristal.inria.fr - temporarily
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: (GC issues) Alternative Bytecodes for OCaml

[Nicolas Cannasse]

> No, Ocaml's major GC (the garbage collection of the old generation) is
> not conservative; it is precise (it knows exactly where the pointers
> are), but is an incremental mark&sweep - with occasionnal call to the
> compactor whichs compacts the whole heap (including old stuff) by
> moving values & updating pointers.
>
> So I don't think Ocaml's GC could be easily patched to have the old GC
> work conservatively - hence avoiding the requirement of telling the
> runtime what are the pointers (ie CAMLlocal* & CAMLparam* macros).
>
> (I'm not sure that Nicolas Cannasse uses the "conservative" word in
> the established sense of the GC experts - perhaps my previous
> explanations where not clear enough).

I'm sorry I was mistaken about the 'conservative' word correct usage.
Please replace "conservative" by "not moving pointers" in my previous email.

Nicolas

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Alternative Bytecodes for OCaml

[=?unknown-8bit?Q?=A3ukasz?= Dobrek]

On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:
> I see several possibilities with both of those paths:
> 
>  * An ocamlc/ocamlrun that execute under Java or .NET and compile/run 
> normal OCaml bytecode
> 
>  * An ocamlopt-equivolent that would compile OCaml code directly to Java 
> or .NET bytecode 

Here, I guess, the garbage collector for languages like Java, 
will be very inefficient with ocaml, and other way around. 
I don't know Java so well nor .NET but ML languages tend to have 
very different profile of memory usage than languages like Java 
or C#. 

best regards
Lukasz Dobrek

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners