headers
Pierre Weis | 3 May 1996 20:56
Picon
Picon

camlot65


[Version francaise ci-dessous]

Hi,

A new version of Camlot, the well-known :) optimising compiler for
Caml Light is available by anonymous ftp from the usual Caml site
ftp.inria.fr, in the  directory lang/caml-light (file
camlot65.tar.gz). It runs on Sun4, decstations and HP snakes and Linux
boxes (but remains highly portable on any 32-bit platform).

This version compiles Caml Light version 0.61 code.
It produces C code which runs from 2 to 20 times faster than the
normal Caml Light byte-code.

As usual, you need an ANSI C compiler, preferably GCC, the regular
Caml Light compiler, and the GNU make utility.

Bug reports (if any) should be reported to this list, or directly to
Re'gis Cridlig (cridlig <at> dmi.ens.fr).

Best regards,

Re'gis Cridlig and Pierre Weis.

Bonjour,

Une nouvelle version de Camlot, le compilateur optimisant pour Caml
Light bien connu :) est disponible sur ftp.inria.fr, dans
le re'pertoire lang/caml-light (fichier camlot65.tar.gz). Il marche sur
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Hayden | 8 May 1996 15:56
Picon
Favicon

time-based profiler for Caml Special Light


Hi,
  A couple of months ago, I posted a time-based
profiler for Caml Light.  I'm posting an updated
version translated to CSL for those who are
interested.  After the README file below is a shar
script containing the required sources and a
Makefile.  Please email me if you have any
problems.

--Mark

A time-based profiler for Caml Special Light
Author: Mark Hayden, 4/96, hayden <at> cs.cornell.edu

This library is a simple time-based profiling package (as opposed to the
call-count profiler included with Caml Special Light).  It is intended to
be similar in design and output to the time-based parts of the gprof
package for C.  This library only works with Unix because it requires Unix
timer signals.  CSL does not provide access to Unix profiling signals, so
this version uses the normal timer signals for profiling.

This libary is very similar to the time-profiler announced by Christophe
Raffalli.  It differs in that it uses signals to avoid making calls to
Unix.times on every call to a profiled function.  So potentially this
library does not affect application performance as much.  Also, after
initialization, this profiler is designed to (I believe) not cause any
additional memory allocation.

