English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Test release Objective Caml 3.03 Alpha
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-10-12 (13:00)
From: Xavier Leroy <xavier.leroy@i...>
Subject: [Caml-list] Test release Objective Caml 3.03 Alpha
Hello list,

An alpha release of what should eventually be Objective Caml 3.03 is
available for testing at the usual place:

We usually do not do alpha or beta pre-releases of Objective Caml,
however enough significant changes have occurred since 3.02 that we
would like to get some user feedback on them.  The changes in question

1- Labels on function arguments are now strict (non-optional) by default,
   and the standard library modules are now not labeled, instead
   labeled versions of some of these modules are provided.
   This change was discussed at length on this list a few months ago,
   and rather than summarizing all the issues, I'm just appending
   Jacques Garrigue's "questions and answers" document.

2- As an alternative to building "custom bytecode executables"
   (containing C code statically linked), the bytecode interpreter now
   supports dynamic loading of the C part of mixed Caml/C libraries.
   This should be mostly transparent to the casual user, hopefully
   making their life easier in some cases.  However, serious testing
   is needed to make sure it works well on a variety of operating systems.

3- The CamlP4 pre-processor-pretty-printer is now integrated in the
   distribution.  Again, this should only make life easier for users,
   although we took advantage of CamlP4's better implementation of
   streams and stream parsers to remove them from the core OCaml language.

The 3.03 alpha distribution is source code only, to encourage testers
to build it themselves and not install it over their working OCaml
3.02 system :-)  This shouldn't be much of a hassle for Unix and
Cygwin users.  For pure Windows users, we are planning a binary
release of 3.03 alpha in a couple of weeks, which should also include
some new Windows-specific code.

Have fun testing this alpha release, and please let us know of your
experience with it.

- Xavier Leroy


      FAQ: how to upgrade from Objective Caml 3.02 to 3.03-alpha

I Installation

Q1: When compiling the distribution, I am getting strange linking
    errors in otherlibraries.

A1: This is probably a problem with dynamic linking. You can disable
    it with ./configure -no-shared-libs. If you really want to use
    shared libraries, look in the manual pages of your system for how
    to get some debugging output from the dynamic linker.

II Non-label changes

Q2: I get a syntax error when I try to compile a program using stream

A2: Stream parser now require camlp4. It is included in the
    distribution, and you just need to use "ocamlc -pp camlp4o" in
    place of "ocamlc".

Q3: I get a warning when I use the syntax "#variant" inside type

A3: The new syntax is [< variant], which just a special case of
    the more general new syntax, which allows type expressions like
    [ variant1 | variant2] of [> variant]. See the reference manual
    for details.

III Label changes

Q4: I was using labels before, and now I get lots of type errors.

A4: The handling of labels changed with 3.03-alpha. The new default
    is a more flexible version of the commuting label mode, allowing
    one to omit labels in total applications. There is still a
    -nolabels mode, but it does not allow non-optional labels in
    applications (this was unsound).
    To keep full compatibility with Objective Caml 2, labels were
    removed from the standard libraries. Some labelized libraries are
    kept as StdLabels (contains Array, List and String), MoreLabels
    (contains Hashtbl, Map and Set), and UnixLabels.
    Note that MoreLabels' status is not yet decided.

Q5: Why isn't there a ThreadUnixLabels module ?

A5: ThreadUnix is deprecated. It only calls directly the Unix module.

Q6: I was using commuting label mode, how can I upgrade ?

