Objective Caml 3.00 released

Objective Caml 3.00 released

[Xavier Leroy]

Brought to you by the Easter bunny: Objective Caml version 3.00.

The main novelty in this release is the integration of three important
features from Jacques Garrigue's Objective Label:

- Labeled arguments to functions and classes.  Labels help document the
  code, especially the interfaces of large libraries.
  By default, and for backward compatibility with OCaml 2.0x, labels
  are optional and can be omitted at point of call.  A compiler flag
  selects a more Objective Label-style treatment of labels, where
  labels are mandatory, but re-ordering of function arguments based on
  their labels is supported.

- Optional arguments to functions and classes.  They allow to define
  multiple call patterns for functions, 

- Polymorphic variants.  Unlike Caml's data types, those variant types
  need not be declared before use, allow constructor names belonging
  to multiple types, and provide a refined type checking.

This release 3.00 also provides the LablTk GUI library (a version of
the CamlTK interface that takes advantage of labeled and optional
arguments to provide a much nicer interface), and the OCamlbrowser
"integrated programming environment" (library browser, type-checking
editor, and interactive Objective Caml shell).

Other novelties of this release include support for exception renaming,
a simplified handling of libraries containing C code (the Caml library
now "remembers" all the C libraries that need to be linked in), and
several new library modules Bigarray, Int32, Int64, Nativeint to
facilitate interfacing with numerical C and Fortran code.  A more
detailed list of changes is included below.

As usual, sources, documentation and binaries for various platforms
are available from:

        http://caml.inria.fr/ocaml/distrib.html
        ftp://ftp.inria.fr/lang/caml-light/

For general info on Objective Caml, see http://caml.inria.fr/ocaml/

- Xavier Leroy, for the Objective Caml team.

Objective Caml 3.00:
--------------------

Language:
- OCaml/OLabl merger:
  * Support for labeled and optional arguments for functions and classes.
  * Support for variant types (sum types compared by structure).
  See tutorial (chapter 2 of the OCaml manual) for more information.
- Syntactic change: "?" in stream error handlers changed to "??".
- Added exception renaming in structures (exception E = F).
- (OCaml 2.99/OLabl users only) Label syntax changed to preserve
  backward compatibility with 2.0x (labeled function application
  is f ~lbl:arg instead of f lbl:arg).  A tool is provided to help
  convert labelized programs to OCaml 3.00.

Both compilers:
- Option -labels to select commuting label mode (labels are mandatory,
  but labeled arguments can be passed in a different order than in
  the definition of the function; in default mode, labels may be omitted,
  but argument reordering is only allowed for optional arguments).
- Libraries (.cma and .cmxa files) now "remember" C libraries given
  at library construction time, and add them back at link time.
  Allows linking with e.g. just unix.cma instead of
  unix.cma -custom -cclib -lunix
- Revised printing of error messages, now use Format.fprintf; no visible
  difference for users, but could facilitate internationalization later.
- Fixed bug in unboxing of records containing only floats.
- Fixed typing bug involving applicative functors as components of modules.
- Better error message for inconsistencies between compiled interfaces.

Bytecode compiler:
- New "modular" format for bytecode executables; no visible differences
  for users, but will facilitate further extensions later.
- Fixed problems in signal handling.

Native-code compiler:
- Profiling support on x86 under FreeBSD
- Open-coding and unboxing optimizations for the new integer types
  int32, int64, nativeint, and for bigarrays.
- Fixed instruction selection bug with "raise" appearing in arguments
  of strict operators, e.g. "1 + raise E".
- Better error message when linking incomplete/incorrectly ordered set
  of .cmx files.
- Optimized scanning of global roots during GC, can reduce total running
  time by up to 8% on GC-intensive programs.

Interactive toplevel:
- Better printing of exceptions, including arguments, when possible.
- Fixed rare GC bug occurring during interpretation of scripts.
- Added consistency checks between interfaces and implementations
  during #load.

Run-time system:
- Added support for "custom" heap blocks (heap blocks carrying
  C functions for finalization, comparison, hashing, serialization
  and deserialization).
- Support for finalisation functions written in Caml.

Standard library:
- New modules Int32, Int64, Nativeint for 32-bit, 64-bit and
  platform-native integers
- Module Array: added Array.sort, Array.stable_sort.
- Module Gc: added Gc.finalise to attach Caml finalisation functions to
  arbitrary heap-allocated data.
