Hello

Here is the latest Caml Weekly News, for the week of 05 to 12 October, 2004.

1. new 64 bit SPARC code generation patch
2. OCaml and doxygen?
3. Free VC++ compiler for the Native Win32 Port Built With MS Visual C?
4. Are you sure the new "=" of 3.08 is good ?
5. Announcing Micmatch: High-Level Regexps for OCaml
6. ocaml nae core foundation (cf-0.4)
7. libwww for OCaml

Archive: http://caml.inria.fr/archives/200410/msg00035.html

A set of patches to ocaml 3.08.1 to generate 64 bit native code on
SPARC systems can be found at this URL:
http://www.mit.edu/~jfc/ocaml-3.08.1-sparc64.tar.gz
This is a new version of the patch I released a few years ago,
rewritten and updated to work with the latest ocaml.

32 or 64 bit mode is selected at configure time based on the compiler
and options passed to the configure script.  In 32 bit mode some
optimizations are added for SPARC V9 when using the -march=v9 option.
I also changed the default architecture level from v7 to v8 in 32 bit
mode because it has been over a decade since Sun sold any workstations
without hardware multiply.

Applications may benefit from 64 bit code if
1. They use objects, other than bigarrays, larger than ~32 MBbyte
2. Total memory use exceeds ~4Gbyte
3. Extensive use is made of int64
4. Extensive use is made of heap-allocated floating point values

On the other hand, the cost of 64 bit code is increased memory use.
A program that I thought would benefit because it used many boxed
integers turned out to run slower.

If you email me to say you are using the patches I will inform you of
bug fixes.  Consider this beta quality because of limited testing.
In addition to any bugs in my code, the machine-independent code
generator appears not to have been tested on a big-endian 64 bit
system.  (I do not think that the ocaml team at INRIA has such a
system.)

I have only tested Solaris 9.  I have no reason to believe that Linux
will not work, but I have no way to test.
    

Archive: http://caml.inria.fr/archives/200410/msg00036.html

To my knowledge http://www.doxygen.org only works with C/C++. Is there any
general-purpose tool that allows one to do something like literate programming
with OCaml?
    

We've been using ocamldoc, which comes with the OCaml distribution,
quite successfully for producing documentation.  It has a few quirks,
such as renaming type parameters in signatures to 'a, 'b, 'c, ... (not
helpful when you're trying to use more descriptive names), but is quite
powerful.  I believe it's fairly similar to doxygen, but have not used
the latter.
    

ocamaweb is a good solution too, but has at this stage not extension (xml
configuration file) for all languages.
it works with MATLAB, awk, visual basic, SAS, etc (in fact, with languages
having only line comments).
it is according to me a good balance between javadoc/doxygen tools (too
close to code structure) and web systems (that need a compilation/tangle
to produce code).
ocamaweb is widely used at miriad technologies for matlab documentations.

http://sourceforge.net/projects/ocamaweb

http://www.literateprogramming.com/ftools.html
    