Functions are registered with the profiler through calls to [Profile.fN
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bertrand JEANNET | 8 May 1996 17:15
Picon
Picon

compilateur natif Caml Special Light pour 680x0 ?


        Est-ce que quelqu'un planche deja sur l'ecriture d'un compilateur
Caml Special Light generant de l'assembleur 680x0 ? Ca pourrait etre utile
a tous les utilisateurs de Next, sun3, Macintosh, Amiga etc...

        Bertrand Jeannet

jeannet <at> poly.polytechnique.fr   (1)69 33 56 68
X93 6 CIE Ecole Polytechnique
F-91128 PALAISEAU Cedex
FRANCE
Permalink | Reply | 0 comments |
headers
Xavier Leroy | 9 May 1996 16:27
Picon
Picon

Objective Caml 1.00


We are proud to announce the availability of Objective Caml version 1.00.

Objective Caml is an object-oriented extension of the Caml dialect of ML.
It is statically type-checked (no "message not understood" run-time errors)
and performs ML-style type reconstruction (no type declarations for function
parameters). This is arguably the first publically available
object-oriented language featuring ML-style type reconstruction.

Objective Caml is a class-based OO language, and offers pretty much
all standard features of these languages, including "self", single and
multiple inheritance, "super", and binary methods, plus a number of
less common features such as parametric classes.

The main limitation (due to type reconstruction) is that coercion from
an object type to a supertype is not automatic, and needs to be
written down explicitly. Message sending remains fully polymorphic,
though.

Objective Caml is based on (and supersedes) the Caml Special Light
system. It inherits from Caml Special Light a powerful module
calculus, Modula-style separate compilation, a fast-turnaround
bytecode compiler, and a high-performance native-code compiler.
Upward compatilibity with Caml Special Light is very high.

More information on Objective Caml, including tutorials and user's
manuals, is available on the Web, at

        http://pauillac.inria.fr/ocaml/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Hayden | 9 May 1996 22:27
Picon
Favicon

another time-based profiler


...this time for Objective Caml

It difficult to keep up with the Caml
implementors.  I posted a profiler yesterday,
and then a new version of the language comes out
today.  Here is a version for Objective Caml.
The main difference is that Objective Caml
provides stubs to the Unix setitimer() system
call and access to the profiling interrupt
signals, so those are once again supported.

A README file is included below, followed by 
a shar file.

--Mark Hayden

A time-based profiler for Objective Caml
Author: Mark Hayden, 4/96, hayden <at> cs.cornell.edu

This library is a simple time-based profiling package (as opposed to the
call-count profiler included with Objective Caml).  It is intended to be
similar in design and output to the time-based parts of the gprof package
for C.  This library only works with Unix because it requires Unix timer
signals.

This libary is very similar to the time-profiler announced by Christophe
Raffalli.  It differs in that it uses signals to avoid making calls to
Unix.times on every call to a profiled function.  So potentially this
library does not affect application performance as much.  Also, after
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thorsten Ohl | 10 May 1996 12:46
Picon

Class variables in O'Caml???


I have played a little bit with O'Caml yesterday and found that the
new features very conveniently formalize what I had been doing with
mutable records already.  Good job!

I have one question however: it seems that all variables in a class
are instance variables.  Have I overlooked something in the
documentation or can somebody explain to me why class variables
(i.e. variables that are shared mong all instances of a class) are a
bad idea?

The typical application is a class of non-uniform random number
generators, where the distribution to be generated would be an
instance variable, while the state of the underlying uniform
generator should be a class variable.  This way, differrent instances
will generate different distributions, but draw from the _same_ source
of random numbers.

It is possible to emulate this with references, of course.  But it
would be somewhat unnatural ...

Cheers,
-Thorsten
Permalink | Reply | 4 comments |
headers
Christian Boos | 10 May 1996 14:57
Picon
Picon

Re: Class variables in O'Caml??? + questions


Hello, 

Thorsten Ohl writes:
 > (...)
 > 
 > The typical application is a class of non-uniform random number
 > generators, where the distribution to be generated would be an
 > instance variable, while the state of the underlying uniform
 > generator should be a class variable.  This way, differrent instances
 > will generate different distributions, but draw from the _same_ source
 > of random numbers.
 > 
 > It is possible to emulate this with references, of course.  But it
 > would be somewhat unnatural ...
 > 

I played with O'Caml too ...

IMO, the use of references is not so unnatural. Together with structs,
it provides  a clean way  to encapsulate global  state and actions for
classes.

I would illustrate this on a small example, a simple unique identifier
generator:

 #module Identifier :
 #  sig
 #    class identifier (unit) =
 #      val id : int
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thorsten Ohl | 10 May 1996 17:13
Picon

Re: Class variables in O'Caml??? + questions


>>>>> "Christian" == Christian Boos <boos <at> gr6.u-strasbg.fr> writes:

Christian> IMO, the use of references is not so unnatural. Together
Christian> with structs, it provides a clean way to encapsulate global
Christian> state and actions for classes.

Sure, it us possible to do it.  But, IMHO, class variables should be
declared in the class and be opaque.  If you put several classes in a
module, the use of module wide references makes much less sense.
Another hack is to define a sub-module for each class, but that's not
nice either ...

I'm just curious if (and why) this syntactic sugar has been left out
intentionally.
--

-- 
Thorsten Ohl, Physics Department, TH Darmstadt --- PGP: AF 38 FF CE 03 8A 2E A7
http://crunch.ikp.physik.th-darmstadt.de/~ohl/ -------- 8F 2A C1 86 8C 06 32 6B
Permalink | Reply | 1 comment |
headers
Xavier Leroy | 10 May 1996 13:43
Picon
Picon

Re: Objective Caml 1.00


> As "Upward compatibility with Caml Special Light is very high", I wonder if
> Objectif Caml will replace CSL or if newer versions of CSL will continue to
> come. Should every user of CSL move to Objective Caml ?

Objective Caml should really be viewed as the latest release of
CSL. It could very well have been called CSL 1.20. It's just that we
werent' completely happy with the name "Caml Special Light" (too long,
not catchy enough), and wanted to emphasize the new object stuff.

The only incompatibility between Objective Caml and Caml Special Light
is that there are a few extra reserved keywords in Objective Caml,
such as "new", "class", "inherit" and "constraint". Unfortunately,
several library functions were called "new" (e.g. Hashtbl.new) and had
to be renamed (e.g. Hashtbl.create).

The Objective Caml distribution contains a script (in tools/csl2ocaml)
to help convert to Objective Caml. It renames the library functions
and warns for each use of one of the now-reserved keywords as variable
names.

You may also have to change your Makefiles, because the compilers have
been renamed as well (cslc -> ocamlc, etc), but this is not even
necessary with a few extra symbolic links.

Apart from this, all CSL code should run in Objective Caml without
further modification.

Other improvements and bug fixes between CSL 1.15 and Objective Caml
1.00 include:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Conway | 11 May 1996 02:16
Picon

O'Caml & modules


Thanks for O'caml. I haven't had a chance to try it yet,
but the type system looks both interesting and useful.

Remember a while back we were having a discussion on the merits
of allowing local module definitions? It appears to me that these
are very very similar to the constructor of an object.

Does this mean that the infrastructure necessary to add
local module definitions is already partially in place? If so,
it could be a useful addition (although arugably one could just
use an object instead of a module, but it is aesthetically unpleasing.

One might want, for instance, a module giving packed-n-bit
vectors, where n is a parameter to a multiply called
function. One would then use an object to refer to a specific
bit vector, using a function from the above mentioned module,
which may get a little messy.

Anyway, I just thought this would be a good idea to re-bring
up this thread.

Thanks again,

Andrew.
Permalink | Reply | 0 comments |

Gmane