From: Xavier Leroy <xavier.leroy@inria.fr>
To: caml-list@inria.fr
Subject: [Caml-list] Test release Objective Caml 3.03 Alpha
Date: Fri, 12 Oct 2001 15:00:27 +0200 [thread overview]
Message-ID: <20011012150027.A16644@pauillac.inria.fr> (raw)
Hello list,
An alpha release of what should eventually be Objective Caml 3.03 is
available for testing at the usual place:
http://caml.inria.fr/ocaml/distrib.html
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
are:
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
parsers.
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
expressions.
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
or
$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
arguments.
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
doing
$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:
Language:
- Removed built-in syntactic sugar for streams and stream patterns
[< ... >], now supported via CamlP4, which is now included in the
distribution.
- 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.
Type-checker:
- 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.
Tools:
- The CamlP4 pre-processor-pretty-printer is now included in the standard
distribution.
- 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
next reply other threads:[~2001-10-12 13:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-12 13:00 Xavier Leroy [this message]
2001-10-12 17:39 ` Christophe TROESTLER
2001-10-12 18:55 ` Daniel de Rauglaudre
2001-10-14 18:08 ` Christophe TROESTLER
2001-10-14 18:27 ` Daniel de Rauglaudre
2001-10-14 18:14 ` Christophe TROESTLER
2001-10-12 18:14 ` Ceri Storey
2001-10-15 14:12 ` md5i
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011012150027.A16644@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox