Here is the latest Caml Weekly News, for the week of 07 to 14 February, 2006.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32155Alessandro Baretta asked and Xavier Leroy answered:
> Would the authors/copyright holders consider a tarball containing an Ocaml > source tarball plus other source code and other source tarballs as a > distribution of their software or as a derived work? The question is tricky due > to the non-free public license adopted by Inria originally. > > I ask this question because I would like to release a source distribution for > Ocaml containing all source tarballs and all patches needed to build a complete > AS/Xcaml toolchain. This includes one or more stable ocaml tarballs, an > ocaml-cvs directory (for testing purposes), a metaocaml tarball, and a quite a > few libraries (findlib, pcre-ocaml, ocamlnet, pxp, extlib, postgres and a bunch > more). If I understand the QPL correctly, should this project be considered a > derived work I would not be allowed to distribute it; whereas, if it is > considered a distribution, à la Debian, there should be no problem. > > Notice that all modifications to other peoples code exist in my distribution in > the form of patch files, which are automatically applied before the build > process begins. Sven's reply is perfectly correct: by distributing the Caml source code unmodified, plus modifications as separate patches, you are 100% in compliance with the letter (and the spirit) of the QPL. (Moreover, the QPL + LGPL + exceptions combo we use for OCaml is free software -- even the Debian legal team agrees with that :) So, please go ahead with your distributions plans, this is exactly how we intend the Caml source to be used.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32094Jeff Scofield and Xavier Leroy answered:
> Does anybody know if/when OCaml will be able to run natively (i.e., > generate native code) on the new Intel Macs? Shortly after a new shiny Intel MacBook lands on my desk. The 15" model is however too heavy for my taste; I'm tempted to wait for a smaller, lighter model. > I assume the major > building blocks are already present but the cognoscenti still need to > hook them up the right way. Based on the PowerPC/MacOSX and PowerPC/Linux ports, I'd expect the changes to the x86 code generator to be small. If someone has an Intel Mac and is willing to run a test for me (basically, compile a C file of mine to assembler and mail me the generated assembly), that would help planning the porting work.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32199Jonathan Roewen asked, and both Eric Cooper and Michel Mauny answered:
> I think it would be awesome if the toplevel would be able to spit out > the interface to a module. > > Like: > > # Printf;; > and it prints out a Module = sig ... end of the module if found. > Or like this: (:)) # module P = Printf;; module P : sig val fprintf : out_channel -> ('a, out_channel, unit) format -> 'a val printf : ('a, out_channel, unit) format -> 'a val eprintf : ('a, out_channel, unit) format -> 'a val sprintf : ('a, unit, string) format -> 'a ... Maybe *module _ = Printf ;;* would be slightly more elegant, but the above does work.Jon Harrop added:
Or if you don't want to pollute the namespace with a module called P: # module Printf = Printf;; module Printf : sig val fprintf : out_channel -> ('a, out_channel, unit) format -> 'a val printf : ('a, out_channel, unit) format -> 'a ... end
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32204Byron Cook announced:
Research Software Development Engineer: TERMINATOR project Project website: http://www.research.microsoft.com/terminator Site location: Microsoft Research in Cambridge, UK Contract length: 6 months to start, with negotiation to extend Who to contact: Byron Cook (email@example.com) TERMINATOR is a program termination prover that supports C programs with arbitrarily nested loops or recursive functions, and imperative features such as references, functions with side-effects, and function pointers. TERMINATOR uses a newly discovered method of counterexample-guided abstraction refinement for program termination proofs. The termination argument is constructed incrementally, based on failed proof attempts. TERMINATOR also infers and proves required program invariants on demand. It has been successfully used on Windows device drivers of up to 35,000 lines of code. The TERMINATOR team is looking for someone with functional programming and formal verification experience to develop and maintain the TERMINATOR code-base. Candidates should have the following qualifications: 1) MS. or Ph.D. in Computer Science 2) Experience with ML or an ML-like programming language (TERMINATOR is written primarily in O'Caml, with some C++ and Prolog) 3) Knowledge of algorithms and techniques from automatic formal verification and compilers 4) Good communication and inter-personal skills 5) Leadership and cross-team collaboration skills 6) 2 years of industrial experience (preferred) This position will include the following activities: Fixing bugs in the TERMINATOR code base; providing new features in TERMINATOR; responding to customer feature requests; improving the performance of TERMINATOR, and improving the reliability of TERMINATOR. This is an important position. TERMINATOR is the first known automatic termination prover to support real programs, and solves a problem that is important to reactive systems (i.e. proving that they actually will be able to react). It has the potential to make a huge contribution to how future developers write programs and the quality of the software that we use. Interested? Send a CV to Byron Cook (firstname.lastname@example.org)Goulagman asked and Josh Berdine answered:
> I was just wondering why you didn't use Microsoft's F# language > instead of OCaml. > Have you planned to port it to F# or are you sticking with Ocaml? And > if so, why? (I don't know much about F#). The short answer is that we use both the OCaml and F# compilers for Terminator. There is an answer on the FAQ: http://research.microsoft.com/terminator/faq.htm
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31971Continuing an old thread, Olivier Andrieu asked and Damien Doligez answered:
> in mlvalues.h, I have (with ARCH_ALIGN_DOUBLE undefined) : > > #define Double_val(v) (* (double *)(v)) > #define Double_field(v,i) Double_val((value)((double *)(v) + (i))) > > so &(Double_field(ml_array, 0)) looks pretty equivalent to a simple > cast to double*, no ? You should treat those definitions as abstract. It is purely for efficiency reasons that they are defined as macros. If we decide to change the representation of Caml values (admittedly a pretty remote possibility at this point), the pointer might not point to the first field of the array anymore. For example. it could point to the header, or to the second byte of the contents.
Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32221Basile Starynkevitch asked and Jacques Garrigue answered:
> class virtual ['VarT,'NodeT] myclass = object(self) > method virtual v : 'VarT > method virtual n : 'NodeT > end;; > > type > 'a vart = [> `NothingV | `IntegerV of int | `NodeV of 'a nodet ] > and > 'a nodet = Empty | LeafI of int | ObLeaf of 'a instancet | Node of nodet list > and > 'a instancet = ('a,nodet) myclass constraint 'a = 'a vart > > > I'm getting the following error > > File "ess.ml", line 8, characters 12-66: > Unbound type parameter [..] There are two problems here. One is that your definition of vart is invalid: the ">" introduce a type variable that is bound nowhere (this is the direct cause of the error.) Even if you correct this, another problem is that, in mutually recursive definitions, constraints must be repeated everywhere they are needed. So a straightforward correction would be: type 'a vart = [ `NothingV | `IntegerV of int | `NodeV of 'a ] type 'a nodet = Empty | LeafI of int | ObLeaf of 'a instancet | Node of 'a nodet list constraint 'a = [> 'a nodet vart] and 'a instancet = ('a,'a nodet) myclass constraint 'a = [> 'a nodet vart] Now, I don't know what kind of code you are intending to write, but depending of the kind of parameterization you are using, a functorized version could be more natural: type 'a vart = [ `NothingV | `IntegerV of int | `NodeV of 'a ] module F(X : sig type 'a t = private [> 'a vart] end) = struct type nodet = Empty | LeafI of int | ObLeaf of 'a instancet | Node of 'a nodet list and instancet = <v : nodet X.t; n : nodet> ... end The nice part is that individual constraints disappear: they are fully expressed by the signature of X.
Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).
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.