Release 1.06 of Caml Special Light

Release 1.06 of Caml Special Light

[Xavier Leroy]

Announcing Caml Special Light 1.06, the first public release of the
Caml Special Light system.

Caml Special Light is a complete reimplementation of Caml Light that
adds a powerful module system in the style of Standard ML. The module
system is based on the notion of manifest types / translucent sums; it
supports Modula-style separate compilation, and fully transparent
higher-order functors (see the papers in the POPL 94 and 95
proceedings).

Caml Special Light comprises two compilers: a bytecode compiler in the
style of Caml Light (but up to twice as fast), and a high-performance
native code compiler for the following platforms:

        Alpha processors: DecStation 3000 under OSF1
        Sparc processors: Sun Sparcstation under SunOS 4.1 or Solaris 2
        Intel 386 / 486 / Pentium processors: PCs under Linux
        Mips processors: DecStation 3100 and 5000 under Ultrix 4

The native-code compiler delivers excellent performance (better than
Standard ML of New Jersey 1.08 on our tests), while retaining the
moderate memory requirements of the bytecode compiler.

Caml Special Light is still in the experimental state: the base
language has changed and will change again in significant ways,
source-level compatibility is not ensured, the implementation is
alpha-release quality, and many Caml Light tools and libraries have
not yet been ported to Caml Special Light. The present release is
targeted towards testers, adventurous souls, and users with strong
interest in modules and high-performance compilation; other users are
encouraged to stay with Caml Light 0.7 for a while.

The source distribution (for Unix machines only) is available by
anonymous FTP on ftp.inria.fr, directory lang/caml-light.

More information on Caml Special Light is available on the World Wide
Web, at http://pauillac.inria.fr/csl/.

Bug reports and technical questions should be directed to
caml-light@pauillac.inria.fr. For general questions and comments,
use the Caml mailing list caml-list@pauillac.inria.fr (to subscribe:
caml-list-request@pauillac.inria.fr).

- Xavier Leroy

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Caml Special Light                  "Taste Caml in a whole new Light" %
% caml-light@pauillac.inria.fr                                          %
% Projet Cristal, INRIA, B.P.105, 78153 Le Chesnay, France.             %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Suggestions

[Christophe Raffalli]

Hi,

After using Caml-Light (a lot), I think I have few suggestions that might be
worst a discussion:

1) find the bug in this piece of code:

  ...;
  if ... then raise Not_found
  f t;
  ...

You get it ! f t is never called !
Conclusion : there should be a warning when raise got more than one argument.

2) A "match" guard would be really useful in pattern matching: take this
exemple: 

a module with :

type A                      (* abstract type *)
and A' = B | C of A * A;;   

value read : A -> A';;

an implementation of a function f

let f x =
  match read x with 
    B -> ...code1...
  | C (x1,x2) -> 
     (match read x1 with 
       B -> ...code1...
     | C _ -> 
        (match read x2 with
          B -> ...code1...
        | C _ -> ...code2...
        )
     )
;;

code1 is there 3 times !

If we use a match guard:

let f x =
  match read x with
    C(x1,x2) where match read x1, read x2 with C _,C _ -> ...code2...
  | _ -> ...code1...
;;

This make it much simpler, and I have plenty of axemple where this would be
usefull ! Moreover, stream pattern matching can be implemented as a syntactic
suggar for the match guard (with a different semantic that the current one).

3) Order of evaluation is unspecified. I have no problem with that except that
some piece of imperative code can behave differently on different
compiler. Such code should not be allowed or at least give a warning. I
propose the following very simple extension of the type system to detect
ambiguities:

Arrows can be marker with a * 
  (this star does not need to be printed to the user) 

The |- in a typing seqent can be marker too.

Then the typing rules are

Gamma , x : A |- t : B
----------------------
  Gamma |- \x t : A -> B

Gamma , x : A |-* t : B
----------------------
  Gamma |- \x t : A ->* B

Gamma |-r t : A1 ->m1 ... -> An ->mn B    Gamma |-p1 u1 : A1 ... Gamma |-pn An
-----------------------------------------------------------------------------
  Gamma |-r' (t u1 .. un) : B