- Module Hashtbl: do not bomb when resizing very large table.
- Module Lazy: raise Lazy.Undefined when a lazy evaluation needs itself.
- Module List: added List.sort, List.stable_sort; fixed bug in List.rev_map2.
- Module Map: added mapi (iteration with key and data).
- Module Set: added iterators for_all, exists, filter, partition.
- Module Sort: still here but deprecated in favor of new sorting functions
  in Array and List.
- Module Stack: added Stack.top
- Module String: fixed boundary condition on String.rindex_from
- Added labels on function arguments where appropriate.

New libraries and tools:
- ocamlbrowser: graphical browser for OCaml sources and compiled interfaces,
  supports cross-referencing, editing, running the toplevel.
- LablTK: GUI toolkit based on TK, using labeled and optional arguments,
  easier to use than CamlTK.
- Bigarray: large, multi-dimensional numerical arrays, facilitate
  interfacing with C/Fortran numerical code, efficient support for
  advanced array operations such as slicing and memory-mapping of files.

Other libraries:
- Bytecode threads: timer-based preemption was broken, works back again;
  fixed bug in Pervasives.input_line; exported Thread.yield.
- System threads: several GC / reentrancy bugs fixed in buffered I/O
  and Unix I/O; revised Thread.join implementation for strict POSIX
  conformance; exported Thread.yield.
- Graphics: added support for double buffering; added, current_x, current_y,
  rmoveto, rlineto, and draw_rect.
- Num: fixed bug in Num.float_of_num.
- Str: worked around potential symbol conflicts with C standard library.
- Dbm: fixed bug with Dbm.iter on empty database.

New or updated ports:
- Alpha/Digital Unix: lifted 256M limitation on total memory space 
  induced by -taso
- Port to AIX 4.3 on PowerPC
- Port to HPUX 10 on HPPA
- Deprecated 680x0 / SunOS port

Macintosh port:
- Implemented the Unix and Thread libraries.
- The toplevel application does not work on 68k Macintoshes; maybe
  later if there's a demand.
- Added a new tool, ocamlmkappli, to build an application from a
  program written in O'Caml.

Re: Objective Caml 3.00 released

[John Prevost]

- (OCaml 2.99/OLabl users only) Label syntax changed to preserve
  backward compatibility with 2.0x (labeled function application
  is f ~lbl:arg instead of f lbl:arg).  A tool is provided to help
  convert labelized programs to OCaml 3.00.

Interesting.

- Libraries (.cma and .cmxa files) now "remember" C libraries given
  at library construction time, and add them back at link time.
  Allows linking with e.g. just unix.cma instead of
  unix.cma -custom -cclib -lunix

Awesome!

- New modules Int32, Int64, Nativeint for 32-bit, 64-bit and
  platform-native integers

Sugoi!

I look forward to working with the new system!

John.

Re: Objective Caml 3.00 released

[Max Skaller]

Xavier Leroy wrote:
> 
> Brought to you by the Easter bunny: Objective Caml version 3.00.

	Thanks!
 
	A comment on the documentation for the integer types.
What does '32 bit integer' mean? What is the meaning of
'bitwise or'? It is _necessary_ to say something like

	'implements an integer with 32 bit twos complement
representation' for either of these statements to be meaningful,
that is, to establish a mapping between an array of 32 bits,
and an integral value. 


-- 
John (Max) Skaller at OTT [Open Telecommications Ltd]
mailto:maxs@in.ot.com.au      -- at work
mailto:skaller@maxtal.com.au  -- at home

Re: what does "32-bit integer" mean?

[Xavier Leroy]

> 	A comment on the documentation for the integer types.
> What does '32 bit integer' mean?

It means "an integer whose machine representation consists of 32
binary digits".  How surprising...

> What is the meaning of 'bitwise or'?

It means "the logical `or' operation applied bit per bit to the
machine representations of its two arguments".  Unexpected, isn't it?

(I think you just won the first prize for most vacuous question asked on
this mailing list.)

> It is _necessary_ to say something like
> 	'implements an integer with 32 bit twos complement
> representation' for either of these statements to be meaningful,
> that is, to establish a mapping between an array of 32 bits,
> and an integral value. 

Ah, twos complement and ones complement -- comp.lang.c 's favorite
flame war.  (I know you love flame wars, but are you sure we should
have this one here?) 

Caml integers are C integers in (slight) disguise -- by virtue of the
Caml bytecode interpreter being written in ANSI C.  C integers are
machine integers in (slight) disguise.  The ANSI C reference explains
what can be assumed on integers and what is machine-dependent.  Yes,
bitwise operations expose the difference between twos complement and
ones complement.  So what?

