Hello
Here is the latest Caml Weekly News, for the week of June 01 to 08, 2010.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/181d6632141060a5#
Julien Signoles asked and Alain Frisch replied:
> If I well understood what Alain Frisch and Xavier Leroy explained,
> modules (including both structures and functors) become first class
> value: structures may be converted to records and functors to functions;
> and conversely. But I let more informed person confirm this.
Not really. What you describe is the internal compilation strategy for
modules (structures -> records; functors -> functions), which did not
change with the introduction of 1st class modules.
What's possible in OCaml 3.12 is to turn a module (be it a structure or
a functor) into a "package", which is a first-class value. A package is
just the wrapper around a module that makes it a first-class value. In
particular, a package that wraps a structure (resp. a functor) is *not*
converted to a record (resp. a function).
What you can with a package:
- whatever you can do with a first-class value (pass it to a function,
store it in a data structure, etc);
- unwrap it back into the underlying module.
We've been using first-class modules for more than one year at LexiFi
and we have never found a use for packing functors into first-class
values, but I've no doubt people will find some. In particular, this
allows the program to decide at runtime (given an environment variable
or a command-line argument) to use some particular (functorized)
implementation of a data structure over another.
Eric Cooper asked and Alain Frisch replied:
> Is it possible to marshal and unmarshal these packages?
Yes, this is possible, but:
1. Extremely dangerous: there is no runtime type-checking. If you
marshal a module, you need to unmarshal it to the same package type,
exactly (no coercion allowed).
2. Rather useless: the code for functions within modules is not
marshaled (as for regular functions). If you marshal a module that
define functions, you need to unmarshal it in the same program.
> That might be a nice way to implement a plug-in architecture.
Given the points above, I don't think so!
Jacques Garrigue then said:
While marshalling of first-class modules is indeed not a good idea, I
think that dynamic loading of first-class modules might provide a nice
plug-in architecture.
For instance, you can easily build a list of such plug-ins, with an
uniform interface, and add elements to this list through dynamic
loading. They can even expose internal data, with an abstract type.
There is however a difficulty if you want to save and load data used
by these plugins uniformly. Namely, even if all these plugins expose
some data with a type "t", the "t" is actually going to be different
in each, and the type system will enforce it. This is good, but it
will be seen as different for the same plugin in a different run of
the same application. So you need to do some standard hacking around,
having unique ids for each plugin, and some magic to recover the data.
Otherwise this seems a nice approach, easier than using objects, since
objects don't let you expose internal data of different types.
(Well, actually you can probably do this with objects too, using a
polymorphic method to encoding existential types in CPS style, but
this is going to be costly and not very natural.)
To which Alain Frisch replied:
> For instance, you can easily build a list of such plug-ins, with an
> uniform interface, and add elements to this list through dynamic
> loading. They can even expose internal data, with an abstract type.
Indeed!
That's basically our primary use of first-class modules at LexiFi. Our
application maintains several sets of extensible notions (like
"instruments" or "models") and it can load plugins which can register
new such objects. Roughly speaking, each instrument is represented as a
first-class module of type (module S) which looks like:
module type S = sig
type t (* the type of parameters for the instruments *)
val t: t ttype (* a dynamic representation of the type t *)
val name: string (* name to identify this instrument, presented
in a menu to the end-user *)
val run: t -> contract (* build a fresh contract, which is a notion
independent from the instrument *)
type attrs (* the type of attributes for this instrument *)
val attrs: attrs ttype (* dynamic representation of attrs *)
val compute: t -> contract -> attrs (* calculate attributes
from initial parameters and
a contract with history *)
(* ... *)
end
The idea is that each instrument defines a number of abstract types
(parameters, attributes) and operations on these types. It also exports
values that gives the concrete structural representation of these
abstract types (the 'a ttype components above) to enable generic
operations such as automatic generation of GUI for showing/editing
values of these types, or safe marshaling. These "type" values can be
derived automatically from the actual type definitions (either with a
syntax extension, or with a compiler modification in our case).
This year's ICFP Programming Contest will begin on June 18th (12:00
Noon GMT) and will run till June 21st (12:00 Noon GMT). As in the
previous editions, this is your chance to show that your favorite
programming language is better than all others! The problem statement
and further information will become available at:
http://icfpcontest.org/2010/
Feel free to contact ifcpcont at imn dot htwk-leipzig dot de for
further questions. Good luck!
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/2c19843e4ddd7ab4#
Vincent Balat announced:
The PPS laboratory [2] is hiring a Research Engineer with good
skills in (Ca)ML programming for 1 to 2 years.
Keywords: Ocsigen, Web applications, content management, OCaml
Task:
The engineer will join the Ocsigen [1] development team, as
member of the ANR national project PWD (Programmation du Web
Diffus). The work will take place in the new research center on
free/open source software (IRILL) [3] in Paris.
He will participate in the development of various components of
the Ocsigen framework:
- implementation of higher level tools for creating Web site
easily (content management, Ocsimore project)
- extensions and improvements to the Web server
- library for writing graphical interfaces in OCaml in a browser
- Ocsigen on mobile phones
- Ocsigen and cloud computing
About Ocsigen:
Ocsigen is an open source framework to develop client server Web
applications fully in OCaml, as a single program.
About PPS:
PPS is an A-ranked CNRS laboratory of the University Paris
Diderot Paris 7. One of its main research topics is the the
study of programming languages and distributed systems and their
logical foundations. The research activity is associated with an
important software development activity, mainly in OCaml
(for example Menhir, Unison). The main themes span from the
Web (Ocsigen, CDuce, Xduce, Polipo) to parallel programming (Lwt, OcamlP3L,
CPC), from networks (Babel) to the management of software packages
(Debian, Edos, Mancoosi) and proof assistants (Coq).
About the IRILL:
The IRILL is a new international research centre on free/open source
software located in Paris. IRILL's objective is to become a reference
center for the research and development of stable and reliable free
software. By hosting development projects, IRILL will also act as an
observatory and experimental centre for transfer using free software.
Required skills:
- Expertise in OCaml programming
- Knowledge of Web standards
- Engineer or PhD degree (master may be sufficient under conditions)
Contacts:
Vincent Balat and Jérôme Vouillon:
{Vincent.Balat || Jerome.Vouillon} @pps.jussieu.fr
[1] http://www.ocsigen.org
[2] http://www.pps.jussieu.fr
[3] http://www.inria.fr/actualites/espace-presse/cp/pre201.en.html
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/dcd9b17d49310b43#
Vincent Rahli announced:
We are happy to announce the release of the version 0.5 of our type
error slicing software for the SML programming language.
Major improvements over the previous release:
* Handling of the SML 'open' feature.
* Handling of the SML datatype replication feature.
* Type error slices can now be displayed in a terminal window or in
a web browser.
* We supply Ubuntu and Fedora packages.
Other less important improvement is:
* We improved our minimisation algorithm.
Even more changes are documented in the ChangeLog file.
The aim of our type error slicer is to provide useful type error
reports for pieces of code written in SML:
* It identifies all of the program points that contribute to a type
error, including the spot with the actual programming error that
caused the type error.
* It highlights these program points in the original, unchanged
source code.
* It avoids showing internal details of the operation of the type
inference machinery.
New Ubuntu (Debian based) and Fedora (Red-Hat based) packages of our
type error slicer can be found at this URL:
http://www.macs.hw.ac.uk/ultra/compositional-analysis/type-error-slicing/
We will also shortly release a plain archive of our type error
slicer.
At the time of the release of version 0.4, we forgot to update the web
demo. We have now updated our web demo from version 0.3 to version 0.5.
Known limitations:
* We have not yet built the software for other operating systems
than Linux.
* The currently supported user interfaces are via a terminal window,
GNU Emacs (or our web demo). We are currently developing a Vim
interface.
* Some type errors are not yet discovered (the user will need to
rely on their usual type checker in these cases). Notable spots
where the implementation is incomplete are functors (you can work
around this by including signatures on functor applications),
equality types.
* Concerning fixity declarations, programs are parsed as though the
declarations were not there, which gives wrong results.
* We don't yet handle overloaded constants (for example 1 is always
of type int).
* The details of the SML basis library are incomplete (fortunately
the user can add any additional details they are using).
* The software does not currently scale well to very large programs
(we are still improving this). It is currently suitable for small
programs and use in teaching.
* We do not report free identifiers anymore.
* We have some known issues ';' that can lead to incorrect
constraint generations and so to wrong type error messages. We
are currently working on a new version of the slicer that will fix
this issue.
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/.
Batteries Included 1.2.0 Released:
http://forge.ocamlcore.org/forum/forum.php?forum_id=619
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.