[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Feb 14 01:19:08 PST 2006
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 [..]
========================================================================
1) 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.
========================================================================
2) 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.
========================================================================
3) 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
========================================================================
4) 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 at 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 at 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>
========================================================================
5) 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.
========================================================================
6) (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}$'?'<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
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take
a look at
the archive (<http://sardes.inrialpes.fr/~aschmitt/cwn/>) or the RSS
feed of the
archives (<http://sardes.inrialpes.fr/~aschmitt/cwn/cwn.rss>). If you
also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .
========================================================================
Alan Schmitt, <http://sardes.inrialpes.fr/~aschmitt/>
--
Alan Schmitt <http://sardes.inrialpes.fr/~aschmitt/>
The hacker: someone who figured things out and made something cool
happen.
.O.
..O
OOO
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20060214/d5175c97/PGP.bin
More information about the caml-news-weekly
mailing list