At any rate, no ones complement computer have been produced in the last
20 years, so it should be safe to assume twos complement if you need
to make that assumption.

This reminds me of a nice compiler book from the late 60s, whose title
is something like "Compilation for digital computers".  Presumably, in
these days, one had to specify that one's computer was digital, not
analog.  Now we don't bother.

- Xavier Leroy

RE: what does "32-bit integer" mean?

[Paul A. Steckler]

>This reminds me of a nice compiler book from the late 60s, whose title
>is something like "Compilation for digital computers".  

I believe the book you refer to is
"Compiler Construction for Digital Computers",
by David Gries, copyright 1971.  I have a copy on my 
shelf, leftover from my office's previous tenant.
It looks like it was printed using an IBM
Selectric typeball. :-)

-- Paul

Re: what does "32-bit integer" mean?

[John Max Skaller]

Xavier Leroy wrote:

> (I think you just won the first prize for most vacuous question asked on
> this mailing list.)

	Thanks :-(

> > It is _necessary_ to say something like
> >       'implements an integer with 32 bit twos complement
> > representation' for either of these statements to be meaningful,
> > that is, to establish a mapping between an array of 32 bits,
> > and an integral value.
> 
> Ah, twos complement and ones complement -- comp.lang.c 's favorite
> flame war.  (I know you love flame wars, but are you sure we should
> have this one here?

	I am not interested in wars or flame wars.
I am sure we should have this discussion, however.

> Caml integers are C integers in (slight) disguise -- by virtue of the
> Caml bytecode interpreter being written in ANSI C.  C integers are
> machine integers in (slight) disguise.  The ANSI C reference explains
> what can be assumed on integers and what is machine-dependent.  Yes,
> bitwise operations expose the difference between twos complement and
> ones complement.  So what?

	This would be a flaw in the ocaml language specification.
 
> At any rate, no ones complement computer have been produced in the last
> 20 years, so it should be safe to assume twos complement if you need
> to make that assumption.

	I'm not interested in 'should be safe' as much as
specified language semantics. In this case, you are 
refering to the 'C specification', but this is not done
in the manual. You also do not say WHICH C specification,
C90 or C9X. The semantics I refer to are tightened up a bit
in C9X.
 
> This reminds me of a nice compiler book from the late 60s, whose title
> is something like "Compilation for digital computers".  Presumably, in
> these days, one had to specify that one's computer was digital, not
> analog.  Now we don't bother.

	I am a member of the C committee.
The issues here are important and non-trivial.
I write algorithms that depend on it :-) 
I point them out only as a service to the ocaml community
(myself included of course :-)

In particular, since ocaml does not provide any unsigned integers,
it is exposed to the mal-specified signed operations of the C
compiler. I do NOT like this. I would rather that the
ocaml team provide a mathematical definition, and MAKE
the implementation work that way on all target machines
independently of what C does.

	This is the course taken by Python.

	I also do not use the bytecode interpreter.
I'm interested in what the optimising compiler does.

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

Re: what does "32-bit integer" mean?

[Xavier Leroy]

> > (I think you just won the first prize for most vacuous question asked on
> > this mailing list.)
> 	Thanks :-(

My apologies for the sarcasm; I know I shouldn't have done it, but I just
couldn't resist :-)

> In particular, since ocaml does not provide any unsigned integers,
> it is exposed to the mal-specified signed operations of the C
> compiler. I do NOT like this. I would rather that the
> ocaml team provide a mathematical definition, and MAKE
> the implementation work that way on all target machines
> independently of what C does.

We could easily specify Caml's integers as twos complement, with
division that rounds towards zero, signed modulus, etc, etc --- all the
guarantees that C doesn't give us ---, then check those properties
during configuration and refuse to compile OCaml on machines that do
not meet those properties.  Given that all modern machines meet them,
that would not be a limitation in practice.

The other option (emulate twos complement / signed modulus / etc) on
machines that do not provide them naturally is too much
work, and just pointless (since such machines no longer exist).

> 	I am a member of the C committee.
> The issues here are important and non-trivial.
> I write algorithms that depend on it :-) 
> I point them out only as a service to the ocaml community
> (myself included of course :-)

Thanks.  But as a member of the C committee, you could make all of us
(not just Caml users, but C programmers as well) a HUGE service
by pushing forward a C standard that fully specifies signed integer
arithmetic, e.g. like Java does.  (While you're at it, please standardize
IEEE floats as well.)

> 	I also do not use the bytecode interpreter.
> I'm interested in what the optimising compiler does.

The situation is much better on the native compiler front: since we
know exactly which processors are supported, we can actually guarantee
twos complement, division that rounds towards zero, signed modulus,
etc, etc, just because all the supported processors implement those
properties.

The limiting factor is the bytecode interpreter, at least as long as
we want it to work on any system with an ANSI-compliant C compiler.

- Xavier Leroy

Re: what does "32-bit integer" mean?

[John Max Skaller]

Xavier Leroy wrote:

> We could easily specify Caml's integers as twos complement, with
> division that rounds towards zero, signed modulus, etc, etc --- all the
> guarantees that C doesn't give us ---, 

	That would be good I think.

> then check those properties
> during configuration and refuse to compile OCaml on machines that do
> not meet those properties.  Given that all modern machines meet them,
> that would not be a limitation in practice.

	Given that it is usually possible to implement the desired
semantics, such a limitation could also be removed with some
additional effort if necessary.

> >       I am a member of the C committee.
> > The issues here are important and non-trivial.
> > I write algorithms that depend on it :-)
> > I point them out only as a service to the ocaml community
> > (myself included of course :-)
> 
> Thanks.  But as a member of the C committee, you could make all of us
> (not just Caml users, but C programmers as well) a HUGE service
> by pushing forward a C standard that fully specifies signed integer
> arithmetic, e.g. like Java does.  (While you're at it, please standardize
> IEEE floats as well.)

	The C9X rules are firmer but not yet deterministic.

