Francois Rouaix | 1 Mar 13:41 1997

Re: ML extension language

> A main advantage of extension languages is that they enable a high
> degree of portability, thereby facilitating the availability of (in
> this case) functional programming tools.  More specifically, instead
> of requiring the user to install an interpreter at their site to be
> able to run their application, the application *is* an interpreter for
> its own private language.

The availability of an extension language does not mean that the application
will be portable. The application itself has to be portable in the first place.
Of course, having a portable extension language allows extensions to be
portable as well.

> but the main difference is that in a caml program,
> the main program is the interpreter for the caml virtual machine, whereas
> in an extension language control resides in the application.
Even with the current releases of Caml, it may be a little more complex:
for example, in a CamlTk application, the control is essentially in the
event loop, which belongs to Tk. Moreover, using client/server, RPCs, threads
and whatever, it's "easy" to have several co-existing control flows.

> Thus far, I plan
> to use almost the entire caml-light runtime system, and write a different
> compiler (in C) for a simpler, but (hopefully!) still powerful language.  
The advantage of Caml over Scheme, Python, Tcl or Rexx is that it is 
*statically* strongly typed. The Caml runtime system knows nothing of types;
it simply provides a reasonably efficient portable platform to execute
strict functional and imperative programs.

If you want to define a language "simpler" than Caml, but that has
basically the same operational semantics as well as a strong polymorphic
(Continue reading)

Francois Pessaux | 3 Mar 17:01 1997



Y-a-t'il deja un soft de morphing ecrit en Caml ?


(*                                                                   *)
(*                      Francois PESSAUX (Francois.Pessaux <at> *)
(*                                                    Projet CRISTAL *)
(*                               ( *)
(*                                                                   *)

Lyn A Headley | 4 Mar 05:24 1997

ocaml -> java bytecode?

subject kinda says it: has anyone worked on converting ocaml
to java byte code?  If not I might consider giving it a try.


Frank Christoph | 4 Mar 13:49 1997

Re: ocaml -> java

  Instead of compiling directly to Java bytecode, it might be more profitable
to write a translator to Pizza.  Pizza is a strict superset of Java developed
by Martin Odersky and Phil Wadler which is extended with higher-order
functions, algebraic types, and parametric polymorphism, which is itself
translated to pure Java source code.

  Check out the Pizza home page.


Frank Christoph                 Next Solution Co.      Tel: 0424-98-1811
christo <at>                             Fax: 0424-98-1500

Pawel Wojciechowski | 10 Mar 15:01 1997

Conversion between file descriptors and strings

Hi all,

I just started programming in the Objective Caml language. At the current 
stage of my project, I need to implement a communication between a process 
and its child process, which is created by 'fork'. I decided to use pipes 
from the Unix library. Instead of exchanging standard descriptors (0 and 1) 
for descriptors fd_in and fd_out created by 'pipe' (as in the expression
(fd_out, fd_in) = pipe()), I'd prefer to pass descriptors fd_out and fd_in,
to a program executed as a forked process, as arguments when invoking
'execvp'. Then, you can pass these values to the program (which is stored 
in a separate file and compiled separately) as an array of *strings*
being a structural argument to the 'execvp'.

My question is how to convert a descriptor of type file_descr into a string 
and vice-versa?

In C, there is no such problems, since descriptors are integers, and you 
can always write accordingly: 

sprintf(arg1, "%d", pipe[0])


descr =  atoi(argv[1])

In strongly-typed (O)Caml, we should expect the following error message:
"This expression has type int but is here used with type Unix.file_descr"

I don't have much experience in using (O)Caml so appologize if you
(Continue reading)

Xavier Leroy | 11 Mar 14:28 1997

Objective Caml 1.04 released

Release 1.04 of Objective Caml is now available.

The main novelty in this release is the port of the Caml Light replay
debugger. Also, the native-code compiler now works on Silicon
Graphics, weak pointers are supported, and the foreign interface
was enriched to make calling Caml from C easier.

A detailed list of changes follows at the end of this message.

The sources and Windows binaries are available by anonymous FTP
at Diffs are not available due to
bootstrapping difficulties.

See for documentation and general info
about Objective Caml.

- Xavier Leroy

Objective Caml 1.04:

* Replay debugger ported from Caml Light; added debugger support in
  compiler (option -g) and runtime system. Debugger is alpha-quality
  and needs testing.

* Parsing:
  - Support for "# linenum" directives.
  - At toplevel, allow several phrases without intermediate ";;".

* Typing:
(Continue reading)

Daniel de Rauglaudre | 11 Mar 17:24 1997

camplp4 0.5

Release 0.5 of Camp4 is now available.

It is compatible with Objective Caml version 1.04 (latest version).
The sources are available by anonymous FTP at:
    README.camlp4  small description
    camlp4.tar.gz  sources   documentation


 Projet Cristal - INRIA Rocquencourt
 Tel: +33 (01) 39 63 53 51
 Email: daniel.de_rauglaudre <at>

Xavier Leroy | 12 Mar 10:41 1997

Re: Objective Caml's Unix libraries

> It seems to me that in the interface file unix.mli (from the directory
> otherlibs/unix of the Objective Caml release 1.03), one line should be
> amended. Instead of 
> type file_descr
> there should be:
> type file_descr = int 

No. File descriptors are an abstract type in the Unix library, and
this is a conscious decision. An abstract type is a type that can only
be manipulated using the operations given by its implementation
module. In the case of the Unix library, this means that the only way
to obtain a file descriptor is through the constants stdin, stdout,
stderr, or the operations open, pipe, accept, ... One of the benefits
is that typing will catch many stupid errors, such as confusing the
"file descriptor" and the "length" arguments to "read".

> File descriptors are integers indeed. 

That's what C programming lets you believe, but they are not. It does
not make sense to add or multiply two file descriptors, for instance.

> This allowed me to avoid some problems when using file descriptors 
> (I recently signalled my problem on the mailing list).

I have doubts that what you were trying to do (pass file
descriptors to an exec'd program by giving their numbers as
command-line arguments) is 100% POSIX conformant.
(Continue reading)

Andrew Conway | 11 Mar 20:31 1997

New C interfaces

Dear o'caml community,

I have been reading the 1.04 documentation on the C language interface,
and it occured to me that one could get library routined compiled with ocamlopt
to live in harmony with the top level by compiling the library routines
using ocamlopt -output-obj, and then linking them into the toplevel
using -custom. It looks messy but practical. 

Are there any problems with this, apart from the hassle? 
Does this make multiple copies of the garbage collector?

I have a small number of numeric routines that I link into the
top level, and it would be very nice to have them operating more

(By the way: there are still many references to caml light in chapter 13.)

[ resume:

Je pense qu'on peut utiliser "ocamlopt -output-obj" et "ocamlmktop -custom"
pour vitesse. Pourquoi pas?


Pawel Wojciechowski | 12 Mar 00:05 1997

Objective Caml's Unix libraries

It seems to me that in the interface file unix.mli (from the directory
otherlibs/unix of the Objective Caml release 1.03), one line should be
amended. Instead of 

(*** Basic file input/output *)

type file_descr

there should be:

(*** Basic file input/output *)

type file_descr = int 

This allowed me to avoid some problems when using file descriptors 
(I recently signalled my problem on the mailing list).

File descriptors are integers indeed. On the other hand, there is 
a correct definition of this type (ie as above) in the main file,
so everything should be ok (or I am wrong?). Unfortunately without that 
small amendment in the library files, I couldn't compile my program
without an error: "This expression has type int but is here used with 
type Unix.file_descr"