Hello,

Here is the latest Caml Weekly News, week 22 to 29 October, 2002.

1) GlSurf: surface in OCaml/OpenGL
2) Baire Status
3) Standard library naming scheme
4) email parser in ocamllex/ocamlyacc
5) Question about polymorphic variant
6) Macros and camlp4

======================================================================
1) GlSurf: surface in OCaml/OpenGL
----------------------------------------------------------------------
Christophe Raffalli announced:

I am pleased to announce GlSurf written in OCaml/OpenGL:

  http://www.lama.univ-savoie.fr/~raffalli/glsurf

GlSurf is a program (similar to Surf) to draw surfaces from their
implicit equations (that is drawing the set of points (x,y,z) such that
f(x,y,z) = 0).

It offers an intuitive and simple syntax to construct your functions, it
can draw multiple surfaces simultaneously and it can use all the power
of OpenGl to animate the surface, use transparency, etc ...

Look at the web page and you will want to try it :-)

======================================================================
2) Baire Status
----------------------------------------------------------------------
Diego Olivier Fernandez Pons explained:

I answer here to a few frequently asked questions :

- Baire hasn't changed for more than one month, not that it is
considered ready to release (there is still a lot of work to do) but
the last month I have been working on long term evolution rather than
short term.

- I have been asked (many times) for a better support of english in
Baire (documentation, comments, web-page), and some people would like   
to package it.

In my opinion Baire is not yet ready for packaging and stable official
release. I am preparing a 0.1 version with a better english (hope
multilingual) support, more homogenity, more documentation, (less
bugs), etc.

- I have been asked to change Baire web-site of place (mostly because
of annoying advertising and download times), I also have been asked
for a CVS.

I hope I will be able to put it on the server of the university in a
few weeks but it does not depend only on me.

======================================================================
3) Standard library naming scheme
----------------------------------------------------------------------
Brian Rogoff said:

This is one of those things that's always troubled me (perhaps there's
another petty complaint coming up) about OCaml. In a language with a
hierarchical module system, it seems that we should be able to avoid
such problems by having the standard library packages nested under a
"Std" module, or something like that, so that List, Array, etc., become
Std.List, Std.Array, etc, as we do now for the labeled modules. 

I suppose it's too late now for such a change, but I'm pretty
sympathetic to people who grouse over the fact that lots of good names
are taken.

To which Chris Hecker replied:

It's not too late for a change.  The standard library should be packed
(resulting in the namespaces you mention above), and then a deprecated
backwards-compatibility switch can be added to the compiler that does an
"open Std" before everything, and that should just work (it should be
inserted before the open Pervasives that's currently there).  You'll
have to recompile everything, but you have to do that with ocaml version
changes anyway.  :)

Dmitry Bely replied as well:

That was exactly my proposal some time ago:

http://caml.inria.fr/archives/200208/msg00432.html

(then said about the "being too late" part):

No way! It would only require adding "open Std" to the existing
sources. But we can even introduce it transparately (although I think it is
really not necessary): open Std by default (like Pervasives) and having a 
compiler flag "-nostd" (like "-nopervasives") to disable this auto open.

There is more in this thread at:
http://caml.inria.fr/archives/200210/msg00592.html

======================================================================
4) email parser in ocamllex/ocamlyacc
----------------------------------------------------------------------
Gerd Stolpmann answered a query about an email parser:

Well, O'caml programming is so much fun that everybody wants to
reinvent the wheel. I really understand that, I'm also tempted
every day.

My wheel came into the world in the spring of 2000, and has grown
since that a lot. It is now called "ocamlnet" after the fusion
with Patrick Doane's wheel, and includes not only a parser for RFC(2)822  
messages, but supports also the MIME RFCs (2045-47), RFC 2231,
parsing of dates, the ability to parse from pipelines chunk by
chunk, and last but not least even printers for these (partly
brain-dead) formats. You also find an HTML parser, and a lot of
other useful stuff. It is now more a mobile construction set than
a wheel.

By the way: if anybody has something to contribute, any addition
that is useful, works, and will be maintained is still accepted.

You find it here:

http://sourceforge.net/projects/ocamlnet

======================================================================
5) Question about polymorphic variant
----------------------------------------------------------------------
Christophe Raffalli asked and Jacques Garrigue explained:

> In the following code, f and g typecheck but not h.
> Why ?
> 
> let f = function
>     `a -> 0
>   | `b -> 1
> 
> let g = function
>     `c -> 2
>   |  (`a | `b as x) -> f x
> 
> let h = function
>     `c -> 2
>   |  x -> f x