with
 - r' is star if one of the r m1 .. mn p1 ... pn is star
 - if there is more than one argument and if one of the p1 ... pn is star
   then an ambiguities warning is printed.

now the type of the function doing physical manipulation is marked:

print_string : string ->* unit
:= : 'a ref -> 'a ->* unit
raise : exn ->* 'a
etc ....

the other function are unchanged.

I think we need something like that ! and I think it is really simple !

Hope this help to have a better language ....
Christophe Raffalli

Re: Suggestions

[Pierre Weis]

> 1) there should be a warning when raise got more than one argument.

The problem is due to the raise primitive that returns a polymorphic
argument, which can be applied to anything. It can be exemplified by:

#raise Not_found map it_list;;
Exception non rattrapée: Not_found

I'm sorry to refer once more to Caml V3.1, but here you get:

   CAML (decstation) (V3.1.2) by INRIA Thu Feb 4 

#raise Not_found map it_list;;

line 1: ill-typed phrase, the variable Not_found of type exc
cannot be used with type instance 'a -> exc in
raise Not_found map it_list
1 error in typechecking

Typecheck Failed

This is due to the syntactic treatment of ``raise'': in this version
of Caml, raise is a keyword and applications of raise are treated
explicitely in the parser.

Now, ``raise Not_found map it_list'' is parsed as
 raise (Not_found map it_list). For instance:

#raise failure "foo";;

Evaluation Failed: failure "foo"

This has some drawbacks, since you have to be aware of this special
treatment of raise, when this is just the regular syntactic rule for
application in Caml Light. On the other hand, to treat raise as a
regular primitive leads to very strange programs, since you can
redefine raise.

You may have turned your puzzle as: find out why this program evaluates to ()

#if true then raise Not_found;;
- : unit = ()

Yes, that's because I redefined raise as:

#let raise _ = ();;
raise : 'a -> unit = <fun>

> 2) A "match" guard would be really useful in pattern matching.

>let f x =
>  match read x with
>    C(x1,x2) where match read x1, read x2 with C _,C _ -> ...code2...
>  | _ -> ...code1...
>;;

Why don't you use the ``when'' clauses of Caml Light 0.7?

let f x =
  match read x with
    C (x1, x2) when
     (match read x1, read x2 with
        C _,C _ -> true
      | _ -> false) ->
      ...code2...
  | _ -> ...code1...
;;

Pierre Weis
----------------------------------------------------------------------------
WWW Home Page: http://pauillac.inria.fr/~weis
Projet Cristal
INRIA, BP 105, F-78153 Le Chesnay Cedex (France)
E-mail: Pierre.Weis@inria.fr
Telephone: +33 1 39 63 55 98
Fax: +33 1 39 63 53 30
----------------------------------------------------------------------------

Re: Suggestions

[Christophe Raffalli]

> Why don't you use the ``when'' clauses of Caml Light 0.7?
>
> let f x =
>   match read x with
>    C (x1, x2) when
>     (match read x1, read x2 with
>        C _,C _ -> true
>      | _ -> false) ->
>      ...code2...
>  | _ -> ...code1...
>;;

This is ok in this example, but the problem is that "when" is not a binder !

So if I want to write 

let f x =
  match read x with
    C (x1, x2) when
     (match read x1, read x2 with
        C (x3,x4),C (x5,x6) -> true
      | _ -> false) ->
      ...code2...
  | _ -> ...code1...
;;

x3,x4,x5,x6 are not bound in ...code2... too bad !

With the "where match" match guard it will work and look nicer !

let f x =
  match read x with
    C (x1, x2) where
      match read x1, read x2 with
        C (x3,x4),C (x5,x6) -> ....code2....
  | _ -> ...code1...
;;

The "where match" is in fact strictly more general than the when:

   pat when exp ->

is equivalent to

   pat where match exp with true ->

but the when is weaker because it does not bind any variable.


Christophe Raffalli.

Re: Suggestions

[Pierre Weis]

Continuing the ``where match'' saga ...

> the problem is that "when" is not a binder !

> The "where match" is in fact strictly more general than the when:
>   pat when exp ->
> is equivalent to
>   pat where match exp with true ->
> but the when is weaker because it does not bind any variable.

