File: tutorial005.html

package info (click to toggle)
ocaml-doc 3.09-1
links: PTS
area: non-free
in suites: etch, etch-m68k
size: 10,428 kB
ctags: 4,963
sloc: ml: 9,244; makefile: 2,413; ansic: 122; sh: 49; asm: 17
file content (1219 lines) | stat: -rw-r--r-- 50,404 bytes
parent folder | download | duplicates (2)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.06">
<TITLE>
 The revised syntax
</TITLE>
</HEAD>
<BODY TEXT=black BGCOLOR=white>
<A HREF="tutorial004.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="tutorial006.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>
<TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#2de52d"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc39"><B><FONT SIZE=6>Chapter&nbsp;5</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=6>The revised syntax</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<A NAME="c:tutrevis"></A>
The revised syntax is an alternative syntax for OCaml. Its purposes
are 1/ fix some problems of the normal syntax (unclosed constructions
sometimes introducing ambiguities, constructors arity, end of top
level phrases and structure items, etc) 2/ avoid unjustified double
constructions (<CODE>":="</CODE> vs ``<CODE>&lt;-</CODE>'', ``fun'' vs ``function'',
``begin..end'' vs parentheses) or concepts (types and types
declarations) 3/ bring some ideas (lists, types). In a word, propose a
syntax which be more logical, simpler, more consistent and easier to
parse and to pretty print.<BR>
<BR>


The revised syntax, being few used, is less constrained by the
history than the normal one, and can try to answer the question: ``how
things should be done'' instead of ``how to remain compatible with old
versions''.<BR>
<BR>


Other motivations are: 1/ show that syntax is just a ``shell'' of the
language: you can change it without modifying the background 2/
experiment right to the end the ability of Camlp4 of doing syntax
extensions.<BR>
<BR>


It is a syntax of the complete language, therefore it can be used for
all OCaml programs: by the way, Camlp4 is itself completely written in
that syntax. Notice that it is not a constraint: it is always possible
to convert from and to the normal syntax, using the pretty print
facilities of Camlp4.<BR>
<BR>


Remark: syntax in programming languages is much a question of personal
taste. This syntax represents mine, with some ideas taken here and
there. Some choices may seem arbitrary (other solutions are possible),
but I tried to keep some consistency, and without being too far from
the normal syntax: I guess that it is possible to understand a program
written in revised syntax even without having read this chapter.<BR>
<BR>


Most of the constructions in revised syntax are therefore the same
than in the normal syntax. This chapter presents only the differences,
and the motivations of them.<BR>
<BR>


The quotations for OCaml syntax trees, which we shall see in next
chapter, use the revised syntax.<BR>
<BR>


<A NAME="toc33"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc40"><B><FONT SIZE=5>5.1</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Practical points</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE><BR>
To compile the file <CODE>foo.ml</CODE> written in revised syntax, use:
<PRE>
            $ ocamlc -pp camlp4r foo.ml
</PRE>
To use the revised syntax in the toplevel, do:
<PRE>
            $ ocaml
            #load "camlp4r.cma";;
</PRE>
<A NAME="toc34"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc41"><B><FONT SIZE=5>5.2</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Phrases</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<UL><LI>In revised syntax, simple semicolons end the items of structures,
signatures and objects. These semicolons are <EM>mandatory</EM>. The
double semicolon is no more a token. There is no ambiguity with the
sequence, which has a special construction (see further).<BR>
<BR>
<LI>The declaration of a global variable is introduced by the keyword
``<CODE>value</CODE>'', ``<CODE>let</CODE>'' being reserved to the construction
``<CODE>let..in</CODE>'':<BR>
<BR>

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>let x = 23;;</tt></td><td><tt>value x = 23;</tt></td></tr>
<tr><td><tt>let x = 23 in x + 7;;</tt></td><td><tt>let x = 23 in x + 7;</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>In interfaces, one must use ``<CODE>value</CODE>'', too, instead of
``<CODE>val</CODE>''.<BR>
<BR>

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>val x : int;;</tt></td><td><tt>value x : int;</tt></td></tr>
</table></center>
</UL>


<FONT SIZE=2><B>Motivation of the simple semicolon</B><BR>
<BR>


The double semicolon in OCaml exists for historical reasons: the first
parsers were driven by the tokens, not by the rules: all constructions
needed to have a specific token.<BR>
<BR>


But because of the introduction of modules in OCaml, the double
semicolon, which was mandatory in Caml Light to end sentences, became
optional: the reason is that in OCaml, a ``phrase'' and a
``structure item'' are actually the same notion. The problem is that
the double semicolon is associated with the idea of ``terminating''
something: for a phrase, it is exact, but not for a structure item
inside a structure, since other structure items and the keyword
``end'' follow.<BR>
<BR>


That choice of letting the double semicolon be optional in normal
syntax has introduced several problems:
</FONT><UL><LI><FONT SIZE=2>A structure item is actually ended by the beginning of the next
structure item; it means that all structure items must start with a
keyword; otherwise there is an ambiguity. For example, you cannot write:
</FONT><PRE><FONT SIZE=2>
     print_string "hello, world"
     print_newline ()
</FONT></PRE>
<FONT SIZE=2>because it is interpreted as a call to </FONT><CODE><FONT SIZE=2>print_string</FONT></CODE><FONT SIZE=2> with 3
parameters (and typing error). The advocated solution is to write:
</FONT><PRE><FONT SIZE=2>
     let _ = print_string "hello, world"
     let _ = print_newline ()
</FONT></PRE>
<FONT SIZE=2>Mmm....</FONT><BR>
<BR>
<LI><FONT SIZE=2>But this solution does not work interactively: in the toplevel, you
cannot ask people to type the beginning of the next sentence to see
the result of the current one. Therefore the double semicolon still
remains! The property that we write in the toplevel like in source
files has been lost.</FONT><BR>
<BR>
<LI><FONT SIZE=2>In structures and objects, the fact that you don't end the
structure items and object items make the programs more difficult to
read. If you write a short object or structure item in one only line,
it is very difficult to see where the items start and end.</FONT></UL>
<FONT SIZE=2>

