Hello
Here is the latest Caml Weekly News, for the week of 18 October to 01 November, 2005.
Sorry for not sending a CWN last week: I was in vacations with a very slow internet connection.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30803
Mark Samir asked:
I want to implement a GUI for my program. Provided for rapid development,
I need to a GUI builder. MLGlade and Zoggy are two popular GUI builders. Both
of them are intended for Linux OS but I develop my program in Windows OS. I
tried to compile source code of those tools but I could not do that. Because
There is need to utilities such as ./configure and autoconfig that are not
in Windows OS.
Does any friend know a GUI builder for Windows OS.?
Matthew Hannigan answered:
You might try gazpacho; it's like glade but better.
http://gazpacho.sicem.biz/
There is a windows installer for it.
Jacques Garrigue also answered:
A possible option (as suggested by someone else) would be to use glade
or gazpacho. But you would then need to use the lablgtk binding to
libglade (the runtime part to use a GUI description). It can be
compiled on windows, and it is included in the source distribution,
but not in the binary distribution. You might try to compile it
yourself.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30809
David Baelde asked:
There seems to be many (Fast)CGI implementations in OCaml around:
XCaml, CamlGI, caml-fastcgi, OCamlNet... But many seem dead, or won't
even build. I'm wondering which one should I choose, and I'd be glad
to find some examples or a good doc to start with. Any experiences ? I
hope the OCaml FastCGI community hasn't give up.
Jonathan Bryant answered:
I'm currently working on one for an in-house project I'm doing. I can
post the source if you would like. Currently, request and response
handling are done, cookies are done, and sessions just need a little
tweak to get them working. The persistance of sessions works (rather
nicely I might add, I just need to rewrite them to use cookies, that is
unless someone knows off hand if there is an attribute in the HTTP
headers to start a HTTP session within the web server. There are also
URL en/de-code functions...
The library is in pure OCaml and is (almost) purely functional. No
libraries external to the main OCaml distribution are required.
Maxence Guesdon also answered:
You may have a look at Ocgi:
http://pauillac.inria.fr/~guesdon/Tools/ocgi/
The library includes functions to retrieve arguments and environment
values. Functors can be used to create "models" of cgi handling sessions
with cookie or in parameters. A lot of useful functions are included to
send mails, escaping strings, building HTML structures (list in tables, ...).
At last, a template tool is included to make the use of forms easier
(using generated record types). This tool can also be used to create
templates for html code or even mail bodies (or any text, in fact).
Alessandro Baretta also answered:
We have more or less given up. The AS/Xcaml connects to the HTTP
client over any Netcgi compatible connector. Baretta SRL has
recently commissioned the development of a full HTTP/1.1
implementation to Gerd Stolpmann within the framework of the
Ocamlnet/Netcgi, thus eliminating the need for fastcgi.
Eric Stokes also answered:
The fastcgi support in Ocamlnet is mature and quite stable, and it is
supported in wdialog applications.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30821
Jacques Carette said:
[I am posting this message to caml-list on behalf of Oleg, who is
not a subscriber. I asked him to compose this, as the messages he
points to are just as relevant to Caml programmers as to Haskell
programmers to understand 'the other side' -- Jacques]
Correspondence between ML structures and functors and Haskell type
classes is described in a message:
Applicative translucent functors in Haskell
http://www.haskell.org/pipermail/haskell/2004-August/014463.html
The message is based on a draft paper by Chung-chieh Shan, who showed
the complete translation of Dreyer-Crary-Harper module language into
System Fw. The message attempted to interpret some of Shan's results
in idiomatic Haskell with the full use of type classes. That message
is both Haskell and OCaml literate code. It can be loaded in GHCi or
Hugs -98, and (after some sed filtering) into OCaml.
The upshot of the correspondence between type classes and ML modules
is as follows:
ML signatures correspond to Haskell type classes, and their
implementations to the instances
Abstract types in ML correspond to either uninstantiated or
explicitly quantified type variables in Haskell
Type sharing is expressed via type variable name sharing
Functor (signatures or structures) correspond to Haskell (class
declarations or instances) with type class constraints
The argument of functors is expressed via types, with additional labels
when needed for finer differentiation
Functor applications are done by instance selection based on types
at hand plus the additional labels
OCaml signature attribution operation -- casting the module or
the result of the functor into a desired signature and hiding
the extras -- sometimes involves additional tagging/untagging tricks
(cf. SetESet). This tagging, done via newtype, is syntactic only and
has no run-time effect.
Hiding of information (`sealing', in ML-speak) is done by
existential quantification. To gain applicativity, we quantify over
a higher-ranked type variable (Skolem function proper).
A follow-up message (written together with Chung-chieh Shan)
Applicative translucent functors in Haskell
http://www.haskell.org/pipermail/haskell/2004-September/014515.html
is devoted to the problem of sharing constraints and exponential
explosion and brittleness of ``sharing by construction'' (or
positional sharing). The message translates Harper and Pierce's
example into Haskell, using only the most common Haskell extensions to
give type-equality constraints by name and avoid an exponential
blowup. This exercise suggests that, while type-level records may be
convenient to have in Haskell, they may not be strictly necessary to
express sharing by specification. As shown below, we can indeed refer
to type parameters "by name", taking advantage of the ability of a
Haskell compiler to unify type expressions and bind type variables.
Our technique may be generalizable to encode all sharing by
specification. We hope this message helps clarify the difference
between the two sharing styles, and relate the ML and Haskell
orthodoxies.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30892
Jean-Christophe Filliatre announced:
I've recently translated Hans Boehm's exact real arithmetic library from
Java to ocaml (see http://www.hpl.hp.com/personal/Hans_Boehm/crcalc/)
It is bundled with another exact real arithmetic implementation, and
the two have almost the same interface, so that it is easy to switch
from one to the other.
The library includes a small (exact!) calculator.
You can download the library from
http://www.lri.fr/~filliatr/creal.en.html
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30894
Yaron Minsky announced:
Jane Street Capital (http://janestcapital.com) is a proprietary
trading company located in Manhattan. We're looking for students
interested in internships for the summer of 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.
Summer interns are paid quite well, and we can help out with housing
costs if you don't live nearby. If you're interested, please send a
cover-letter and resume to:
yminsky@janestcapital.com
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30893
Yaron Minsky asked and Gerd Stolpmann answered:
> I've been trying to figure out what the state of OCaml on Windows is,
> and I'm wondering if anyone on the list can help me out. I've been
> trying to get godi, findlib and integration with MS excel going at the
> same time. The problem is that these approaches appear at first
> glance to be incompatible. Here are the dependencies that I know
> about.
>
> 1. Godi works only on cygwin, and isn't supported even with mingw.
Porting Godi to mingw has become quite important. It is now
top-priority, but apparently not simple. A lot of preliminary work has
already been done, especially getting rid of all the C helper programs
(this is not yet released, though), so the port has only to deal with
O'Caml programs and shell scripts.
However, there is no solution in the short term. I expect the release of
the mingw port in summer 2006.
> 2. Findlib works with cygwin -or- mingw, but doesn't work with the native build
This should be doable. Findlib is a pure O'Caml program, and the system
side is very simple. Although I don't know what is going wrong, I
suspect the calling conventions of external programs are different.
Findlib executes ocamlc as subprocess.
> 3. The real windows support (win32 libraries and ocamole, the latter
> of which provides Excel integration), only work with the native build.
I have actually no idea whether this can be ported to mingw, or whether
one can at least link mingw- and msvc-generated libraries together. The
mingw web site says this is possible.
Gerd
> Does anyone have a sense of whether any of these issues can be
> overcome? How much work, for instance, would it take to get findlib
> working on the native win32 build? How about Godi? How about getting
> theings like ocamole working with the mingw build?
After more than one year, there are two new releases for LablGtk2 and
LablGL, respectively interfaces for the Gtk2 GUI library, and the
OpenGL 3D library.
You can find them at:
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgl.html
There are also (semi-)binary releases for windows, that can be
used directly with the OCaml MSVC or mingw ports. ocamlopt is now
supported in binary releases.
For lablgtk, changes are two numerous to write, and include support
for some new 2.6 widgets, and better thread support.
For lablGL, here is the complete list since 1.01:
* fix GlMat.mult_transpose
* correct GlTex.image2d border bug
* add glGetError
* add index_logic_op and color_logic_op
Many people have contributed with bug reports and fixes, and most of
the improvements in lablgtk are by Olivier Andrieu.
(Note that if you got these releases before this annoucement, you may
have jumped the gun: the files were modified several times in the last
24 hours.)
Archive: http://thread.gmane.org/gmane.comp.lang.caml.announce/13
Xavier Leroy announced:
It is my pleasure to announce the release of Objective Caml version 3.09.0,
the "Halloween" release. Be very afraid :)
Novelties in this release include:
- Introduction of private row types, for abstracting the row in object
and variant types. (See Jacques Garrigue's paper, " Private rows:
abstracting the unnamed", available from
http://www.math.nagoya-u.ac.jp/~garrigue/papers/).
- New warnings for variables locally bound and never used.
- A revised implementation of "ocamlopt -pack" that does not depend
on GNU binutils and should work on all platforms supported by ocamlopt.
The downside is that object files intended for later packing should
be compiled with an appropriate "-for-pack" option.
Plus the usual assortment of corrections and small improvements listed
below.
The release can be found at http://caml.inria.fr/ocaml/release
and is currently available as source code and Windows binaries.
More binaries will be added in the coming weeks.
Enjoy,
- Xavier Leroy, for the OCaml development team
----------------------------------------------------------------------
Objective Caml 3.09.0:
----------------------
(Changes that can break existing programs are marked with a "*" )
Language features:
- Introduction of private row types, for abstracting the row in object
and variant types.
Type checking:
- Polymorphic variants with at most one constructor [< `A of t] are no
longer systematically promoted to the exact type [`A of t]. This was
more confusing than useful, and created problems with private row
types.
Both compilers:
- Added warnings 'Y' and 'Z' for local variables that are bound but
never used.
- Added warning for some uses non-returning functions (e.g. raise), when
they are
passed extra arguments, or followed by extra statements.
- Pattern matching: more prudent compilation in case of guards; fixed PR#3780.
- Compilation of classes: reduction in size of generated code.
- Compilation of "module rec" definitions: fixed a bad interaction with
structure coercion (to a more restrictive signature).
Native-code compiler (ocamlopt):
* Revised implementation of the -pack option (packing of several compilation
units into one). The .cmx files that are to be packed with
"ocamlopt -pack -o P.cmx" must be compiled with "ocamlopt -for-pack P".
In exchange for this additional constraint, ocamlopt -pack is now
available on all platforms (no need for binutils).
* Fixed wrong evaluation order for arguments to certain inlined functions.
- Modified code generation for "let rec ... and ..." to reduce compilation
time (which was quadratic in the number of mutually-recursive functions).
- x86 port: support tail-calls for functions with up to 21 arguments.
- AMD64 port, Linux: recover from system stack overflow.
- Sparc port: more portable handling of out-of-bound conditions
on systems other than Solaris.
Standard library:
- Pervasives: faster implementation of close_in, close_out.
set_binary_mode_{out,in} now working correctly under Cygwin.
- Printf: better handling of partial applications of the printf functions.
- Scanf: new function sscanf_format to read a format from a
string. The type of the resulting format is dynamically checked and
should be the type of the template format which is the second argument.
- Scanf: no more spurious lookahead attempt when the end of file condition
is set and a correct token has already been read and could be returned.
Other libraries:
- System threads library: added Thread.sigmask; fixed race condition
in signal handling.
- Bigarray library: fixed bug in Array3.of_array.
- Unix library: use canonical signal numbers in results of Unix.wait*;
hardened Unix.establish_server against EINTR errors.
Run-time system:
- Support platforms where sizeof(void *) = 8 and sizeof(long) = 4.
- Improved and cleaned up implementation of signal handling.
Replay debugger:
- Improved handling of locations in source code.
OCamldoc:
- extensible {foo } syntax
- user can give .txt files on the command line, containing ocamldoc formatted
text, to be able to include bigger texts out of source files
- -o option is now used by the html generator to indicate the prefix
of generated index files (to avoid conflict when a Index module exists
on case-insensitive file systems).
Miscellaneous:
- Configuration information is installed in `ocamlc -where`/Makefile.config
and can be used by client Makefiles or shell scripts.
Damien Doligez added:
> Replay debugger:
> - Improved handling of locations in source code.
Please note that this entails an incompatible change to the ocamldebug-emacs
interface, so you will have to reinstall the emacs mode files when you switch
to 3.09.0.
Aleksey Nogin said:
I have built binary and source RPMs for Fedora Core 2, 3 and 4, Red Hat
Enterprise Linux 3 and 4, and Mandrake 10.1. Get them from
http://rpm.nogin.org/ocaml.html
Aleksey Nogin said and Damien Doligez answered:
> AFAIU, there are two warnings - "Y" for variables bound with let
> and "Z" for variables bound by pattern matching. By default, Y is
> enabled and Z is not.
The rules for Y are a bit complex. They are designed to match our style
of programming, where we sometimes document patterns by giving names to
all the arguments, even if they are unused.
Y will warn you on all variables bound with an "as" (in a let-in or a
match). For the other variables of a let-in pattern, it will warn you
only if all of them are unused. Examples:
let (x, y) = (0, 0) in 0;; (* warning on x and y *)
let (x, y) = (0, 0) in x;; (* no warning *)
let (x, y) as z = (0, 0) in (x, y);; (* warning on z *)
match 1 with _ as z -> 1;; (* warning on z *)
Variables whose names start with _ are always ignored for the
purposes of
these warnings (both Y and Z):
let (_x, y) = (0, 0) in 0;; (* warning on y *)
let (_x, y) = (0, 0) in _x;; (* warning on y *)
Z will warn you on all unused variables bound by "let-in" or "match",
except the ones that are (or would be) reported by Y. Note that it
doesn't
make much sense to have Y disabled and Z enabled.
Pattern-matchings introduced by the "fun" and "function" keywords behave
like the ones that start with "match".
> Use "ocamlc -wA" to enable all the warnings.
That should be "ocamlc -w A" with a space.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30968
Gerd Stolpmann announced:
I just released new versions of some libraries that work for O'Caml
3.09:
- xstrp4 1.6
- PXP 1.1.96 (there also some minor bugfixes in it)
- WDialog 2.1.2
These all failed because of the loc to _loc change in camlp4. Tip: Use
the -loc argument of camlp4 to revert to the old name of this variable,
and you need not to change code. This also works for O'Caml 3.08.
See http://www.ocaml-programming.de/packages/ for download links etc.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30969
Gerd Stolpmann said:
GODI had good success in the transition to 3.09. Although not yet
released, there is already an almost working GODI for 3.09. Especially
useful for developers who want to check their software for 3.09.
To get this release, download the bootstrap archive:
http://www.ocaml-programming.de/packages/godi-bootstrap-20050829.tar.gz
Call the bootstrap script with the additional argument --section 3.09,
e.g.
./bootstrap --section 3.09 --prefix /opt/godi-3.09
then continue as explained in README.
Not all libraries are already available, but most are.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30971
Jeremy O'Donoghue announced:
I've been working to get wxCaml to compile and run using the Microsoft tools.
This seems only to require some small changes to the Makefile, and I
attach a (rather messy) modified version.
The user will need to change
PWD (wxCaml build directory)
OCAMLDIR (Ocaml installation directory)
WXWINDOWS (wxWidgets installation directory)
WXHASKELL (wxHaskell build directory)
VCLIBDIR (Visual Studio library directory)
to reflect the appropriate values for their build environment.
I have added support for both bytecode and native code versions of the
wxcaml library. Both version compile and run the test application, but
both generate a memory leak indication on exit. I will look into this
when time allows.
I can confirm that the wxcaml tarball worked successfully with up to
date versions of wxWidgets and wxHaskell - wxWidgets 2.6.2 and
wxHaskell 0.9.4 in this case.
There appears to be no license file with the wxCaml tarball. I have
licensed the Makefile attached under the wxWindows library license, as
it seems most appropriate (wxWindows and wxHaskell, the main
components use this license).
However, I will be happy to change to any recognised Open Source
license if SooHyoung Oh, the wxCaml author, requests - this
contributon is trivial.
I would prefer that there is some clarity in the licensing of wxCaml
in any case - it is really impossible to do anything more than play
with it until this is done.
(Editor's note: see the archive link for the attachment.)
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30925
Xavier Clerc asked and Jacques Garrigue answered:
> I have a question concerning polymorphic variants and type inference.
> Formulating my question from the example of section 4.2 in the ocaml
> manual (version 3.08), I define a function f:
>
> let f = function
> | `On -> 1
> | `Off -> 0
>
> which is inferred as: val f : [< `Off | `On ] -> int
>
> Then, I use this function in the following expression :
>
> List.map f
>
> which is in turn inferred as: _[< `Off | `On ] list -> int list
>
> My question is about the meaning of the leading underscore in the
> inferred type (given that I understand the meaning of the underscore
> in an expression such as "Stack.create ()" that is inferred as: '_a
> Stack.t).
This is exactly the same meaning: [< `Off | `On] has some form of
flexibility left, which you might see as a type variable, and as such
it obeys the same rules as type variables.
An example close to the above one would be:
# List.map (fun (x,y) -> x+1);;
- : (int * '_a) list -> int list = <fun>
Now you might wonder why '_a cannot be polymorphic in the above
example. That is, could there really be a definition of List.map such
that the polymorphic type would be dangerous (causing a segmentation
fault for instance.) The answer is yes, with a counter-example using
the difference in representation between normal arrays and float
arrays.
Actually, since this counter-example wouldn't apply to the above case
of polymorphic variants, this would probably be safe to leave the
polymorphic variant type as polymorphic...
Xavier Clerc then asked and Jacques Garrigue answered:
> > The answer is yes, with a counter-example using
> > the difference in representation between normal arrays and float
> > arrays.
>
> In this counter-example, it is not clear to me whether the possible
> problem is type-related or runtime-related. I mean, would this
> counter-example still hold if arrays were both boxed or both unboxed ?
No, the difference in representation is essential here.
But at the type level, this problem can be expressed a bit
differently: whether it is safe to add a "top" to the type system,
allowing any type to be coerced to it. While some languages might
allow that, there is no fundamental reason it should be so (an this is
indeed not the case in ocaml.)
If we cannot assume the existence of such a type, then we cannot prove
that polymorphism in this case would be safe.
Note that the property used by the relaxed value restriction, that
one can always add safely a "bottom" to the type system, is much more
reasonable, as it's only assumption is that the representation of
values depend only on (typed) values, not on types alone. This is
valid in ocaml, but some other language might still break it.
> > Actually, since this counter-example wouldn't apply to the above case
> > of polymorphic variants, this would probably be safe to leave the
> > polymorphic variant type as polymorphic...
>
> Does this mean that inferring "[< `Off | `On] list -> int list" would
> be perfectly safe in the example above ?
> (by saying so, I am not pleading for any compiler change, I am just
> trying to organize my thoughts)
I believe so, but I don't have a proof ready for that.
One way to do it would be to prove that any instance of [< `Off | `On]
is a subtype of [ `Off | `On ], which sounds trivial in this case.
So I would say this should apply to both [< ... ] types (closed
polymorphic variants, including the [< ... > ...] case) and <...; ..>
types (extensible object types.) But not to [> ...] types (open
polymorphic variants.)
Xavier Clerc then asked and Jacques Garrigue answered:
> I must admit that I don't grasp the link between the existence of a
> "top" type and the inference of a polymorphic type in the given
> examples. I would expect inference of 'a array in arrays example and
> 'a in "List.map (fun (x, y) -> x + 1)" and don't see in what
> circumstances such types would not be safe (modulo the array
> representation issue discussed above).
> Could you exhibit an example where such inference would be false/
> unsafe ?
Here is the concrete counter-example for top. It uses the (unsafe) Obj
module to produce a segmentation fault, but through an operation that
most people would suppose to be safe.
# let l = [| Obj.repr 1.0 |];;
val l : Obj.t array = [|<abstr>|]
# l.(0) <- Obj.repr 1;;
Segmentation fault
How does it relate to top? Essentially, every ocaml value is
represented by a fixed-size word, either an integer or a
pointer to a boxed representation. All Obj.repr does is return its
argument with type Obj.t, the type of all ocaml values, which we can
see as another name for top. So one could assume that Obj.repr is a
coercion to top. The trouble, as you can see here, is that Obj.t
itself appears to be unsafe. Here l is created as an array, initialized
with a float. This means that internally it will get a float array
representation. Now when we try to put an integer into it, it will try
to use the float array assignment operation, which attempts to
dereference the argument to get its float representation. This
naturally results in a segmentation fault.
As a result we can see here that one assumption in the above must be
false. Since the definition of Obj.repr is exactly that of a coercion
to top, this must mean that adding top to the type system is unsound.
Now, how can I use it to find a problem in the following typing?
# let g = map (fun x -> 1) ;;
val g : 'a list -> int list
I first need a "bad" implementation of map, which uses arrays behind the
scene.
let map f =
let arr = ref [||] in
fun l ->
List.iter
(fun x -> if !arr = [||] then arr := [|x|] else !arr.(0) <- x) l;
List.map f l
val map : ('a -> 'b) -> 'a list -> 'b list
This function just keeps the last list element in a one-element array,
but does nothing with it, so it is exactly equivalent to List.map.
Actually, it cannot do anything bad, as the type system protects me:
# let g = map (fun x -> 1) ;;
val g : '_a list -> int list
But now let's assume that Obj.t is really top, and Obj.repr a safe
operation.
# let g' l = g (List.map Obj.repr l) ;;
val g' : 'a list -> int list
This time we've got the right type.
Let's use it:
# g' [1.0];;
- : int list = [1]
# g' [1];;
Segmentation fault
> Well, the only way to get rid of the leading underscore in inferred
> type is to "use" all the tags of the type (that is "converge" toward
> the upper bound of the variant), as in the following toplevel session :
>
> # let f = function
> | `Off -> 0
> | `On -> 1;;
> val f : [< `Off | `On ] -> int = <fun>
> # let mf = List.map f;;
> val mf : _[< `Off | `On ] list -> int list = <fun>
> # mf [`On];;
> - : int list = [1]
> # mf;;
> - : _[< `Off | `On > `On ] list -> int list = <fun>
> # mf [`Off];;
> - : int list = [0]
> # mf;;
> - : [ `Off | `On ] list -> int list = <fun>
>
> Does this mean that [`Off | `On] list -> int list could be inferred
> for mf as one can pass [`Off | `On] where [< `Off | `On] is waited
> (as [`tag1 | `tag2 ... | `tagn] is shorthand for [< tag1 | `tag2 ...
> | `tagn > tag1 | `tag2 ... | `tagn]).
Certainly, as [`Off|`On] is an instance of [< `Off|`On].
But [`Off] or [`On] are other possible instances of [< `Off|`On], so
the latter is more general.
By the way, you can get your intended type directly with a type
annotation.
# let mf = List.map (f : [`Off|`On] -> _);;
val mf : [ `Off | `On ] list -> int list = <fun>
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30926
Tato Thetza said and Brian Hurt answered:
> sorry I meant
> Ocaml for Experienced Programmers:
> http://www.bogonomicon.com/bblog/book/html/book1.html
This link wasn't really intended for public consumption, so it's been
removed. I forgot to put it in the robots.txt file, so it got out. My
apologies for the inconvience.
The good news is that the Pragmatic Programmers have expressed interest in
publishing the book. They have a "beta book" deal:
http://pragmaticprogrammer.com/starter_kit/faqs/beta_faq.html
I'll see how quickly I can get the book into the program. I probably need
to finish writting it first, however. This is, however, my new job.
Thanks for the good feedback, however.
Yaron Minsky added:
For what it's worth, I've looked at the book too, and found it to be
the best thing of its kind out there. When it's released, we will
definitely buy a few copies.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30986
Gerd Stolpmann announced:
I just managed to get a new version of findlib released. It works now
perfectly (hopefully) with O'Caml 3.09, and you can use all 3.09
command-line arguments.
There are also a number of improvements triggered by discussions:
- The check whether a package is already installed has been
relaxed. In particular, the destination directory may already
exist. It is, however, still not allowed to overwrite files
when packages are installed.
- One can declare files as optional when installing a package.
- One can patch the META file when installing a package.
Currently, there are three types of patches: The version
string can be overwritten. Subpackages can be removed.
Archive references can be removed when the corresponding
files do not exist.
Especially the latter is still experimental because it is
unclear whether it improves anything. The resulting META
file may be broken.
- There is an exists_if variable in META. The idea is to
disable subpackages when a certain file does not exist,
e.g.
package "foo" (
exists_if = "foo.cma"
archive(byte) = "foo.cma"
)
If this package is only optionally built, the exists_if
variable may hide the package.
- The may be a directory with findlib configuration snippets.
If you have findlib.conf.d and put *.conf files into it,
these files will be read.
This is to be used in conjunction with the following...
- It is now possible to drive patched compilers. Assume you
have ocamlc-mypatch which is binary compatible with ocamlc.
It is now possible to use the patched compiler instead of
the regular one with ocamlfind.
First, you need to define the patched toolchain. Use this
in findlib.conf:
ocamlc(mypatch) = "ocamlc-mypatch"
(This works with all findlib.conf parameters.)
Second, you can select this toolchain by:
ocamlfind -toolchain mypatch ocamlc ...
Note that the -toolchain argument is before the command
name.
One should put the toolchain definition into its own
mypatch.conf file for easier installation.
There are also a number of bugfixes.
See http://www.ocaml-programming.de/packages/documentation/findlib/
for documentation and links. See
http://www.ocaml-programming.de/packages/
for downloads.
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.