Hello
Here is the latest Caml Weekly News, for the week of 29 November to 13 December, 2005.
Sorry for not sending the CWN last week, I was travelling to Japan
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31559
Philippe Narbel announced:
http://www.vuibert.com/livre1978.html
http://www.vuibert.com/DOC/273-tdm-ocalm.pdf
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31587
John Harrison announced:
I'm pleased to announce the availability of HOL Light version 2.10 from
the usual Web page:
http://www.cl.cam.ac.uk/users/jrh/hol-light
There are no very radical changes since 2.00, so existing users needn't
be in any hurry to upgrade. But it now works out of the box under OCaml
3.09, and there are a fair number of worthwhile bugfixes and enhancements,
some of which are listed below.
John.
*
New theorems:
Permutation/*.ml --- list permutations (thanks to Marco Maggesi)
Multivariate/*.ml --- determinants, more linear algebra and integration
Examples/transc.ml --- many new basic theorems about integrals on R
Examples/hol88.ml --- partial HOL88 compatibility file
Complex/transc.ml --- some complex transcendental functions
iter.ml --- more theorems about iterated operations
equal.ml --- PAT_CONV for positional conversion application
Bugfixes:
"RING" could fail on trivial conclusion with unnecessary hypotheses
"REAL_RAT_REDUCE_CONV" could leave fractions with denominator 1
"FIELD" failed to infer nonzeroness of x^n from nonzeroness of x
"DIFF_CONV" did not cope with sqrt, asn and acs
"define" had trouble with some functions out of types involving `:bool`
"define" could not cope with summations in function being defined
Other changes:
Explicit bound variables in set abstractions (thanks to Sean McLaughlin)
Universe set on type "ty" can parse and print as "(:ty)"
MESON is by default less verbose
Slightly modified lexical conventions for symbols using "," and ";"
Makefile also works out of the box with newer OCamls
Documentation:
New subsection of tutorial, plus some minor fixes
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31655
malc announced:
A while ago i have written a little helper tool to simplify using
Microsoft command line build utilities in a unix-like way. Perhaps
it would be interesting/useful to others, so here goes:
http://www.boblycat.org/~malc/imt/
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31659
Martin Jambon annouced:
I wrote a small utility which downloads and installs small Camlp4 hacks,
in order to make them more accessible:
http://martin.jambon.free.fr/p4ck.html
It's called P4ck (read 4-pack), and is limited to one-file syntax
extensions. I maintain the database of these packages, so just let me know
of any extension that you are aware of and I will add it to the list.
Currently it knows the following, I am pretty sure this list will grow:
pa_tryfinally pa_lettry pa_records pa_compr pa_infix hashtbl_ext
pa_openin pa_oo
The one line installation of all the packages looks like this:
p4ck -init -download -compile -install
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31663
Jonathan Roewen asked:
The idea: a type-safe way to parse an IO.input stream as structured
data (think C structs).
I'm wondering if anyone is interested in trying to create a camlp4
extension for reading structured data from an IO.input stream. I'm not
sure if it's at all possible, but I'd like to return a tuple, and have
it type-checked properly.
Something like:
type field = Byte | Word | DWord | Bytes of int | Char | String of int | All;;
(* corresponding output types: int | int | int32 | int list | char |
string | string; *)
What I want is code that I can pattern match easily (lists are okay,
but I get non-exhaustive match warnings all the time, and it doesn't
guarantee that I'm getting the right values. I also need to use a
second type if I want to have values other than ints.
something like: let (a,b,c) = read_struct i [Byte; Char; Word];;
(using IO module, would return IO.No_more_input if it can't read
enough, which should be okay).
where i = IO.input, such as let i = IO.input_string "hello" in...
I figure something should be possible, as the size of the tuple would
match the size of the list. I'm just not sure if camlp4 is capable of
this; I myself would have zero idea where to begin if I have to write
it... so any help would be greatly appreciated, as I would use this a
heck of a lot in my operating system project.
The operations that would use I think would be:
Byte: IO.read_byte
Word: IO.read_ui16
DWord: IO.read_real_i32
Bytes of int: n * IO.read_byte : int list
Char: IO.read
String of int: IO.really_nread n
All: read until IO.No_more_input is raised, returning a string
Actually, I just had a thought: instead of a list, you could use a
tuple as well .. if that'd make it more possible. Ohh, I forgot about
endianness .. not sure how to handle that...
Gerd Stolpmann answered:
> The idea: a type-safe way to parse an IO.input stream as structured
> data (think C structs).
My SunRPC implementation contains that. It can read and write all data
types specified for SunRPC, including all types you mention. Usage is
quite simple:
- Describe your data structure in an IDL file (syntax close to C), e.g.
struct sample {
int x;
string y<10>; /* String with max length 10 */
};
- Compile that idl file with ocamlrpcgen:
ocamlrpcgen -aux sample.x
That generates sample_aux.{ml,mli}. Among other things, you can find
here:
* For every IDL type a corresponding O'Caml type. In this example:
type sample = { x : int; y : string }
* Functions converting values of type sample to/from the generic
Xdr.xdr_value:
val _to_sample : xdr_value -> sample
val _of_sample : sample -> xdr_value
* The dynamic representation of the IDL type:
val xdrt_sample : xdr_type_term
- You can now easily convert values s of type sample to strings:
let t = Xdr.validate_xdr_type xdrt_sample in (* do this only once *)
let v = _of_sample s in
Xdr.pack_xdr_value_as_string v t []
- And back:
let v = Xdr.unpack_xdr_value ~fast:true str t [] in
_to_sample v
Although there are currently no stream functions, this would be easy to add.
Note that XDR, the marshalling technique used by SunRPC, is an Internet
standard. The representation is portable (e.g. the endianess question is
solved). You can, for example, read such values easily in from a C
program.
Link:
http://www.ocaml-programming.de/programming/rpc.html
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31701
David McClain announced:
Any musicians out there?
I just finished an OCaml framework (sans GUI) for VST Plugins in Windows. If
anyone has an interest in developing plugins with a robust VST interface, I
highly recommend OCaml over C or C++. FP is rich enough that I haven't found
the need for any OO yet. This framework is Functorized so that it can be
adapted readily to any specific VST plugin needs.
Drop me a line if you are interested in the sources and I'll either e-mail
them to you, or put them up on my website...
David McClain
Chief Technology Officer
Refined Audiometrics Laboratory
Tucson, AZ USA
http://refined-audiometrics.com
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31710
Florent Monnier announced:
I am pleased to announce the availability of OCaml_ImageMagick,
which is an interface to the library of ImageMagick.
+ ImageMagick is available at:
http://www.imagemagick.org/
+ The interface for OCaml:
http://www.linux-nantes.org/~fmonnier/OCaml/ImageMagick
+ You can have an overview of the IM available functions here:
http://www.linux-nantes.org/~fmonnier/OCaml/IM-doc/
+ License:
ImageMagick's license is compatible with the GPL,
and the binding is released under the GPL.
+ Tutorials:
If you are not used to ImageMagick, here are some tutorials written by
Anthony Thyssen (also used as a command line validation suite):
http://www.cit.gu.edu.au/~anthony/graphics/imagick6/
+ Contribute:
As I am an OCaml and C beginner you can contribute writing to me what is good
and what is not in the code.
+ State:
Alpha. So I'm waiting for feedback to claim it beta :)
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31744
Yaron Minsky announced:
This is more or less the message I sent out in October, but I wanted to
make a few clarifications based on inquiries I received. First, I wanted
to make it clear that there are both internship and full-time positions
in the offing. Another important thing to note is that we can't
practically hire summer interns who do not already have the right to
work in the US. We also now have a page discussing OCaml-related job
opportunities at Jane Street:
http://www.janestcapital.com/ocaml.html
Here's the actual announcement. As usual, please feel free to forward
it on to students or others who would be interested.
-----------------------------
Jane Street Capital (http://janestcapital.com) is a proprietary
trading company located in Manhattan. We're looking to hire people for
full time positions as well as summer internships for 2006.
Jane Street is an open and informal environment (you can wear shorts
and a t-shirt to the office), and the work is technically challenging,
including systems programming, machine learning, statistical analysis,
parallel processing, and anything that crosses our path that looks
useful. One unusual attraction of the job is that the large majority of
our programming is done in OCaml. Here's what we're looking for from
candidates:
- A commitment to the practical. Both development and research are
tightly integrated with our trading operation, and we work very
hard to keep our work relevant. One of the big attractions of the
job is the opportunity to apply serious ideas to real-world
problems.
- Great communication skills. We need people who can explain
things clearly and cogently, who can read dense academic papers
and write clear documentation.
- Strong programming skills. Most of our programming is
in OCaml, so being a solid Caml hacker is a big plus. Extra points
for deep knowledge of OCaml internals and experience wrapping
thorny libraries. But we're also interested in great programmers
who we are convinced will be able to pick up OCaml quickly, so
anyone with high-level of proficiency with functional languages
would be a good match.
- Top-notch mathematical and analytic skills. We want people who
can solve difficult technical problems, and think clearly and
mathematically about all sorts of problems.
- Strong Unix/Linux skills --- We're looking for someone who knows
their way around the standard Unix tools, can write makefiles,
shell scripts, etc. We're also very interested in people with
serious systems administration and architecture experience.
For those interested in summer internships, interns are paid quite well,
and we can help out with housing costs if you don't live nearby. If
you're interested in either the internships or the full-time positions,
please send a cover-letter and resume to:
yminsky@janestcapital.com
Note that we can't hire people for internships that don't already have
the right to work in the US.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31745
Francois Pottier announced:
We are proud to announce the first release of Menhir. Menhir compiles LR(1)
grammar specifications to OCaml code.
Menhir is 90% compatible with ocamlyacc. That is, existing ocamlyacc grammar
specifications are accepted and compiled by Menhir; the resulting parsers run
and produce correct parse trees, except they produce incorrect position
information, because none of the functionality of module Parsing is
supported. Porting a grammar specification from ocamlyacc to Menhir requires
replacing all calls to the Parsing module with new keywords.
Why switch from ocamlyacc to Menhir? In short,
* Menhir offers parameterized nonterminal symbols as well as a library of
standard definitions, including options, sequences, and lists. It also
offers limited support for EBNF syntax.
* ocamlyacc accepts LALR(1) grammars; Menhir accepts LR(1) grammars, thus
avoiding certain artificial conflicts.
* Menhir explains conflicts in terms of the grammar, not (only) in terms of
the automaton.
* Menhir allows grammar specifications to be split over multiple files. It
also allows several grammars to share a single set of tokens.
* Menhir produces reentrant parsers.
* Menhir is able to produce parsers that are parameterized by Ocaml modules.
* ocamlyacc requires semantic values to be referred to via keywords: $1, $2,
and so on. Menhir allows semantic values to be explicitly named.
* Menhir's error and warning messages are usually more numerous and better
than ocamlyacc's.
A more detailed comparison between ocamlyacc and Menhir appears in Menhir's
documentation.
This is an ALPHA-quality release, so there certainly remain a lot of bugs
to iron out. Nevertheless, we encourage intrepid testers to have a look
and send suggestions and bug reports our way. Thanks for your attention!
Menhir requires ocaml 3.09. The source distribution and the documentation can
be found at
http://pauillac.inria.fr/~fpottier/menhir/menhir-20051212.tar.gz
http://pauillac.inria.fr/~fpottier/menhir/manual.pdf
--
François Pottier and Yann Régis-Gianas
{Francois.Pottier,Yann.Regis-Gianas}@inria.fr
http://pauillac.inria.fr/~fpottier/
http://pauillac.inria.fr/~regisgia/
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.