My opinion is that the structure items should end with a token in a
context where there is never need to read another token. This ensures
a correct behavior in the interactive toplevel. The fact that the
sequence is closed, in the revised syntax, frees the simple semicolon.
And a simple semicolon is perfectly acceptable inside structures and
objects, to end their item, the same way they close a record item. In
the revised syntax, this ending semicolon is mandatory.<BR>
<BR>


It is easier to treat a language whose all phrases end with a token:
at end of the sentences, the characters and the tokens streams are
synchronized (no need to read an extra token to be sure that the
phrase is ended). This property can bring simplifications in other
treatments (extraction of comments or code for documentation,
indentation, editors modes, interactive tools).<BR>
<BR>


<B>Motivation of ``value''</B><BR>
<BR>


The choice of having a different keyword </FONT><CODE><FONT SIZE=2>value</FONT></CODE><FONT SIZE=2> instead of
</FONT><CODE><FONT SIZE=2>let</FONT></CODE><FONT SIZE=2>, for a toplevel value definition, is to mark the difference
with the </FONT><CODE><FONT SIZE=2>let..in</FONT></CODE><FONT SIZE=2> construct. At toplevel, to see if it is a
</FONT><CODE><FONT SIZE=2>let</FONT></CODE><FONT SIZE=2> or or </FONT><CODE><FONT SIZE=2>let..in</FONT></CODE><FONT SIZE=2>, we have to look at the end of the let binding.<BR>
<BR>


In the abstract syntax tree, </FONT><CODE><FONT SIZE=2>let</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>let...in</FONT></CODE><FONT SIZE=2> are very
different: they do not even have the same type: </FONT><CODE><FONT SIZE=2>let</FONT></CODE><FONT SIZE=2> is a
structure item, while </FONT><CODE><FONT SIZE=2>let...in</FONT></CODE><FONT SIZE=2> is an expression. This deserves
to be more visible in the concrete syntax.<BR>
<BR>


Why not </FONT><CODE><FONT SIZE=2>val</FONT></CODE><FONT SIZE=2> instead of </FONT><CODE><FONT SIZE=2>value</FONT></CODE><FONT SIZE=2>? It is to be coherent with
the other declarations </FONT><CODE><FONT SIZE=2>type</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>exception</FONT></CODE><FONT SIZE=2>, which are not
abbreviations: we don't write </FONT><CODE><FONT SIZE=2>typ</FONT></CODE><FONT SIZE=2> for type declarations, nor
</FONT><CODE><FONT SIZE=2>exc</FONT></CODE><FONT SIZE=2> for exception declarations.</FONT><BR>
<BR>
<A NAME="toc35"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc42"><B><FONT SIZE=5>5.3</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Imperative constructions</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<UL><LI>
The sequence is introduced by the keyword
``<CODE>do</CODE>'' followed by ``<CODE>{</CODE>'' and terminated by ``<CODE>}</CODE>''
(it is possible to put a semicolon after the last expression):

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>e1; e2; e3; e4</tt></td><td><tt>do { e1; e2; e3; e4 }</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The body of ``<CODE>for</CODE>'' and ``<CODE>while</CODE>'' has the same
syntax:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>while e1 do</tt></td><td><tt>while e1 do {</tt></td></tr>
<tr><td><tt>&nbsp;&nbsp;e2; e3; e4</tt></td><td><tt>&nbsp;&nbsp;e2; e3; e4</tt></td></tr>
<tr><td><tt>done</tt></td><td><tt>}</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The ``lets'' apply up to the end of the sequences.</UL><FONT SIZE=2>
<B>Motivation of ``do'' and braces</B><BR>
<BR>


First, the sequence needed to be closed. For the reason of the
previous section (toplevel phrases), but also because there are too
many ambiguities with other constructions. For example in the list:
</FONT><PRE><FONT SIZE=2>
     [ a; b; c ]
</FONT></PRE>
<FONT SIZE=2>We know that it is the list of </FONT><CODE><FONT SIZE=2>a</FONT></CODE><FONT SIZE=2>, </FONT><CODE><FONT SIZE=2>b</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>c</FONT></CODE><FONT SIZE=2>. But it
could be interpreted as a list one element, the sequence
</FONT><CODE><FONT SIZE=2>"a; b; c"</FONT></CODE><FONT SIZE=2>. In the grammar, it supposes that list items are not
``top'' expressions (expressions of the first level of the ``expr''
grammar entry): it is mandatory to use things like ``expression-1'' or
``simple expression'' in the grammar.<BR>
<BR>


In revised syntax, this case never occurs: when a rule needs an
expression, it always uses the top level of the ``expr'' entry. The
grammar is then simpler and easier to read and understand.<BR>
<BR>


The choice of </FONT><CODE><FONT SIZE=2>"do"</FONT></CODE><FONT SIZE=2> followed by braces has something
arbitrary. However, the keyword </FONT><CODE><FONT SIZE=2>"do"</FONT></CODE><FONT SIZE=2> let us easily think of
something imperative (not functional). And the braces remind the
sequence in the C language.<BR>
<BR>


Why not </FONT><CODE><FONT SIZE=2>do..done</FONT></CODE><FONT SIZE=2>? Question of taste. It could have been
</FONT><CODE><FONT SIZE=2>do..done</FONT></CODE><FONT SIZE=2>. The idea is to remain relatively discrete. And the
proposed construction saves a keyword.<BR>
<BR>


Note that a </FONT><CODE><FONT SIZE=2>let...in</FONT></CODE><FONT SIZE=2> in the sequence applies up to the end of
the sequence, like in normal syntax. However, in normal syntax,
because of the fact that the sequence is an opened construction, you
can obtain strange results. In the example:
</FONT><PRE><FONT SIZE=2>
     if condition then
        a-simple-statement;
     statement-2;
     statement-3;
</FONT></PRE>
<FONT SIZE=2>Let us suppose that you need to add a let binding for the ``simple
statement'': if you just add it, this is what you see:
</FONT><PRE><FONT SIZE=2>
     if condition then
        let v = expr in
        a-simple-statement;
     statement-2;
     statement-3;
