[cwn] Attn: Development Editor, Latest Caml Weekly News

Alan Schmitt alan.schmitt at polytechnique.org
Mon May 7 23:55:33 PDT 2007 

Hello,

Here is the latest Caml Weekly News, for the week of May 01 to 08, 2007.

1) PML: a new language is being born
2) lazy lists
3) How to use C++ library in OCaml?
4) Abstract types in the revised syntax
5) Fedora/OCaml packaging discussion
6) F#

========================================================================
1) PML: a new language is being born
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/ 
e31703471a20ddfe/9eefff537640e43b#9eefff537640e43b>
------------------------------------------------------------------------
** Christophe Raffalli announced:

I am pleased to announce the first EXPERIMENTAL release of PML,
an ML like programming language, which will be extended with a prover  
soon.

In this release, only the programming language is implemented, but I
am interested to hear remarks from the members of this list to try to
get the best possible initial design.

More information, development plan, download and manual are available at

    <http://www.lama.univ-savoie.fr/~raffalli/pml>

The main features of the language are:
- great cartesian product unification (records, modules and objects  
are the
same, arrays are missing and will not be unified)
- polymorphic variant needing no type annotation (but it is a good  
idea to use
some)
- two kinds of inheritance: open inheritance and multiple (closed)  
inheritance
(read the manual to know what this mean) both for records and pattern- 
matching
which are dual in PML.
- etc.
			
========================================================================
2) lazy lists
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/ 
c1712a37bafa186b/9f0428fcf6a2a169#9f0428fcf6a2a169>
------------------------------------------------------------------------
** Loup Vaillant asked and Daniel de Rauglaudre answered:

 > Regular streams are destructive. I was talking about "functional"
 > ones. I didn't try them myself, but the manual says one can perform
 > left recursion with them (thanks to their non destructive nature).

Use camlp4s : the library "fstream" and the syntax extension  
"pa_fstream"
are still there. Access and download from my home page below.
			
========================================================================
3) How to use C++ library in OCaml?
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/ 
fbdc86a31ce29b76/89aeb5d2fbaa4bb8#89aeb5d2fbaa4bb8>
------------------------------------------------------------------------
** Guan asked and Roberto Bagnara answered:

 > I'd like to use the Parma Polyhedra Library
 > (<http://www.cs.unipr.it/ppl/>) to solve the convex-hull and widening
 > problems. Does it work in ocaml? Or any other good tools for ocaml?

The CVS version of the PPL (what will become PPL 0.10) has an OCaml
interface (in addition to C++, C, Prolog and Java interfaces).
This version is not formally released yet, but you can obtain it
by following the instructions at
      <http://www.cs.unipr.it/ppl/Download/cvs#read-only-access>

The OCaml interface has not been heavily tested yet, but we believe
it works OK.  In any case, we will provide all the assistance
you may need.

 > BTW, does ocaml work with the
 > LP_solver(<http://lpsolve.sourceforge.net/5.5/>) library? Or is  
there any
 > good LP solver for ocaml?

The same version of the PPL features also a Mixed Linear/Integer  
Programming
solver based on exact arithmetic.  You can access it from all the  
interfaces,
including the OCaml interface.
			
========================================================================
4) Abstract types in the revised syntax
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/ 
f96bbd4421838955/c0278e387262a106#c0278e387262a106>
------------------------------------------------------------------------
** Nicolas Pouillard explained:

This message concern the few people that use the revised syntax :)

In the revised syntax, abstract types are expressed by defining them
with an unbound type variable:

(* Original *)
type t;;

(* Revised *)
type t = 'a;

The motivation is that looks like an existential type, which is a way
of seeing abstract types.

However I found this motivation misapplied since it doesn't look like
an existential type, there is no exists keyword?!? (type t = exists
'a. 'a;)

It's like a hot-dog without sausage?!?

In fact, consequences of that choice are worst. If forces the
parser/printer to do some semantical operation to convert back and
forth between syntaxes.

type t 'a = 'a; (* not abstract *)

type t 'a = 'b; (* abstract *)

It was considered acceptable, since the test for the freeness of a
single type variable seemed simple because very local.

Indeed only the list of parameters was consulted to compute the
freeness of the type variable.

It seems very weak since highly dependent of future evolution of the  
language.

Nowadays it's no longer sufficient. Constraints can be added with a
type declaration to constrain the type of parameters.

type c 'a = 'b
    constraint 'a = < b : 'b; .. >;
(* Thanks to Till Varoquaux for it's bug report. *)

Clearly I don't want to push that wrong choice further by making more
semantic analysis in the parser/printer.

So I revert back to << type t; >> for abstract types.

Now, what's the new representation for abstract types. OCaml use a
option type, where None represent the abstract type. We can't afford
that, since we want a concrete syntax for everything.
However we have a nil type that can be used as a default case (for
lists of types or optional types).

<:sig_item< type t >> === <:sig_item< type t = $ <:ctyp<>> $ >>

Not that this will also concern abstract module types.

Alas, this will affect existing code using the revised syntax, but
will be easily caught at compilation.

 >From a pragmatic point of view, a grep to show the usage of such  
types:

grep -E "^[ \t]*type.*=[ \t]*'[^ \t]*[ \t]*;[ \t]*$" **/*.ml*
Feel free to share your mind on that subject. The change is not yet
applied to the CVS.
			
** Till Varoquaux then asked and Nicolas Pouillard answered:

 > BTW I still haven't figured out how to generate constraints (lets say
 > I have a list of strings [t1,..,tn] and a list of idents [c1...cn],
 > how do I generate the type < c1:t1; ... ; cn:tn >? )

That way...
open Camlp4.PreCast;;

let mk_obj_type _loc fields types =
   let object_type =
     List.fold_right2 begin fun field typ object_type ->
       <:ctyp< $lid:field$ : $lid:typ$ ; $object_type$ >>
     end fields types <:ctyp<>>
   in
   <:ctyp< < $object_type$ > >>
;;

mk_obj_type (Loc.mk "<test>") ["f1"; "f2"] ["t1"; "t2"];;
			
========================================================================
5) Fedora/OCaml packaging discussion
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/ 
2bf9ff8eb58659cb/28e14764072b1056#28e14764072b1056>
------------------------------------------------------------------------
** Richard Jones said:

Starting here:
<https://www.redhat.com/archives/fedora-devel-list/2007-May/ 
thread.html#00129>
			
========================================================================
6) F#
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/ 
51df11815c2b694b/52a4168cb183c79d#52a4168cb183c79d>
------------------------------------------------------------------------
** In this thread, Don Syme said:

F# is a research language, with many of the same issues as other  
research
languages (license, support, works poorly on some platforms). We  
never think
of it as a replacement for OCaml, though it makes a reasonable  
alternative on
Windows (less so on Linux). I guess as I researcher I think of both as
stepping stones to other better and greater things. I want to see  
this class
of languages live and flourish in many parts of the computing  
industry. Brian
Hurt captured things well here.

There is a overlap between the two (e.g. with Jon's work), but there  
is also a
lot of synergy: I know OCaml is gaining traction in some financial  
companies,
and I can't help think that the existence of F# helps this more than it
hinders it. For example, it helps people make stronger arguments to
management: easier to recruit programmers, gives a way for Java and C#
programmers to retrain in steps. Also, I think an OCaml/F# mix would  
make an
excellent university course, where each language alone would leave  
interesting
issues unaddressed. Perhaps there is also scope for a dual-track  
conference on
both languages.

We've always tried very hard to avoid overlap. For example, you'll  
notice we
don't announce F# releases on the OCaml list - this is out of respect  
for the
OCaml community. Jon operates in both worlds and has books and  
products to
sell, so will be naturally talking about and comparing both systems.  
I think
that's a good thing, and I know he intends his comparisons to be  
informative
rather than destructive.

F# is an independent implementation: it wasn't derived from an  
earlier version
of OCaml (we would have avoided zillions of bugs if we'd done that!).  
We try
to arrange the libraries to get a reasonable degree of compatibility  
with
OCaml 3.08, but are imperfect. We also aim to support cross compilation,
though not perfectly (local adjustments to code may be required, and  
missing
features avoided). We do use OCaml to bootstrap F# for a variety of  
reasons,
though we are moving away from that model.

Jon's assessment of performance under Mono hasn't been independently  
verified.
Any particular performance problem really comes down to a Mono  
v. .NET issue.
Jon should isolate the issue out in a C# program and report it to the  
Mono
team: they will take it seriously. Other users of Mono do not report
catastrophic performance problems (or else no one would use it!)

We understand the current license doesn't meet the standards of the open
source community. We have permission to release the source under a more
permissive license quite similar to Iron Python, and plan to do that.  
However
we probably won't make a big song-and-dance about that, as the way we  
have the
project set up now (binary releases) is really ideal for us as a  
small team.
But emitting the source code under a permissive license now and then  
makes a
lot of sense in order to address some of the issues you mention below.
			
========================================================================
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://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/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://alan.petitepomme.net/>

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: =?ISO-8859-1?Q?Questa_=E8_un_messaggio_firmato_elettronicamente?=
Url : http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20070508/9085761d/attachment.pgp

More information about the caml-news-weekly mailing list