> The situation is much better on the native compiler front: since we
> know exactly which processors are supported, we can actually guarantee
> twos complement, division that rounds towards zero, signed modulus,
> etc, etc, just because all the supported processors implement those
> properties.
> 
> The limiting factor is the bytecode interpreter, at least as long as
> we want it to work on any system with an ANSI-compliant C compiler.

	That makes sense. However, it may make sense to specify
the desired semantics anyway, and state that the bytecode interpreter
is not conformant on certain systems.

	By the way, I think for 'native' int, the semantics 
can be loose: the idea being to 'do what the machine does',
the purpose here is already machine specific.

	Perhaps by way of explanation: I feel that the ocaml team
and myself share a goal: to be able to write code about which
various properties are easily deduced. Reasoning about bitwise
operations use together with integral ones on special 'portable
register' types such as int32 would be enhanced by a strictly
deterministic semantics.

	So I mentioned this 'flaw' in the manual not to whinge,
but to show how easily a common goal might be met.  Many applications
needing to perform encoding/decoding functions would benefit I think,
from knowing either that they're 'portable across all ocaml platforms'
or at least having a rule to know on _which_ the language will
model desired behaviour.

	In particular, many operations are easily specified with
unsigned types like 'uint32' which can only be translated to
signed types with a deterministic semantics.

	From what you have said, all existing, known, ocaml ports 
meet the twos complement specification anyhow, so not much is lost
by making that a requirement. :-)
-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Objective Caml 3.00 released

[Andreas Rossberg]

Xavier Leroy wrote:
> 
> Brought to you by the Easter bunny: Objective Caml version 3.00.

Very nice indeed, but...