</FONT></PRE>
<FONT SIZE=2>But what you get is actually:
</FONT><PRE><FONT SIZE=2>
     if condition then
        let v = expr in
        a-simple-statement;
        statement-2;
        statement-3;
</FONT></PRE>
<FONT SIZE=2>The </FONT><CODE><FONT SIZE=2>let</FONT></CODE><FONT SIZE=2> has ``absorbed'' the rest of the sequence, which is now
included in the if condition. To be correct, you need to add an
enclosing </FONT><CODE><FONT SIZE=2>begin..end</FONT></CODE><FONT SIZE=2> or parentheses.</FONT><BR>
<BR>
<A NAME="toc36"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc43"><B><FONT SIZE=5>5.4</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Tuples and lists</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<UL><LI>
Parentheses are mandatory in tuples:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>1, "hello", World</tt></td><td><tt>(1, "hello", World)</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>Lists are always enclosed with ``<CODE>[</CODE>'' and ``<CODE>]</CODE>''.
Their syntax is:
<DIV ALIGN=center>
<TABLE CELLSPACING=2 CELLPADDING=0>
<TR><TD ALIGN=left NOWRAP><EM>list</EM></TD>
<TD ALIGN=right NOWRAP>::=</TD>
<TD ALIGN=left NOWRAP><CODE>[</CODE> <EM>elem-list opt-cons</EM> <CODE>]</CODE></TD>
</TR>
<TR><TD ALIGN=left NOWRAP><EM>elem-list</EM></TD>
<TD ALIGN=right NOWRAP>::=</TD>
<TD ALIGN=left NOWRAP><EM>expression</EM> <CODE>;</CODE> <EM>elem-list</EM> |
<EM>expression</EM></TD>
</TR>
<TR><TD ALIGN=left NOWRAP><EM>opt-cons</EM></TD>
<TD ALIGN=right NOWRAP>::=</TD>
<TD ALIGN=left NOWRAP><CODE>::</CODE> <EM>expression</EM> | <EM>(*empty*)</EM></TD>
</TR></TABLE>
</DIV>
A list is a sequence of expressions separated by semicolons, optionally
ended by a ``<CODE>::</CODE>'' and an expression, the whole being always enclosed
by brackets.
Examples:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>x::y</tt></td><td><tt>[x::y]</tt></td></tr>
<tr><td><tt>[x; y; z]</tt></td><td><tt>[x; y; z]</tt></td></tr>
<tr><td><tt>x::y::z::t</tt></td><td><tt>[x::[y::[z::t]]]</tt></td></tr>
<tr><td><tt>x::y::z::t</tt></td><td><tt>[x; y; z :: t]</tt></td></tr>
</table></center>
Note the two ways to write the last case.</UL><FONT SIZE=2>
<B>Motivation to close the tuples by parentheses</B><BR>
<BR>


In mathematics, tuples are always between parentheses.<BR>
<BR>


Moreover, it is in a general policy of the revised syntax: close more
constructions: it is easier to read and don't need to learn certain
subtle precedences levels.<BR>
<BR>


<B>Motivation for the syntax of lists</B><BR>
<BR>


In revised syntax, the lists are always closed. Be a ``cons''
</FONT><CODE><FONT SIZE=2>[a :: b]</FONT></CODE><FONT SIZE=2> or an enumeration of all items
</FONT><CODE><FONT SIZE=2>[a; b; c]</FONT></CODE><FONT SIZE=2>, we always know syntactically where a list starts
and when it ends.<BR>
<BR>


This syntax have something similar of the lists in Lisp: the brackets
are like the parentheses, the semicolons are like the spaces and the
double colon is like the dot.<BR>
<BR>


Moreover, the syntax:
</FONT><PRE><FONT SIZE=2>
     [ x; y; z :: t ]
</FONT></PRE>
<FONT SIZE=2>is more understandable and more logical than the equivalent in normal
syntax:
</FONT><PRE><FONT SIZE=2>
     x :: y :: z :: t
</FONT></PRE>
<FONT SIZE=2>Indeed, reading it in normal syntax, the types are not clear:
</FONT><CODE><FONT SIZE=2>x</FONT></CODE><FONT SIZE=2>, </FONT><CODE><FONT SIZE=2>y</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>z</FONT></CODE><FONT SIZE=2> are not of same type than </FONT><CODE><FONT SIZE=2>t</FONT></CODE><FONT SIZE=2>, we
have to remember that this double colon is right associative, which is
generally not natural. In revised syntax, </FONT><CODE><FONT SIZE=2>x</FONT></CODE><FONT SIZE=2>, </FONT><CODE><FONT SIZE=2>y</FONT></CODE><FONT SIZE=2>, and
</FONT><CODE><FONT SIZE=2>z</FONT></CODE><FONT SIZE=2> are at the same level (separated by semicolons), different
from the one of </FONT><CODE><FONT SIZE=2>t</FONT></CODE><FONT SIZE=2> (separated from the rest by the double
colon).<BR>
<BR>


In revised syntax, it is clear that </FONT><CODE><FONT SIZE=2>x</FONT></CODE><FONT SIZE=2>, </FONT><CODE><FONT SIZE=2>y</FONT></CODE><FONT SIZE=2> and
</FONT><CODE><FONT SIZE=2>z</FONT></CODE><FONT SIZE=2> are the first items of the list, because the syntax is
identical when the list is ended by a ``cons'' and when it is not,
what is not the case in normal syntax.</FONT><BR>
<BR>
<A NAME="toc37"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc44"><B><FONT SIZE=5>5.5</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Irrefutable patterns</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE><BR>
There is a notion of ``irrefutable patterns'' used by some syntactic
constructions (next sections). Matching against these patterns never
fails. An ``irrefutable pattern'' is either:
<UL><LI>
A variable.
<LI>The wildcard ``<CODE>_</CODE>''.
<LI>The constructor ``<CODE>()</CODE>''.
<LI>A tuple with irrefutable patterns.
<LI>A record with irrefutable patterns.
<LI>An irrefutable pattern with a type constraint.
</UL>
Note that the term ``irrefutable'' does not apply to all patterns
which never fail: constructors alone in their type definition,
except ``<CODE>()</CODE>'', are not said ``irrefutable'' (the fact that
they be alone or not cannot be determined at parsing time).<BR>
<BR>
<A NAME="toc38"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc45"><B><FONT SIZE=5>5.6</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Constructions with matching</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<UL><LI>
The keyword ``<CODE>function</CODE>'' no longer exists. One must use
only ``<CODE>fun</CODE>''.<BR>
<BR>
<LI>The pattern matchings, in constructions with ``<CODE>fun</CODE>'',
``<CODE>match</CODE>'' and ``<CODE>try</CODE>'' are closed by brackets: an open
bracket ``<CODE>[</CODE>'' before the first case, and a close bracket
``<CODE>]</CODE>'' after the last case:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>match e with</tt></td><td><tt>match e with</tt></td></tr>
<tr><td><tt>&nbsp;&nbsp;p1 -> e1</tt></td><td><tt>[ p1 -> e1</tt></td></tr>
<tr><td><tt>| p2 -> e2;;</tt></td><td><tt>| p2 -> e2 ];</tt></td></tr>