You must first understand how works type checking for
pattern-matching.  Basically the idea is that you have a list of cases
pat1 -> expr1 | ... | patn -> exprn, and that all patterns and all
expressions have their types unified.  In h this means that x will get
the same type as `c, i.e. [> `c], and will then be unified to the
input type of f : [< `a|`b] -> int. Since `c is not allowed as input
to f, this fails.  (By the way, in ocaml 3.00 h would be accepted, but
with type [< `a|`b] -> int, which is probably nto what you intended.)

The typing of g procedes a bit differently. The type of (`a|`b as x)
will still be [< `a|`b|`c], but the type of x can be restricted to
those actually matched by the pattern it aliases, i.e. [> `a|`b].  As
a result inference succeeds.

Now you might be wondering why in the first place we gave the same
type to all pattern-matching cases. Indeed, if `c is matched first, it
cannot occur anymore in subsequent cases. But the trouble with such an
approach is that it doesn't generalize well: we would need to do
exhaustivity checking before typing, but exhaustivity checking itself
depends on typing.  Even limiting ourselves to trivial cases, this
would add to the confusion by adding variables that refer not to
types, but just to bits of types. So we prefer to keep the more
conservative typing rule for pattern-matching, putting rather the
emphasis on dispatch.

======================================================================
6) Macros and camlp4
----------------------------------------------------------------------
Following a long thread on pattern matching and strings (starting at
http://caml.inria.fr/archives/200210/msg00021.html), Daniel de
Rauglaudre proposed:

I have been thinking to implement that. Proposing a syntax extension
to make macros with Camlp4 (in this case, you don't have to write
Camlp4 code, but just use the extension file). I propose that syntax:
     DEFMACRO <ident> <(optional-parameters)> = <expression/pattern>

where <expression/pattern> is input text which can be interpreted as
expression or pattern (variables, constants, constructors, records).

In this case, the <ident> is added as keyword in the grammar,
evaluated at parse time, transformed into the <expression/pattern>
depending on its position. The possible parameters are possibly
substituted by their actual value in the expression pattern.

We can have also:
     UNDEFMACRO <ident>

To remove it from the grammar.

Would it be OK? General enough? Other propositions? 

then he added, answering questions from Alessandro Baretta:

> Does "evaluated at parse time" mean that you define a syntax 
> tree transformation as opposed to a character stream 
> transformation?

Right. The general idea of Camlp4, anyway, is manipulation of
syntax tree. Every syntax extension work with syntax trees, not  
character stream.

The extension DEFMACRO or DEFINE, which I propose to add in Camlp4,
uses correct syntax trees. The syntax of this construction uses the 
normal lexing and parsing of OCaml expressions. The substitutions of
possible parameters will be scans of the syntax trees and tree
substitution.

(Virtual) Example:

   DEFMACRO f(x) (x, x)
   f(3+y)
   function f(2) -> 0  

would be interpreted as:
   (3+y, 3+y)
   function (2, 2) -> 0

We may be interested in "inlining" with this system: but in this
case, if we accept any expression, it would not work in pattern
position. Example:
   DEFMACRO f(x) (x+3)
   f(2)
would be interpreted as:
   2+3
but
   function f(2) -> 0
has no meaning.

> This is more or less what I had in mind. The only problem 
> with this scheme is probably with compile-time error 
> reporting. If this is not somehow linked with the compiler, 
> how will the compiler be able to tell us that that something 
> we wrote makes no sense?

Indeed if the macro is a complicated expression, the typing error
might be difficult to understand. As location, I can only underline
all the macro call:

   DEFMACRO f(x) (x, "hello")
   function
     (x, y) -> (x + 2, y + 5)
   | f(3) -> (22, 35)
     ^^^^
This pattern has type string and is used with type int.

Something like that...

Finally, Daniel posted a camlp4 syntax extension for macros on the list.
You can find the file at:
http://caml.inria.fr/archives/200210/msg00654.html

======================================================================
Old cwn
----------------------------------------------------------------------

If you happen to miss a cwn, you can send me a message
(alan.schmitt@inria.fr) and I'll mail it to you, or go take a look at
the archive (http://pauillac.inria.fr/~aschmitt/cwn/). If you also wish
to receive it every week by mail, just tell me so.

======================================================================

Alan Schmitt