Hello
Here is the latest Caml Weekly News, for the week of 13 to 20 September, 2005.
Archive: http://thread.gmane.org/gmane.science.mathematics.logic.coq.club/714
Therese Hardin announced, in French:
PREMIER APPEL AUX COMMUNICATIONS PREMIER APPEL AUX COMMUNICATIONS
JFLA'2006 (http://jfla.inria.fr/)
Journées Francophones des Langages Applicatifs
Organisées par l'INRIA
28-31 janvier 2006
JFLA'2006 est la dix-septième conférence francophone organisée autour des
langages applicatifs et des techniques de certification basées sur la
démonstration.
Ces nouvelles journées se tiendront les
28-31 janvier 2006.
Elles auront lieu à la mer, à
Pauillac, à proximité de Bordeaux.
Toujours centrée sur l'approche fonctionnelle de la programmation, la
conférence souhaite cette année élargir son spectre aux techniques et
outils complémentaires qui élèvent le niveau de qualité des logiciels
(systèmes d'aide à la preuve, réécriture, tests, démonstration
automatique, vérification).
Les JFLA réunissent concepteurs et utilisateurs dans un
cadre agréable facilitant la communication; ces journées ont pour
ambition de couvrir le domaine des langages applicatifs, en y incluant
les apports d'outils d'autres domaines qui autorisent la construction
de systèmes logiciels plus sûrs. L'enseignement de l'approche
fonctionnelle du développement logiciel (spécification, sémantiques,
programmation, compilation, certification) est également un sujet
concernant fortement les JFLA.
C'est pourquoi des contributions sur les thèmes suivants sont
particulièrement recherchées (liste non exclusive) :
- Langages fonctionnels : sémantique, compilation, optimisation,
mesures, tests, extensions par d'autres paradigmes de programmation.
- Spécification, prototypage, développements formels d'algorithmes.
- Utilisation industrielle des langages fonctionnels.
- Assistants de preuve : implémentation, nouvelles tactiques,
développements présentant un intéret technique ou méthodologique.
- Enseignement dans ses aspects liés à l'approche fonctionnelle
du développement.
Orateurs invités
----------------
Paul Caspi (VERIMAG).
Choukri Ben-Yellès (IUT Valence).
Comité de programme
-------------------
Thérèse Hardin, Président (LIP6, Université Pierre et Marie
Curie, Paris)
Pierre-Etienne Moreau, Vice-Président (projet PROTHEO, LORIA)
Pierre Casteran (LABRI)
Christine Paulin (LRI, Université d'Orsay)
Renaud Rioboo (LIP6, UPMC)
Xavier Urbain (CEDRIC, Institut d'Informatique d'Entreprise/
CNAM)
Alan Schmitt (projet SARDES, INRIA Grenoble)
Bernard Serpette (projet OASIS, INRIA Sophia-Antipolis)
François Pessaux (Société SURLOG)
Pierre-Yves Schobbens (Institut d'Informatique, Université
de Namur)
Sandrine Blazy-Darmon (CEDRIC, Projet CRISTAL-INRIA
Rocquencourt)
Soumission
----------
Date limite de soumission : 10 octobre 2005
Les soumissions doivent être soit rédigées en français, soit
présentées en français. Elles sont limitées à 15 pages A4. Le style
latex est imposé et se trouve sur le site WEB des journées à l'adresse
suivante :
http://jfla.inria.fr/2006/actes.sty
La soumission est uniquement électronique, selon la méthode détaillée
dans
http://jfla.inria.fr/2006/instructions-fra.html
Les soumissions sont à envoyer à la présidente du comité de programme,
avec pour titre de votre message ``SOUMISSION JFLA 2006'', à l'adresse
suivante :
jfla2006@loria.fr
Les intentions de soumission envoyées le plus tôt possible à l'adresse
ci-dessus seront les bienvenues.
Dates importantes
-----------------
10 octobre 2005 : Date limite de soumission
15 novembre 2005 : Notification aux auteurs
10 décembre 2005 : Remise des articles définitifs
15 janvier 2006 : Date limite d'inscription aux journées
28-31 janvier 2006 : Journées
Pour tout renseignement, contacter
----------------------------------
Marie-Françoise Loubressac
INRIA Rocquencourt
Bureau des Cours et Colloques (JFLA2003)
Domaine de Voluceau - BP 105
78153 Le Chesnay Cedex
Tél.: +33 (0) 1 39 63 56 00 - Fax : +33 (0) 1 39 63 56 38
email : Marie-Francoise.Loubressac <at> inria.fr
http://jfla.inria.fr/2006/
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30489
Jon Harrop asked and Damien Bobillot answered:
> I've recently been trying to optimize Presenta. The profiling results
> surprised me. Most of the time was spent in the GC, invoked by
> "<spontaneous>". I assumed this meant that the GC was recycling
> enormous
> amounts of garbage from the old generation. Had it been recycled
> from the
> young generation then I assume the calls to the (minor) GC would be
> invoked
> by the allocating function - is that right?
>
> Anyway, the best way I found to track down the offending function
> was to write
> lots of extra code to spew out Gc.stat results and look at the
> amount of data
> being allocated by each function call. Doing this by hand is very
> tedious, of
> course. So I'm wondering, are there any tools to profile allocation
> and
> collection on a per function basis for OCaml code? I'm thinking of
> something
> along the lines of gprof results but showing space rather than time
> taken.
>
> I managed to find the offending function by hand this time - it was
> retypesetting the entire document every frame, regenerating the
> scene graph.
> Memoizing it improved the performance of the whole program by an
> order of
> magnitude. So this is definitely an optimisation trick worth
> remembering...
You may use GC den-bugging information by adding the following
commands at the beginning of your code :
Gc.set { (Gc.get()) with Gc.verbose = 1+2+4+8 };;
This will print a message on stdout every time a minor or major
collection is done, and some other actions like heap growing.
You may print at any time the current GC statistics (number of
collections, current heap size, total number of allocated bytes...) with :
Gc.print_stat stderr;;
It's also possible to tune the GC parameter to reduce frequency of
minor collections (by increasing the minor heap size for instance)
and some other things.
For more information, have a look at :
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30498
Mark Shinwell asked and Yoann Padioleau answered:
> This is mainly directed at the current O'Caml maintainers.
>
> Does there exist anywhere a piece of code for dumping the typed syntax
> tree representations (values of type Typedtree.structure etc) which are
> used inside the compiler? I can't find anything in the compiler to do
> this at the moment, and it looks moderately tedious to write.
You can use the dumper module by richard jones.
http://merjis.com/developers/dumper
The result is not perfect but it does a good job for fast debugging.
Mark Shinwell then added:
I already have a piece of code which does that, as it happens: the
problem is that you don't get constructor names, etc. It needs to be
something which I can build in with the compiler sources so that this
information is preserved.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30503
Aleksey Nogin announced:
We are proud to announce the latest release of the OMake Build System -
OMake version 0.9.6.5.
OMake is a build system, similar to GNU make, but with many additional
features. The home site for OMake is http://omake.metaprl.org/ . OMake
features include:
o Support for projects spanning several directories or directory
hierarchies.
o Comes with a default configuration file providing support for
OCaml, C and LaTeX projects, or a mixture thereof.
Often, a configuration file is as simple as a single line
OCamlProgram(prog, foo bar baz)
which states that the program "prog" is built from the files
foo.ml, bar.ml, and baz.ml.
o Fast, reliable, automated, scriptable dependency analysis using
MD5 digests.
o Portability: omake provides a uniform interface on Win32, Cygwin,
and Unix systems including Linux and OS X.
o Builtin functions that provide the most common features of programs
like grep, sed, and awk. These are especially useful on Win32.
o Full native support for rules that build several files at once.
o Active filesystem monitoring, where the build automatically
restarts whenever you modify a source file. This can be very
useful during the edit/compile cycle.
o A companion command interpreter, osh, that can be used
interactively.
OMake preserves the style of syntax and rule definitions used in
Makefiles, making it easy to port your project to omake. There is no
need to code in perl (cons), or Python (scons). However, there are a
few things to keep in mind:
1. Indentation is significant, but tabs are not required.
2. The omake language is functional: functions are first-class
and there are no side-effects apart from I/O.
3. Scoping is dynamic.
OMake is licensed under a mixture of the GNU GPL license (OMake engine
itself) and the MIT-like license (default configuration files).
OMake version 0.9.6.5 in mostly a bugfix release. The changes in this
version include:
- Improved support for configure-style scripts.
- LaTeX rules improvements.
- Fixed the "which" function and ocamlfind support under Cygwin.
- New built-in functions: get-registry (Windows-only), removeprefix,
html-string.
- Improved processing of complex shell pipelines.
- A number of documentation fixes.
- Numerous other bug fixes and improvements.
For a more verbose change log, please visit
http://omake.metaprl.org/changelog.html#0.9.6.5 .
Source and binary packages of OMake 0.9.6.5 may be downloaded from
http://omake.metaprl.org/download.html . In addition, OMake may be
obtained via the GODI packaging system (3.08 and "dev" branches).
To try it out, run the command "omake --install" in a project directory,
and modify the generated OMakefile.
OMake 0.9.6.5 is still an alpha release. While we have made an effort
to ensure that it is bug-free, it is possible some functions may not
behave as you would expect. Please report any comments and/or bugs to
the mailing list omake@metaprl.org and/or at http://bugzilla.metaprl.org/
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30521
Jeffrey Mathews announced:
I know, I know -- why bother optimizing bytecode? (Compelling reasons
have long been debated -- for me, it's a need to do dynamic- / meta-
programming.)
Anyway, I've written a small patch for the OCaml bytecode compiler and
runtime that significantly improves the performance of a few
floating-point intensive benchmarks (from 30 to 40%) by reducing
boxing and unboxing of intermediate floating point results.
This is still preliminary work, and honestly I'm a little suspicious
that it works so well. Testing has also been light -- it compiles and
runs my 'benchmark' script when patched against ocaml 3.08.1 and
3.08.4 (as well as MetaOcaml, though the patch needs a little
coaxing).
A short write-up can be found at http://dem.inim.us/ocamlfp/README-FP.html
The patch is found at http://dem.inim.us/ocamlfp/ocamlfp-0.1.diff.gz
I'd greatly appreciate feedback, criticism, testing on other platforms.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30522
Jim Farrand announced:
I am pleased to announce the release of dynaml 0.6-alpha. dynaml is a
camlp4 extension to O'Caml which allows values to be typed dynamically
at runtime, rather than statically at compile time.
Dynaml is available from
http://farrand.net/dynaml.shtml
There are plenty of examples in the tutorial, if you want to get an
quick overview of what dynaml can do:
http://farrand.net/dynaml-tutorial.txt
Dynaml is alpha quality, experimental software, and is licensed under
the LGPL with the linking exception.
In this release, the code has been cleaned up a simplified greatly, and
some work has been done on overloading functions.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30524
Tom Hawkins announced:
I just started a framework for describing hardware structures in OCaml.
Given a functional hardware description, HDCaml will produce a Verilog
netlist for verification and implementation.
HDCaml also has decent PSL support for assertion based verification.
Current Limitations:
- Synchronous, single clock.
- No black boxing.
- Basic regs only. No memories.
- Flat netlisting.
Possible Future Directions:
- Better clock control.
- Hierarchical netlisting.
- C, VHDL, NuSMV code generation.
- Links to HOL Light.
Any recommendations on the API structure or library features would be
appreciated.
-Tom
HDCaml Download:
http://www.confluent.org/
API Docs:
http://www.confluent.org/misc/hdcaml/Hdcaml.html
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30536
Richard Jones said and Jeffrey Evans added:
> It may interest people to know that C# is to add inferred types,
> lambda expressions with limited type inference, some other functional
> features. Unfortunately the only reference is a M$ Word document(!),
> but it's interesting reading nevertheless:
>
> http://msdn.microsoft.com/vcsharp/future/default.aspx
For that matter, F# has been around on the .NET platform for a little
while now.
http://research.microsoft.com/projects/ilx/fsharp.aspx
Of particular interest:
http://research.microsoft.com/projects/ilx/fsharp-language-compare.aspx
Bill Wood then said and Don Syme answered:
> Does anyone have a sense of the extent to which F# is (could be) a
> viable entry in the .NET arena, as opposed to an entertaining
> exercise?
Normally I do not mail to the Caml-list about F#, since such mails can
easily be misinterpreted. However, since the topic came up as an
explicit question I thought I would mention that more information about
F# can be found via Google ("F#"), or at
http://research.microsoft.com/projects/fsharp
though more fun is my blog at
http://blogs.msdn.com/dsyme
F# can cross-compile large Caml applications, e.g. the Static Driver
Verifier (50K lines -
http://www.microsoft.com/whdc/devtools/tools/SDV.mspx) and the SPiM
stochastic Pi calculus simulator (http://www.doc.ic.ac.uk/~anp/spim/),
the Abstract IL libraries and the F# compiler itself. We take
compatibility with the shared core language of OCaml very seriously, to
the extent that if our implementation of a library function throws a
different exception to the OCaml implementation we regard that as a bug.
We want to make sure that cross-compilation between F# and OCaml remains
a valid compilation model. However, we do not aim to implement all
OCaml language features - the OCaml team are too quick to add
interesting (and useful) typing features to make that possible.
Furthermore many do not make sense in the context of a .NET programming
language.
At some point I would dearly like to take the opportunity to write an
extensive report on F# for the benefit of the OCaml community. Although
F# is a simpler language than OCaml, it's role as a .NET language places
it alongside many current interesting developments in programming, e.g.
software-isolated process (called AppDomains in .NET) the recently
announced LINQ project (mentioned below), server-side programming using
ASP.NET or the ability to host semi-trusted code inside SQL Server. In
my opinion this leads to a substantially different perspective on
language design and development, and indeed the whole architecture of
the software environment feels substantially different. I think one
role that F# plays for the OCaml community is to give a chance for
people in the OCaml world dip into this architecture without relearning
everything. And, if you ever find yourself desperate to talk to some
.NET libraries, you may find it feasible to use F# for this purpose.
Anyway, that's my F# post for the year :) If you do take it for a
spin then please let us know how you get on.
Erik de Castro Lopo said:
There's also Nemerle :
http://www.nemerle.org/
which is a cross between C# and Ocaml. I uses infered types and has
Ocaml-like pattern matching.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30545
Christophe Raffalli asked:
I am looking for small ML examples (using variants, modules, objects,
etc ...)
Where one needs to write type information to be able to type-check the
program with OCaml
I am developping a new typing algorithm (not unification based ;) which
seems to accept all OCaml features and more (like higher-order type
without using a functor) with no type annotation at all. I have quite a
few examples, but all the experts on this list may have idea I did not have.
Christophe Raffalli
PS: an article and a first implementation should be available very soon.
Michael Wohlwend answered:
As my example, this should be a try of linked objects (like dllist od extlib):
class ['a] node = object(self:'a)
val mutable nx = nil
method next = nx
method set_next n = nx <- n
method apply f upto =
f self; if self <> upto then self#next#apply f upto
end;;
it doesn't work; the problem is the "nil" objects to initalize it, i cannot
get this right, there are allways typing errors. Can this be defined without
type-annotations?
ahem, this one works easily :)
class ['a] node = object(self:'a)
val mutable nx =(Obj.magic 0 : 'a)
method next = nx
method set_next n = nx <- n
method apply (f: 'a->unit) upto =
f self; if self <> upto then self#next#apply f upto
initializer nx <- self
end;;
let a = new node;;
Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).
:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1
zM
If you know of a better way, please let me know.
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.