<tr><td><tt>fun x -> x;;</tt></td><td><tt>fun [x -> x];</tt></td></tr>
</table></center>
But if there is only one case and if the pattern is <EM>irrefutable</EM>, the brackets are not mandatory. These examples work
identically in normal and revised syntaxes:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>fun x -> x</tt></td><td><tt>fun x -> x</tt></td></tr>
<tr><td><tt>fun {foo=(y, _)} -> y</tt></td><td><tt>fun {foo=(y, _)} -> y</tt></td></tr>
</table></center>
Notice that in revised syntax, both <CODE>fun [ x -&gt; x ]</CODE> and
<CODE>fun x -&gt; x</CODE> are correct.
The currified pattern matching can be done with ``<CODE>fun</CODE>'' without
brackets, but only with <EM>irrefutable</EM> patterns:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>fun x (y, z) -> t</tt></td><td><tt>fun x (y, z) -> t</tt></td></tr>
<tr><td><tt>fun x y (C z) -> t</tt></td><td><tt>fun x y -> fun [C z -> t]</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>It is possible to write the empty function,
raising the exception ``<CODE>Match_failure</CODE>'' whichever parameter is
applied, the empty ``match'', raising ``<CODE>Match_failure</CODE>'' after
having evaluated its expression, and the empty ``try'', equivalent to
its expression without <CODE>try</CODE>:
<PRE>
    fun []
    match e with []
    try e with []
</PRE><BR>
<BR>
<LI>The patterns after ``<CODE>let</CODE>'' and ``<CODE>value</CODE>'' must be
irrefutable. The following OCaml expression:
<PRE>
    let f (x::y) = ...