The binary RPM package for RedHat 6.1 seems to be incomplete, the whole
lib tree is missing - both compiler and interpreter complain about not
finding pervasives.cmi. The RedHat 6.0 package is not accessible at all
from the website. (I've not checked the other packages.)

I'm really looking forward to trying out the fixed version,

	- Andreas

LablTk in Objective Caml 3.00

[T. Kurt Bond]

Xavier Leroy writes:
> This release 3.00 also provides the LablTk GUI library (a version of
> the CamlTK interface that takes advantage of labeled and optional
> arguments to provide a much nicer interface)

I noticed that all the ?width options and ?height options for things
like Label.create and Canvas.create have type int; Why don't these
actually have type Tk.units so that one can specify them in any of the
normal Tk screen units: Inches, Millimeters, Centimeters, Points, or
Pixels, just like you can using raw Tcl/Tk or OcamlTk ? 
-- 
T. Kurt Bond, tkb@tkb.mpl.com

Re: LablTk in Objective Caml 3.00

[Jacques Garrigue]

From: "T. Kurt Bond" <tkb@tkb.mpl.com>

> I noticed that all the ?width options and ?height options for things
> like Label.create and Canvas.create have type int; Why don't these
> actually have type Tk.units so that one can specify them in any of the
> normal Tk screen units: Inches, Millimeters, Centimeters, Points, or
> Pixels, just like you can using raw Tcl/Tk or OcamlTk ? 

The answer is in the LablTk section of the manual:

27.1   Module Tk: basic functions and types for LablTk
Dimensions 
  type units = [`Pix int|`Cm float|`In float|`Mm float|`Pt float]
  val pixels : units -> int
     Converts various on-screen units to pixels, respective to the
     default display. Available units are pixels, centimeters, inches,
     millimeters and points

Having to write units always explicitly was just a pain. This way you
can either write directly in pixels, or convert from another unit.
There is a very small glitch: if your application is intended to run
on several displays with different dpi's, you must use the
Winfo.pixels or Winfo.fpixels functions.

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

Re: LablTk in Objective Caml 3.00

[T. Kurt Bond]

T. Kurt Bond (that would be me) wrote:
> I noticed that all the ?width options and ?height options for things
> like Label.create and Canvas.create have type int; Why don't these
> actually have type Tk.units so that one can specify them in any of the
> normal Tk screen units: Inches, Millimeters, Centimeters, Points, or
> Pixels, just like you can using raw Tcl/Tk or OcamlTk ? 

Jacques Garrigue writes:
> The answer is in the LablTk section of the manual:
> 
> 27.1   Module Tk: basic functions and types for LablTk
> Dimensions 
>   type units = [`Pix int|`Cm float|`In float|`Mm float|`Pt float]
>   val pixels : units -> int
>      Converts various on-screen units to pixels, respective to the
>      default display. Available units are pixels, centimeters, inches,
>      millimeters and points

Yes, I'd found Tk.pixels.

> Having to write units always explicitly was just a pain. This way you
> can either write directly in pixels, or convert from another unit.

I guess it's a matter of taste; I always found it helpful that it
encouraged one to use screen-independent values like points instead of
pixels, and I didn't mind specifying the units.  Actually, since I
rarely specify raw pixel values in code, the conversion using 
one of the pixels functions is actually more annoying, since I have to
write, for instance, (pixels (`Pt 72)) instead of just (`Pt 72).

> There is a very small glitch: if your application is intended to run
> on several displays with different dpi's, you must use the
> Winfo.pixels or Winfo.fpixels functions.

That's a good point I hadn't thought about.

Anyway, thanks for the explanation.

(I found out it's easy enough to switch, btw, even though I don't
fully understand tkcompiler: just change the definitions of "option
Height" and "option Width" in Widgets.src from [_; int] to [_;units]
and change one place in ocamlbrowser, I think, and everything seems to
recompile and work ok.  I'll leave it alone, though, since it's the
intended behavior.)

-- 
T. Kurt Bond, tkb@tkb.mpl.com

Help: anyone knows what this error message means

[Friedman Roy]

Hi,

I have received the following error message while trying to run my
program. Does anyone knows what it means?

Fatal error: uncaught exception Invalid_argument("output_value: functional
value")

Thanks,

Roy

Help: anyone knows what this error message means

[Frank Atanassow]

Friedman Roy writes:
 > I have received the following error message while trying to run my
 > program. Does anyone knows what it means?
 > 
 > Fatal error: uncaught exception Invalid_argument("output_value: functional
 > value")

I guess it means you tried to output a function, although that is not exactly
the message I get:

  # output_value stdout succ;;
  Uncaught exception: Invalid_argument "output_value: abstract value".

-- 
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791

Re: Objective Caml 3.00 released

[Julian Assange]

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

> Brought to you by the Easter bunny: Objective Caml version 3.00.

I'd like to personally thank the ocaml team. I truly appreciate your
work. It brings me happiness and is catalytic in my bringing
happiness to others.

And to Xavier, don't take Max's whinging to heart. It seems to be
imbedded in his character. His posts infuriate me too, but it wiser to
shrug the sholders, move on and keep out of the mud. Perception and
cultural management of project mailinglists is extremely important in
developing a project community. This is something that haskell.org
have really done right. Haskell mailinglists have a general warm,
friendly tone that is highly conductive to discourse and
community. The moderation of caml-list tends to detract from this
sense of community and the complaining tone of Max's posts do
not help. However the correct anti-dote is to rebalance by injection of
unflappable warmth in the face of every adversity, because like it or
not, FP programmers are human beings and associate tone with substance
and attractive characters with attractive ideas. Btw, the ICFP99 write up
had perfect tone. Nicely done.

Cheers,
Julian.