You're right. In my mind even your ``where'' construct is not general
enough. What you want is the so-called ``continue'' feature of Caml
V3.1: a way to ask the pattern matcher to get out from an already
selected clause (wherever you can be within its expression part).

The continue construct works as this: in a pattern matching like

 | pat -> expr
 | pat' -> expr'
 | ...

a ``continue'' statement within expr will exit from the computation of
expr, and the pattern matching will go on with the next clause
appropriate for pat (presumably pat' -> expr').

Using continue, you can freely mix computation of expr and exits to the rest of
the pattern matching, as in:
 | pat ->
    begin try 
     let x = ... in
     if x > 2 then continue else assoc x l
    with Not_found -> continue end

Furthermore ``continue'' subsumes the ``where match'' you proposed:

 | pat where match expr with pati -> ei

is equivalent to

 | pat -> (match expr with pati -> ei | _ -> continue)

(In fact the implemented ``continue'' statement is a bit more complex:
pattern matchings with continue are named so that you may exit to
another pattern matching from within a more nested one.)

In Caml Light, you may simulate a kind of continue statement, using
exception handling and functionality. This is a bit less efficient and
less readable than a built-in mechanism, but it is acceptable since it
is not so common to need ``continue''...

(
Here is the encoding trick:
Suppose you have a clause pat -> expr that needs a continue statement,
inside a given pattern matching:

 | ...
 | pat -> expr
 | pati -> ei

Then define a Continue exception and an auxiliary function for the
rest of the pattern:

exception Continue;;

let rest = function
 | pati -> ei

Use ``raise Continue'' when you need a continue statement and rewrite
your code as:

 | ...
 | pat as p ->
    begin try expr
    with Continue -> rest p end
 | x -> rest x
)

Pierre Weis
----------------------------------------------------------------------------
WWW Home Page: http://pauillac.inria.fr/~weis
Projet Cristal
INRIA, BP 105, F-78153 Le Chesnay Cedex (France)
E-mail: Pierre.Weis@inria.fr
Telephone: +33 1 39 63 55 98
Fax: +33 1 39 63 53 30
----------------------------------------------------------------------------

Suggestions

[Miles Egan]

Thanks again for all your ideas.  I'm afraid enhancements to
OCaml's container libraries or parsing tools are beyond my abilities at the
moment, even though I think those are both worthwhile projects.  I think I'll
start with some database interfaces and perhaps also investigate OCaml web
scripting.  

Gerd Stolpmann's suggestion that some kind of Corba integretation should be
provided is a good one, I think.  I'd have more luck using OCaml at
work if I could hide it behind IDL.  Has anyone investigated Corba or
COM bindings for OCaml?

( Please excuse the absence of a French translation.  My grade-school French
could only confuse things. )

--
miles

Re: Suggestions

[Jon Moore]

> Gerd Stolpmann's suggestion that some kind of Corba integretation should be
> provided is a good one, I think.  I'd have more luck using OCaml at
> work if I could hide it behind IDL.  Has anyone investigated Corba or
> COM bindings for OCaml?

If anyone decides to pick up on this one, I would suggest having a look at:
"Scripting COM components in Haskell," by Simon Peyton-Jones and Erik Meijer
at 
	http://research.microsoft.com/Users/simonpj/Papers/com.ps.gz

I know similar efforts are ongoing for SML/NJ, and would love to see OCaml
have this too.

Jon
..........
Jonathan Moore                              http://www.cis.upenn.edu/~jonm
University of Pennsylvania                          jonm@dsl.cis.upenn.edu

Re: Suggestions

[Xavier Leroy]

> > Gerd Stolpmann's suggestion that some kind of Corba integretation should be
> > provided is a good one, I think.  I'd have more luck using OCaml at
> > work if I could hide it behind IDL.  Has anyone investigated Corba or
> > COM bindings for OCaml?
> 
> I know similar efforts are ongoing for SML/NJ, and would love to see OCaml
> have this too.

I am currently working on a COM binding for OCaml.  The development is
going relatively smoothly so far.  In particular, OCaml classes and
objects provide a good match for COM's interfaces -- nicer than what
they have to do in Haskell due to lack of OO support.

However, some problems remain, not the least of which being writing a
parser for this #$^#!! Microsoft IDL language, which seems to double in
size approximately every year.

Stay tuned,

- Xavier Leroy