A6: The new behaviour is compatible with commuting label mode, but
    standard libraries have no labels. You can add the following
    lines at the beginning of your files (according to your needs):
          open Stdlabels
          open MoreLabels
          module Unix = UnixLabels
    Alternatively, if you already have a common module opened by
    everybody, you can add these:
          include StdLabels
          include MoreLabels
          module Unix = UnixLabels

    You will then need to remove labels in functions from other modules.
    This can be automated by using the scrapelabels tool, installed
    in the Objective Caml library directory, which both removes labels
    and inserts needed `open' clauses (see -help for details).
          $CAMLLIB/scrapelabels -keepstd *.ml
          $CAMLLIB/scrapelabels -keepmore *.ml
    Note that scrapelabels is not guaranteed to be sound for commuting
    label programs, since it will just remove labels, and not reorder

Q7: I was using a few labels in classic mode, and now I get all these
    errors. I just want to get rid of all these silly labels.

A7: scrapelabels will do it for you.
          $CAMLLIB/scrapelabels [-all] *.ml
          $CAMLLIB/scrapelabels -intf *.mli
    You should specify the -all option only if you are sure that your
    sources do not contain calls to functions with optional
    parameters, as those labels would also be removed.

Q8: I was using labels in classic mode, and I was actually pretty fond
    of them. How much more labels will I have to write now ? How can I
    convert my programs and libraries ?

A8: The new default mode is more flexible than the original commuting
    mode, so that you shouldn't see too much differences when using
    labeled libraries. Labels are only compulsory in partial
    applications (including the special case of function with an
    unkwnown return type), or if you wrote some of them.

    On the other hand, for definitions, labels present in the
    interface must also be present in the implementation.
    The addlabels tool can help you to do that. Suppose that you have
    mymod.ml and mymod.mli, where mymod.mli adds some labels. Then
          $CAMLLIB/addlabels mymod.ml
    will insert labels from the interface inside the implementation.
    It also takes care of inserting them in recursive calls, as
    the return type of the function is not known while typing it.

    If you used labels from standard libraries, you will also have
    problems with them. You can proceed as described in A6. Since you
    used classic mode, you do not need to bother about changed
    argument order.


Detailed list of changes:

- Removed built-in syntactic sugar for streams and stream patterns
  [< ... >], now supported via CamlP4, which is now included in the
- Switched the default behaviour to labels mode (labels are compulsory),
  but allows omitting labels when a function application is complete.
  -nolabels mode is available but deprecated for programming.
  (See also scrapelabels and addlabels tools below.)
- Removed all labels in the standard libraries, except labltk.
  Labelized versions are kept for ArrayLabels, ListLabels, StringLabels
  and UnixLabels. "open StdLabels" gives access to the first three.
- Extended polymorphic variant type syntax, allowing union types and
  row abbreviations for both sub- and super-types. #t deprecated in types.
- See the Upgrading file for how to adapt to all the above changes.

- Fixed obscure bug in module typing causing the type-checker to loop
  on signatures of the form
        module type M
        module A: sig module type T = sig module T: M end end
        module B: A.T
- Improved efficiency of module type-checking via lazy computation of
  certain signature summary information.
- An empty polymorphic variant type is now an error.

Both compilers:
- Fixed wrong code generated for "struct include M ... end" when M
  contains one or several "external" declarations.

Byte-code compiler:
- Protect against VM stack overflow caused by module initialization code
  with many local variables.
- Support for dynamic loading of the C part of mixed Caml/C libraries.
- Removed the -use-runtime and -make-runtime flags, obsoleted by dynamic
  loading of C libraries.

Native-code compiler:
- Attempt to recover gracefully from system stack overflow.  Currently
  works on x86 under Linux and BSD.
- Alpha: work around "as" bug in Tru64 5.1.

Toplevel environment:
- Revised printing of inferred types and evaluation results
  so that an external printer (e.g. Camlp4's) can be hooked in.

- The CamlP4 pre-processor-pretty-printer is now included in the standard
- New tool ocamlmklib to help build mixed Caml/C libraries.
- New tool scrapelabels and addlabels, to either remove (non-optional)
  labels in interfaces, or automatically add them in the definitions.
  They provide easy transition from classic mode ocaml 3.02 sources,
  depending on whether you want to keep labels or not.
- ocamldep: added -pp option to handle preprocessed source files.

Run-time system:
- Support for dynamic loading of the C part of mixed Caml/C libraries.
  Currently works under Linux, FreeBSD, Windows, Tru64, Solaris and Irix.
- Implemented registration of global C roots with a skip list,
  runs much faster when there are many global C roots.
- Autoconfiguration script: fixed wrong detection of Mac OS X; problem
  with the Sparc, gcc 3.0, and float alignment fixed.

Standard library:
- Added Pervasives.flush_all to flush all opened output channels.

Other libraries:
- All libraries revised to allow dynamic loading of the C part.
- Graphics under X Windows: revised event handling, should no longer lose
    mouse events between two calls to wait_next_event(); wait_next_event()
    now interruptible by signals.
- Bigarrays: fixed bug in marshaling of big arrays.

Windows port:
- Fixed broken Unix.{get,set}sockopt*

Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr