Here is the latest Caml Weekly News, for the week of May 01 to 08, 2007.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/e31703471a20ddfe/9eefff537640e43b#9eefff537640e43bChristophe 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.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/c1712a37bafa186b/9f0428fcf6a2a169#9f0428fcf6a2a169Loup 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.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/fbdc86a31ce29b76/89aeb5d2fbaa4bb8#89aeb5d2fbaa4bb8Guan 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.
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/f96bbd4421838955/c0278e387262a106#c0278e387262a106Nicolas 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"];;
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/2bf9ff8eb58659cb/28e14764072b1056#28e14764072b1056Richard Jones said:
Starting here: https://www.redhat.com/archives/fedora-devel-list/2007-May/thread.html#00129
Archive: http://groups.google.com/group/fa.caml/browse_frm/thread/51df11815c2b694b/52a4168cb183c79d#52a4168cb183c79dIn 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.
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.