Previous week Up Next week

Hello

Here is the latest Caml Weekly News, for the week of 07 to 14 February, 2006.

  1. License question: tricky issue
  2. Native code generator on Intel Macs
  3. Toplevel Wish
  4. Position available for O'Caml programmer in Microsoft's TERMINATOR project
  5. C interface style question
  6. (quasi FAQ) object, variants, .... Unbound type parameter [..]

License question: tricky issue

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32155

Alessandro 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.
	

Native code generator on Intel Macs

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32094

Jeff 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.
	

Toplevel Wish

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32199

Jonathan 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
	

Position available for O'Caml programmer in Microsoft's TERMINATOR project

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32204

Byron 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 (bycook@microsoft.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 (bycook@microsoft.com)
	
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

C interface style question

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/31971

Continuing 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.
	

(quasi FAQ) object, variants, .... Unbound type parameter [..]

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/32221

Basile 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.
	

Using folding to read the cwn in vim 6+

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}$'?'&lt;1':1
zM

If you know of a better way, please let me know.


Old cwn

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.


Alan Schmitt