Interscript (http://interscript.sf.net), Funnelweb,
Noweb, NuWeb, and half a dozen other LP tools work just fine
with *all* languages.

Ocamldoc (available in the standard distro) is
a language dependent documentatiuon tool
like perldoc, doxygen, javadoc etc,

However, please don't confuse this with LP.
LP is universal but invasive, doc tools are language
dependent, don't interoperate, but aren't invasive.
    

I've developed a literate programming tool for Ocaml, ocamlweb. See
http://www.lri.fr/~filliatr/ocamlweb/

You'll find many examples of ocamlweb output on this page:
http://www.lri.fr/~filliatr/software.en.html (looking at the .ps links)

Though ocamlweb  was inspired  by Knuth's WEB  it only  implements the
pretty-printing  and  indexing   features,  not  the  weaving  feature
(i.e. the ability to present pieces  of code in an arbitrary order). I
consider ocaml to be structured enough.  ocamlweb is assuming comments
to be written  in LaTeX (unless declared as  true comments that should
be ignored).

I wrote this  tool to get nice listings of  my code, following Knuth's
principle that a  program should be something as  beautiful as a book,
readable by a human (and not only a machine).
    

We have over 10,000 lines of literate OCaml written using noweb.
http://www.eecs.harvard.edu/~nr/noweb/
    

demexp is also an ocaml program currently made of more than 5,500 lines
using noweb.

Nice point about noweb: it is language agnostic so, for example, demexp
XDR message description is also documented with noweb.

Weak point in relation with ocaml: no pretty-printing of OCaml code. It
should be doable using noweb plugin infrastructure and ocamlweb
pretty-printing code but nobody as done it yet.
    

Archive: http://caml.inria.fr/archives/200410/msg00044.html

I am on a Win2k system and do not have Visual Studio.  I am interested
in generating native code in native mode.  I wonder if anyone could
tell me if one of the versions available on the net will allow me to
use the native Win32 port built with MS Visual C?

   Visual C++ 2005 Express Beta
      http://lab.msdn.microsoft.com/express/visualc/default.aspx
   Visual C++ 2003 Toolkit
      http://msdn.microsoft.com/visualc/vctoolkit2003/

Also, if only the 2003 Toolkit would work, would I need to install the
SDK?
      http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

If MASM doesn't come with them, I think the readme file in the
downloads section gives me plenty of options there.  I'm just not sure
if these .NET compilers will work or even if I am limited to a certain
version of VC++.
    

I am in the same situation, but under winXP.
All that I tried (and succeeded, thanks to email help from Nicolas
Cannasse) is to use ODLL, with microsoft visual compiler and linker steps.
I used XPSP2 PSDK (for libs and headers) and Visual C++ Toolkit 2003 (for
cl.exe and link.exe).

http://www.lehalle.net/clog/index.php?menu=display&table=clog_news&exact=141

hoping it can help you.
    

Here is a brief report of my experience with this issue:

http://caml.inria.fr/archives/200404/msg00823.html
    

> Someone mentioned the mingw toolchain as an alternative. My problem is
> that apparently if you want to use camlidl on Windows platform you
> *have* to use the MS toolchain. Is there any way to use camlidl with
> cygwin (preferably) or mingw?

Yes, some time ago I have made changes to camlidl sources that allow to
compile it with mingw/cygwin-built Ocaml. All Win32 functionality is
supported including building COM DLLs. I can publish the patch to CVS
version of ocamlidl if you are interested.
    

Archive: http://caml.inria.fr/archives/200410/msg00056.html

> I spend one complete day to adapt Phox (my theorem prover) to 3.08
> because the new = does not check first physical equality. Hopefully, the
> backtracking ocamldebugger let me pin point the many "=" which were
> looping, otherwise I would have spend a month !!!

If you get non-termination with the = comparison in 3.08, it means
your program is comparing cyclic data structures, which could also
have caused looping with the old = comparison.  It's just that the new =
loops "more easily" than the old one.  But I would argue that your
original code was living dangerously close to the edge.  Don't feel
bad: in developing 3.08 we found several instances of misuses of =
over cyclic structures (types) in the OCaml compiler...

> I was assuming two things about equal:
> - scan of block from left to right
> - a test on adress equality on pointer before follwing the pointer
> (which is now wrong in 3.08).

That was true of the old implementation, but has never been guaranteed.

As others mentioned, you can recover the behaviour above in 3.08
(it also works in earlier releases) as follows:

let (=?) x y = (Pervasives.compare x y = 0)

and use =? instead of = where appropriate.

> So the comparison between both "=" gives
>
> old "=":
> - can have much better complexity of some specific data structure
> - nan = nan => true
>
> new "="
> - can have a small linear speedup on some specific data structure
> - nan = nan => false
>

You're missing the essential point: the old "=" was inconsistent over
floats, i.e. you'd get different results from the generic = and the
type-specialized = over floats.  Semantic consistency takes precedence
over efficiency.

> Finally, the IEEE norm about floating point arithmetic is not perfect
> yet.

Maybe not, but it's a consensus that took umpteenth years to achieve
(and got Kahan a Turing award), so one needs very very strong reasons
to depart from it.
    

> For LCF-style theorem provers, I think it's quite important that when
> comparing terms (or similar tree structures) for equality, there should
> be a quick "yes" when two high-level subgraphs are pointer eq. [...]
> I guess like Christophe Raffalli I had just assumed this would be
> the case based on long experience with ML-family languages, rather than
> through any explicit discussion in the documentation.

I agree the behaviour your describe (x == y implies x = y) is very
reasonable.  Unfortunately, nan <> nan is also very reasonable, at
least if you believe in IEEE floats, and you cannot have both...

We agonized a long time on this issue before settling on the current
compromise: "=" is compatible with IEEE float equality, and
Pervasives.compare implements the behaviour you expect (early stop if ==).

> Can you clarify what we need to do in order to guarantee this
> behaviour?

As I said in an earlier post, you can do

  let (=?) x y = (Pervasives.compare x y = 0)

and use =? instead of = in places where you need the "early stop" behaviour.

I advise against Damien's suggestion of defining

  let (=) x y = (Pervasives.compare x y = 0)

because the predefined "=" operator is known to the compiler and is
type-specialized to much more efficient code when comparing ints,
floats or strings.  No such type specialization takes place when "="
is defined in terms of Pervasives.compare.

Of course, if the speed of equality is critical, you can also define
your own comparison functions for the types of interest, or even (as
Damien suggested) implement hash-consing.

Hope this clarifies the issue.
    

Archive: http://caml.inria.fr/archives/200410/msg00094.html

Micmatch is a syntax extension of OCaml that allows an easy manipulation
of regular expressions.

Several features have been recently added, and now make it a functional
and handy tool for writing OCaml scripts as well as larger programs.

Micmatch was already providing these features:
  - a Caml-friendly syntax for defining and reusing regexps
    (ocamllex style with more features)
  - no runtime errors due to incorrect regexps
  - a dedicated toplevel
  - a support for regular expressions in the pattern matching constructs
    of OCaml (match ... with ...)

Now it also provides this:
  - a set of macros using a "functional style" (SEARCH, REPLACE,
    COLLECT, SPLIT, ...)
  - a small but useful library for common operations over textual data
  - the possibility of self-executable scripts on Unix systems
  - lazy quantifiers
  - possessive/atomic groups
  - a reference manual

Micmatch programs normally use the PCRE-OCaml library, but can also
use the Str library (with limited features).
    

http://martin.jambon.free.fr/micmatch.html

Sorry for the inconvenience.

People will notice the OCaml logo by Olivier Grisel [1],
based on the famous walking Camel by Pascal Manoury.

Martin.

[1] http://champi.champiland.homelinux.org/~olivier/ocaml-logos.html
    

Archive: http://caml.inria.fr/archives/200410/msg00096.html

The OCaml Network Application Environment (NAE) is a collection of
Objective Caml libraries to support the development of concurrent,
single-threaded Internet application servers.  Its "core foundation"
library (Cf) is currently the only package released in the project (the
others are in the planning and development phases, and are only
available by anonymous CVS).

See the SF.Net project page for more details and download links.

        http://sf.net/projects/ocnae/

The cf-0.4 package is a BETA candidate.  The latest release of Cf
contains only two small changes from the previous release:

        + Fix Makefile for architectures that do not support native
        compilers.
        + Fix serious bug in the [Cf_gadget] scheduler that caused some
        wires to be
          prematurely collected without delivering events to their receivers.

Here is an excerpt from the README:

===== OCaml NAE Core Foundation (cf) library =====

This directory contains the OCaml NAE Core Foundation library, which is
a
collection of miscellaneous extensions to the Objective Caml standard
library.

Highlighted features include:

- Functional streams and stream processors (extended).
- Functional bootstrapped skew-binomial heap.
- Functional red-black binary tree (associative array).
- Functional sets based on red-black binary tree.
- Functional real-time catenable deque.
- Functional LL(x) parsing using state-exception monad.
- Functional lazy deterministic finite automaton (DFA).
- Functional lexical analyzer (using lazy DFA and monadic parser).
- Functional substring list manipulation (message buffer chains).
- Gregorian calendar date manipulation.
- Standard time manipulation.
- System time in Temps Atomique Internationale (TAI).
- Unicode transcoding.
- Extended socket interface (supports IPv6 and UDP w/multicast).
- Universal resource identifier (URI) manipulation.
- I/O event multiplexing (with Unix.select).

Note: see the ISSUES file for a list of open problems in this release.

===== Required Components =====

This library requires the following external components:

- Objective Caml (v3.07+2 or newer)
- Findlib (tested with v0.8.1 and v1.0.4)

Principle development was on Mac OS X 10.3.  The final version of this
library also compiled successfully and passed all self-tests without
warnings
on Suse Linux 9.0 for x86-32.  Other platforms with POSIX-like
environments
should require only a minimal porting effort.

One major open issue: the extended socket interface is broken under
WIN32.
(The author invites help porting the library to other environments.)
    

Archive: http://caml.inria.fr/archives/200410/msg00101.html

> I wonder if anyone has done an OCaml binding for libwww[1].  A cursory
> Google search doesn't turn up anything.
>
> I also wonder if people can comment on libwww vs. Curl (ocurl[2]).  I
> wish to make requests to a webserver and receive the replies.  The
> library must support cookies, and it would be better if it also
> supported keepalives.
>
> [1] http://www.w3.org/Library/
> [2] http://sourceforge.net/projects/ocurl

Netclient is your friend:

http://www.ocaml-programming.de/programming/netclient.html

It is a 100% O'Caml implementation of HTTP/1.1. Take the "experimental"
version, it is quite stable. You get not only keepalives, but also
pipelining and parallel handling of several requests.

The only drawback is that it always downloads into memory.

I guess this library is the reason why there isn't a libwww binding...
    

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