</PRE>must be written in revised syntax:
<PRE>
    let f = fun [ [x::y] -&gt; ...
</PRE><BR>
<BR>
<LI>It is possible to use a construction ``<CODE>where</CODE>'', it is a
reversed ``<CODE>let</CODE>'', but one can write only one bind:
<PRE>
     e where x = y
</PRE></UL><FONT SIZE=2>
<B>Motivation for one alone keyword ``fun''</B><BR>
<BR>


The presence of </FONT><CODE><FONT SIZE=2>fun</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>function</FONT></CODE><FONT SIZE=2> is somewhat strange,
since they have the same semantics.<BR>
<BR>


In revised syntax, by adding this notion of ``irrefutable patterns'',
there is no ambiguity: a list not being an irrefutable pattern, the
construction with brackets is not a parsing problem. When using
an irrefutable pattern, there must be only one case, and therefore no
close construction is necessary, allowing us to keep the simple
frequent form: </FONT><CODE><FONT SIZE=2>fun x -&gt; x</FONT></CODE><FONT SIZE=2>.<BR>
<BR>


<B>Motivation to close the constructions</B><BR>
<BR>


It is to avoid the problem of the ``dangling bar'' (the same than the
``dangling else'' in the ``if'' construct). In normal syntax, this
program:
</FONT><PRE><FONT SIZE=2>
     match ... with
       case1 -&gt;
         match ... with
           case11 -&gt; ...
         | case12 -&gt; ...
     | case2 -&gt; ...
</FONT></PRE>
<FONT SIZE=2>is wrongly interpreted: to obtain what you want, you need to use
parentheses or </FONT><CODE><FONT SIZE=2>begin..end</FONT></CODE><FONT SIZE=2> to close the internal </FONT><CODE><FONT SIZE=2>match</FONT></CODE><FONT SIZE=2>
construct. There is a same problem with the </FONT><CODE><FONT SIZE=2>if</FONT></CODE><FONT SIZE=2> construct,
because of the optional </FONT><CODE><FONT SIZE=2>else</FONT></CODE><FONT SIZE=2> (see further).<BR>
<BR>


I admit that the fact that all cases do not start with the same token
(the first starting with a left brace, the other ones with a vertical
bar) is not practical in editing programs: it is indeed complicated to
exchange the first case and the other ones. However readability and
absence of ambiguity are more important than easiness to use and
absence of verbosity: when it is easy to edit but risk to introduce
bugs or irregularities, it is not sure that it be better.<BR>
<BR>


Why not close the construction by a keyword, </FONT><CODE><FONT SIZE=2>end</FONT></CODE><FONT SIZE=2> for example,
like the </FONT><CODE><FONT SIZE=2>Ada</FONT></CODE><FONT SIZE=2> language does? It is because an ending keyword
gives an idea of something imperative, it does not make think that
something is returned, which is however the case in the </FONT><CODE><FONT SIZE=2>match</FONT></CODE><FONT SIZE=2>
construct, like most of </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2> constructs.<BR>
<BR>


<B>Motivation for the empty forms</B><BR>
<BR>


The empty function is useful for initial cases of iterations or initial
references values. It is not absolutely essential since it is possible
to write:
</FONT><PRE><FONT SIZE=2>
     fun _ -&gt; assert False
</FONT></PRE><FONT SIZE=2>The empty </FONT><CODE><FONT SIZE=2>match</FONT></CODE><FONT SIZE=2> existed before the introduction of the
</FONT><CODE><FONT SIZE=2>assert</FONT></CODE><FONT SIZE=2> construction in </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2>. Like the assert, it
indicates the position of the error in the file.<BR>
<BR>


These constructions are there because they are the limit when the
number of the matching cases reach zero.<BR>
<BR>


<B>Motivation for irrefutable patterns in ``let''</B><BR>
<BR>


In normal syntax, if you use a ``let'' binding with a non irrefutable
pattern, you get a typing message ``pattern matching is not
exhaustive''. If you want to be clean and add the missing cases, you
have to torture your sources. Indeed, for example, the
</FONT><PRE><FONT SIZE=2>
     let x :: y = a in b
</FONT></PRE><FONT SIZE=2>must be changed into:
</FONT><PRE><FONT SIZE=2>
     match a with x :: y -&gt; b | ...
</FONT></PRE>
<FONT SIZE=2>In revised syntax, since it is forbidden, you are never in this situation.<BR>
<BR>


<B>Motivation for the ``where'' construct</B><BR>
<BR>


This construction existed in the old ``Caml'' V3.1 (whose development
was stopped by the beginning of the 90ies) and I liked it much. There
was a problem in this construct, because it was possible to add
several bindings separated with ``and'', which sometimes could enter
in conflict (another ``dangling'' case) with a possible ``and'' in an
enclosing ``let'':
</FONT><PRE><FONT SIZE=2>
          let a =
             b where c = d
          and e = f in ...
</FONT></PRE><FONT SIZE=2>In this situation, the ``where'' construct used to ``absorb'' the
``and'' of the ``let'' binding. The program was interpreted as:
</FONT><PRE><FONT SIZE=2>
          let a =
             b where c = d and e = f
          in ...
</FONT></PRE>
<FONT SIZE=2>Because of that, in </FONT><CODE><FONT SIZE=2>Caml Light</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2>, the ``where''
construction were removed. But a ``where'' with only one binding could
works. Anyway, having several bindings is not interesting nor useful nor
readable, in this construction.<BR>
<BR>


I personally use this construction in the case when the ``let''
binding is a function definition and the expression a call to this
function. I generally prefer to write:
</FONT><PRE><FONT SIZE=2>
             loop 0 where rec loop i = ...
</FONT></PRE>
<FONT SIZE=2>than the equivalent form:
</FONT><PRE><FONT SIZE=2>
             let loop i = ... in loop 0
</FONT></PRE>
<FONT SIZE=2>I consider the form with </FONT><CODE><FONT SIZE=2>where</FONT></CODE><FONT SIZE=2> more readable in this situation.</FONT><BR>
<BR>
<A NAME="toc39"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc46"><B><FONT SIZE=5>5.7</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Mutables and assignment</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<UL><LI>
The statement ``<CODE>&lt;-</CODE>'' is written ``<CODE>:=</CODE>'':

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>x.f <- y</tt></td><td><tt>x.f := y</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The ``<CODE>ref</CODE>'' type is used as if its field label was 
named ``<CODE>val</CODE>'', instead of ``<CODE>contents</CODE>''. The operator
``<CODE>!</CODE>'' does not exist any more, and references are assigned like
the other mutables:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>x := !x + y</tt></td><td><tt>x.val := x.val + y</tt></td></tr>
</table></center>
</UL>


<FONT SIZE=2><B>Motivation</B><BR>
<BR>


Having two constructions for the assignment is abnormal. In normal
syntax, the </FONT><CODE><FONT SIZE=2>":="</FONT></CODE><FONT SIZE=2>, specific to the </FONT><CODE><FONT SIZE=2>ref</FONT></CODE><FONT SIZE=2> type, is an old
rest of the time when references where implemented with a constructor
(there were mutable constructors, then), and the codes to extract a
reference value and to change it were complicated:
</FONT><PRE><FONT SIZE=2>
            match x with Ref x -&gt; x
            match x with Ref x -&gt; x &lt;- y
</FONT></PRE>
<FONT SIZE=2>It was then justified to have specific constructions </FONT><CODE><FONT SIZE=2>"!x"</FONT></CODE><FONT SIZE=2> and
</FONT><CODE><FONT SIZE=2>"x := y"</FONT></CODE><FONT SIZE=2> for these cases. Now, references are implemented with
a record type, and these constructions can be written:
</FONT><PRE><FONT SIZE=2>
            x.contents
            x.contents &lt;- y
</FONT></PRE>
<FONT SIZE=2>In normal syntax, there are 2 ways to access and assign references,
although the method using the label ``contents'' is rarely used. In
revised syntax, it is the only method. However, I consider
``contents'' as a too long identifier, it is why I changed it into
``val''. It is actually not a change in the definition of </FONT><CODE><FONT SIZE=2>ref</FONT></CODE><FONT SIZE=2>
(since </FONT><CODE><FONT SIZE=2>Camlp4</FONT></CODE><FONT SIZE=2> does only syntax), it is changed in the syntax
trees, the real name of the field remaining ``contents''.<BR>
<BR>


As </FONT><CODE><FONT SIZE=2>":="</FONT></CODE><FONT SIZE=2> is no more necessary with the semantics of assigning a
reference value, it can be used in the place of </FONT><CODE><FONT SIZE=2>"&lt;-"</FONT></CODE><FONT SIZE=2>, a token
less natural and introducing confusions (when we read it) with the
</FONT><CODE><FONT SIZE=2>"-&gt;"</FONT></CODE><FONT SIZE=2> of the functions and pattern matchings.<BR>
<BR>


The construction </FONT><CODE><FONT SIZE=2>!x</FONT></CODE><FONT SIZE=2> is no more necessary either since we can
write </FONT><CODE><FONT SIZE=2>x.val</FONT></CODE><FONT SIZE=2>. We then save two tokens which were used only for
the reference type.</FONT><BR>
<BR>
<A NAME="toc40"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc47"><B><FONT SIZE=5>5.8</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Types</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<A NAME="Types"></A>
<UL><LI>
The type constructors are before their type parameters, which
are written with the currified form:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>int list</tt></td><td><tt>list int</tt></td></tr>
<tr><td><tt>('a, bool) Hashtbl.t</tt></td><td><tt>Hashtbl.t 'a bool</tt></td></tr>
<tr><td><tt>type 'a foo =</tt></td><td><tt>type foo 'a =</tt></td></tr>
<tr><td><tt>&nbsp;&nbsp;&nbsp;'a list list;;</tt></td><td><tt>&nbsp;&nbsp;&nbsp;list (list 'a);</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The abstract types are represented by a unbound type variable:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>type 'a foo;;</tt></td><td><tt>type foo 'a = 'b;</tt></td></tr>
<tr><td><tt>type bar;;</tt></td><td><tt>type bar = 'a;</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>Parentheses are mandatory in tuples of types:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>int * bool</tt></td><td><tt>(int * bool)</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>In declaration of a concrete type, brackets must enclose
the constructors declarations:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>type t = A of i | B;;</tt></td><td><tt>type t = [ A of i | B ];</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>It is possible to make the empty type, without constructor:
<PRE>
    type foo = [];
</PRE><BR>
<BR>
<LI>There is a syntax difference between data constructors with
several parameters and data constructors with one parameter of type
tuple.<BR>
<BR>
The declaration of a data constructor with several parameters is
done by separating the types with ``<CODE>and</CODE>''. In expressions and
patterns, this constructor parameters must be currified:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>type t = C of t1 * t2;;</tt></td><td><tt>type t = [ C of t1 and t2 ];</tt></td></tr>
<tr><td><tt>C (x, y);;</tt></td><td><tt>C x y;</tt></td></tr>
</table></center>
<BR>
<BR>
The declaration of a data constructor with one parameter of type
tuple is done by using a tuple type. In expressions and patterns,
the parameter has not to be currified, since it is alone:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>type t = D of (t1 * t2);;</tt></td><td><tt>type t = [ D of (t1 * t2) ];</tt></td></tr>
<tr><td><tt>D (x, y);;</tt></td><td><tt>D (x, y);</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The predefined constructors ``<CODE>True</CODE>'' and ``<CODE>False</CODE>''
start with an uppercase letter.<BR>
<BR>
<LI>In record types, the keyword ``<CODE>mutable</CODE>'' must appear
after the colon:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>type t = {mutable x : t1};;</tt></td><td><tt>type t = {x : mutable t1};</tt></td></tr>
</table></center>
</UL>


<FONT SIZE=2><B>Motivation for the applying order of type constructors</B><BR>
<BR>


The order is to look like the constructors values: you can then read
value in the same order than their types. The syntax with
currification style is used also for value constructors.<BR>
<BR>


<B>Motivation for the abstract types syntax</B><BR>
<BR>


It was to look like existential types, because abstract types are
actually some kind of existential types. This may have a meaning if
existential types are included one day in </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2>.<BR>
<BR>


<B>Motivation for the parentheses around tuple types</B><BR>
<BR>


Close more constructions. Closed like tuples are. Moreover it is more
visible in constructor declarations to differentiate the case of two
parameters and one parameter being a tuple.<BR>
<BR>


<B>Motivation for the constructor declaration type</B><BR>
<BR>


The revised syntax have tried to be the most general possible, to plan
the possible future extensions of the language.<BR>
<BR>


Record types are closed by braces (no change). Symmetrically, the sum
types (declaring constructors) are closed by brackets. This is also a
way to consider them just as ``types''. We could imagine that they be
authorized one day outside type declarations. For example like this:
</FONT><PRE><FONT SIZE=2>
            fun (x : [ A | B ]) -&gt; ...
            type t = { lab : [ A | B ] }
            type u = [ C of { lab : ...} ]
</FONT></PRE>
<FONT SIZE=2>The form of the last line is, by the way, the method used in the
language </FONT><CODE><FONT SIZE=2>SML</FONT></CODE><FONT SIZE=2>, where record types are always anonymous.<BR>
<BR>


In </FONT><CODE><FONT SIZE=2>Camlp4</FONT></CODE><FONT SIZE=2> abstract syntax, there is no notion of ``type
declaration'': a type declaration is just a type. The fact that sum
types and record types are accepted only in type declarations is done
when converting into the abstract syntax which </FONT><CODE><FONT SIZE=2>ocamlc</FONT></CODE><FONT SIZE=2> uses.<BR>
<BR>


<B>Motivation for the empty type</B><BR>
<BR>


As the type constructor definition is closed, it is possible to
imagine the empty type. Not very useful, but we have it without any
cost: a type inhabited by nothing (empty set).<BR>
<BR>


<B>Motivation for the currified syntax for constructors</B><BR>
<BR>


This reflects the actual semantics. There are indeed two cases, and
the values in the two cases are implemented differently. The arity of
constructors are more clear.<BR>
<BR>


In normal syntax, it is difficult to understand (and to explain) why
if C is a constructor with two parameters, this is accepted:
</FONT><PRE><FONT SIZE=2>
            fun C (x, y) -&gt; (x, y)
</FONT></PRE><FONT SIZE=2>but not that:
</FONT><PRE><FONT SIZE=2>
            fun C x -&gt; x
</FONT></PRE>
<FONT SIZE=2>In revised syntax you have to write:
</FONT><PRE><FONT SIZE=2>
            fun [ C x y -&gt; (x, y) ]
</FONT></PRE>
<FONT SIZE=2>The revised syntax reflects the fact that the two parameters of the
constructor </FONT><CODE><FONT SIZE=2>C</FONT></CODE><FONT SIZE=2> cannot be considered as a tuple.<BR>
<BR>


This does not mean that the ``partial evaluation'' of constructors is
accepted: accept it or not is a semantic issue, treated at
</FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2> typing time.<BR>
<BR>


<B>Motivation for the uppercase for True and False</B><BR>
<BR>


In normal syntax, </FONT><CODE><FONT SIZE=2>true</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>false</FONT></CODE><FONT SIZE=2> are the only
constructors which start with a lowercase letter. It is due to
historical reasons: in </FONT><CODE><FONT SIZE=2>Caml Light</FONT></CODE><FONT SIZE=2>, no constructors (of any
type) need to be capitalized. When </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2> was created, this was
changed, but strangely, </FONT><CODE><FONT SIZE=2>true</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>false</FONT></CODE><FONT SIZE=2> escaped to this
rule. They are even now considered as keywords, what they should not
be, since they are not syntactic constructs or part of syntactic
constructs.<BR>
<BR>


In revised syntax, they must be written </FONT><CODE><FONT SIZE=2>True</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>False</FONT></CODE><FONT SIZE=2>
and are not keywords.<BR>
<BR>


<B>Motivation for mutable syntax in records</B><BR>
<BR>


It is just to read: ``the label x is a mutable integer'' instead of
``the mutable label x is an integer'', which is less clear.</FONT><BR>
<BR>
<A NAME="toc41"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc48"><B><FONT SIZE=5>5.9</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Modules</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE><BR>
Modules application uses the currified form:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>type t = Set.Make(M).t;;</tt></td><td><tt>type t = (Set.Make M).t;</tt></td></tr>
</table></center>
<FONT SIZE=2><BR>
<BR>
<B>Motivation</B><BR>
<BR>


Currification syntax is more natural in functional languages. There is
no reason to have two different syntaxes for applications (whatever we
apply): one with parentheses, one with currification.</FONT><BR>
<BR>
<A NAME="toc42"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc49"><B><FONT SIZE=5>5.10</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Classes and objects</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE><BR>
The classes and objects also have a revised syntax. To see it, the
simplest way is to write examples in normal syntax and to convert them
into revised syntax using the command:
<PRE>
     camlp4o pr_r.cmo file.ml
</PRE>
<FONT SIZE=2>(documentation to be updated)</FONT><BR>
<BR>
<A NAME="toc43"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc50"><B><FONT SIZE=5>5.11</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Miscellaneous</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<UL><LI>
The ``<CODE>else</CODE>'' is mandatory in the ``<CODE>if</CODE>'' statement:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>if a then b</tt></td><td><tt>if a then b else ()</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The boolean operations ``or'' and ``and'' must be written only
with ``<CODE>||</CODE>'' and ``<CODE>&amp;&amp;</CODE>'':

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>a or b & c</tt></td><td><tt>a || b && c</tt></td></tr>
<tr><td><tt>a || b && c</tt></td><td><tt>a || b && c</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>No more ``<CODE>begin end</CODE>'' construction. One must use
parentheses when needed.<BR>
<BR>
<LI>The operators as functions are written with an backslash:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>(+)</tt></td><td><tt>\+</tt></td></tr>
<tr><td><tt>(mod)</tt></td><td><tt>\mod</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The operators with special characters are not automatically
infix. To define infixes, use the syntax extensions.<BR>
<BR>
<LI>It is possible to group together several declarations either in
an interface or in an implementation by enclosing them between
``<CODE>declare</CODE>'' and ``<CODE>end</CODE>''. Example in an interface:
<PRE>
      declare
        type foo = [ Foo of int | Bar ];
        value f : foo -&gt; int;
      end;
</PRE></UL><FONT SIZE=2>
<B>Motivation for the ``else''</B><BR>
<BR>


The </FONT><CODE><FONT SIZE=2>else</FONT></CODE><FONT SIZE=2> is mandatory to avoid the ``dangling else''
problem. In normal syntax, you can write:
</FONT><PRE><FONT SIZE=2>
    if a then
      if b then c
    else d
</FONT></PRE>
<FONT SIZE=2>In the above program, the ``else d'' will actually corresponds to the
``if b'' not to the ``if a''. In revised syntax, the ``else'' being
mandatory, the problem does not exist.<BR>
<BR>


</FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2> being a functional language, it is normal that the ``else'' case
be mandatory: indeed if the condition is false, what is returned by
the statement is not clear in normal syntax.<BR>
<BR>


All these ``dangling'' problems cause also problems in pretty
printing: it is not easy to know if the constructions have to be
parenthesized or not. In revised syntax, there are no dangling
problems and no problem in pretty printing. To pretty print in normal
syntax, a solution had to be used, using an extra parameter
transmitted in all functions.<BR>
<BR>


We remark that in revised syntax, the </FONT><CODE><FONT SIZE=2>if</FONT></CODE><FONT SIZE=2> construct is not
closed, it does not need to be.<BR>
<BR>


<B>Motivation for the ``or'' and ``and'' operators</B><BR>
<BR>


There is no reason to accept two syntaxes for the ``or'' operator and
two for the ``and'' operator. The syntaxes </FONT><CODE><FONT SIZE=2>or</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>&amp;</FONT></CODE><FONT SIZE=2> are
actually old constructions, kept for an old backward compatibility.<BR>
<BR>


<B>Motivation for the suppression of begin..end</B><BR>
<BR>


In normal syntax, the construction with </FONT><CODE><FONT SIZE=2>begin</FONT></CODE><FONT SIZE=2> and </FONT><CODE><FONT SIZE=2>end</FONT></CODE><FONT SIZE=2> is
actually the same than the parentheses: often a question of personal
taste. In normal syntax, when parenthesis is necessary, some
programmers prefer </FONT><CODE><FONT SIZE=2>"begin match...end"</FONT></CODE><FONT SIZE=2>, other </FONT><CODE><FONT SIZE=2>"(match...)"</FONT></CODE><FONT SIZE=2>.<BR>
<BR>


In revised syntax, the cases when such a parenthesization is necessary
is much less frequent, since most constructions are already
parenthesized. Two constructions for that are not necessary.<BR>
<BR>


<B>Motivation for syntax for alone operators</B><BR>
<BR>


To avoid the case of the </FONT><CODE><FONT SIZE=2>*</FONT></CODE><FONT SIZE=2> operator which must be specifically
written with spaces around it, since </FONT><CODE><FONT SIZE=2>(*)</FONT></CODE><FONT SIZE=2> in lexically
interpreted as a beginning of a comment.<BR>
<BR>


<B>Motivation for the fact that there are no automatic infixes</B><BR>
<BR>


Since we are under Camlp4, we can use Camlp4 features.<BR>
<BR>


<B>Motivation for the ``declare'' construction</B><BR>
<BR>


Essential when a syntax extension in </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2> structure item
generates several structure items. For example, if you make a syntax
change in order that a type declaration generates 1/ the type
declaration itself and 2/ functions to be applied to this type.<BR>
<BR>


When converted into </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2> normal syntax tree, this construct is
inlined.</FONT><BR>
<BR>
<A NAME="toc44"></A><TABLE CELLPADDING=0 CELLSPACING=0 WIDTH="100%">
<TR><TD BGCOLOR="#66ff66"><DIV ALIGN=center><TABLE>
<TR><TD><A NAME="htoc51"><B><FONT SIZE=5>5.12</FONT></B></A></TD>
<TD WIDTH="100%" ALIGN=center><B><FONT SIZE=5>Streams and parsers</FONT></B></TD>
</TR></TABLE></DIV></TD>
</TR></TABLE>
<UL><LI>
The streams and the stream patterns are bracketed with
``<CODE>[:</CODE>'' and ``<CODE>:]</CODE>'' instead of ``<CODE>[&lt;</CODE>'' and
``<CODE>&gt;]</CODE>''.<BR>
<BR>
<LI>The stream component ``terminal'' is written with a backquote
instead of a quote:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>[< '1; '2; s; '3 >]</tt></td><td><tt>[: `1; `2; s; `3 :]</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>The cases of parsers are bracketed with ``<CODE>[</CODE>'' and
``<CODE>]</CODE>'', like for ``<CODE>fun</CODE>'', ``<CODE>match</CODE>'' and
``<CODE>try</CODE>''. If there is one case, the brackets are not mandatory:

<center><table border=0 width="75%"><tr><th align=left width="50%">OCaml</th><th align=left width="50%">Revised</th></tr>
<tr><td><tt>parser</tt></td><td><tt>parser</tt></td></tr>
<tr><td><tt>&nbsp;&nbsp;[< 'Foo >] -> e</tt></td><td><tt>[ [: `Foo :] -> e</tt></td></tr>
<tr><td><tt>| [< p = f >] -> f</tt></td><td><tt>| [: p = f :] -> f ]</tt></td></tr>

<tr><td><tt>parser [< 'x >] -> x</tt></td><td><tt>parser [ [: `x :] -> x ]</tt></td></tr>

<tr><td><tt>parser [< 'x >] -> x</tt></td><td><tt>parser [: `x :] -> x</tt></td></tr>
</table></center>
<BR>
<BR>
<LI>It is possible to write the empty parser
raising the exception ``<CODE>Stream.</CODE><CODE>Failure</CODE>''
whichever parameter is applied, and the empty stream matching always
raising ``<CODE>Stream.</CODE><CODE>Failure</CODE>'':
<PRE>
    parser []
    match e with parser []
</PRE></UL><FONT SIZE=2>
<B>Motivation for the keyword </B></FONT><CODE><FONT SIZE=2><B>"parser"</B></FONT></CODE><FONT SIZE=2><B>, rather than
</B></FONT><CODE><FONT SIZE=2><B>"parse"</B></FONT></CODE><BR>
<BR>
<FONT SIZE=2>

Actually, it is not different from the choice of the normal syntax,
since the same keyword is used.<BR>
<BR>


The keyword ``parser'' is like ``function'', not like ``match''. The
``match'' and ``try'' statements are direct actions, with their
immediate parameters. On the other hand, the parsers and functions are
just ``concepts'': they are not immediately applied with their
parameters. One must read: ``this is a parser'' just like ``this is
a function''.<BR>
<BR>


The word ``parse'' might have been used if the construction was
``parse xxx with''. This is written ``match xxx with parser'' in order
to save a keyword.<BR>
<BR>


<B>Motivation for </B></FONT><CODE><FONT SIZE=2><B>[:</B></FONT></CODE><FONT SIZE=2><B> instead of </B></FONT><CODE><FONT SIZE=2><B>[&lt;</B></FONT></CODE><BR>
<BR>
<FONT SIZE=2>

It is a question of readability, because of the presence of quotations
in our extended language, whose syntax use many ``less'' and
``greater'' characters. And it is a problem for a list of quoted
things:
</FONT><PRE><FONT SIZE=2>
          [&lt;:expr&lt; xx &gt;&gt;; &lt;:expr&lt; yy &gt;&gt;]
</FONT></PRE><FONT SIZE=2>
<B>Motivation for quotes and backquotes</B><BR>
<BR>


Actually, this should have been done in </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2> normal syntax,
since from </FONT><CODE><FONT SIZE=2>Caml Light</FONT></CODE><FONT SIZE=2> to </FONT><CODE><FONT SIZE=2>OCaml</FONT></CODE><FONT SIZE=2>, the character used to
enclose characters changed from backquote into right quote. It would
have been then normal to invert that for the streams terminals, but
it was forgotten.<BR>
<BR>


In normal syntax, this creates sometimes problems in characters streams:
</FONT><PRE><FONT SIZE=2>
          parser [&lt; '('a' | 'b') &gt;] -&gt; ...
</FONT></PRE><FONT SIZE=2>The lexer interprets the first parenthesis as a character, which causes
thus parsing error. You must add a space before the left parenthesis:
</FONT><PRE><FONT SIZE=2>
          parser [&lt; ' ('a' | 'b') &gt;] -&gt; ...
</FONT></PRE>
<FONT SIZE=2>In revised syntax, which backquotes, this problem does not appear.<BR>
<BR>


<B>Motivation for closing the syntax of parsers</B><BR>
<BR>


To resolve the same problem of ``dangling bar'' than for functions,
matches and tries. This syntax is closed the same way.<BR>
<BR>


<B>Motivation for the empty parser</B><BR>
<BR>


Useful in initial cases in iterations or initial references values.
</FONT>
<BR>
<BR>
<I><FONT COLOR=maroon>
<br>
For remarks about Camlp4, write to:
<img src="http://cristal.inria.fr/~ddr/images/email.jpg" alt=email align=top>
</FONT></I><HR>
<A HREF="tutorial004.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="tutorial006.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>