Commit 3ae1721f authored by Pietro Abate's avatar Pietro Abate

[r2005-04-20 21:24:01 by beppe] Empty log message

Original author: beppe
Date: 2005-04-20 21:24:01+00:00
parent 0b99c870
......@@ -21,5 +21,7 @@ tutorial_pdf: tutorial
manual_pdf: manual
$(FOP) manual_fo.xml manual.pdf
install:
scp manual.pdf tutorial.pdf cduce@di.ens.fr:public_html/papers/
......@@ -12,9 +12,15 @@ Define exactly @ at page 10
TUTORIAL
========
change syntax
- update syntax for new elements DONE PLEASE CHECK
- explain syntax (x:? t) and why it is better for load xml in page 5
ALL
===
Add page numbers
Add table of contents
......@@ -24,9 +24,9 @@ grouped by categories and explained; a <a href="tutorial.html">Tutorial</a>
where we give a gentle introduction to programming in CDuce; and a
<a href="memento.html">Quick reference card</a> where we group and briefly explain in a single page CDuce syntax.
</p>
<p>A PDF version of the user guide is regularly regenerated from the site and is available <a href="papers/manual.pdf">here</a>. Similarly a PDF version of the tutorial is available e <a href="papers/tutorial.pdf">here</a>. These document are generated by a CDuce program available in the CVS (doc/fomanual). For an up-to-date version always consult the on-line versions</p>
<p>A PDF version of the user guide is regularly regenerated from the site and is available here: <a href="papers/manual.pdf">manual.pdf</a>. Similarly a PDF version of the tutorial is available here: <a href="papers/tutorial.pdf">tutorial.pdf</a>. These document are generated by a CDuce program available in the CVS (doc/fomanual). For an up-to-date version always consult the on-line versions</p>
<p>
For more technical and theoretical information you can consult the technical paper available <a href="papers.html">here</a>.
For more technical and theoretical information you can consult the technical paper available <a href="papers.html">in this page</a>.
</p>
</box>
......
......@@ -19,16 +19,17 @@ demo" name="proto"/>-->
<external href="/cgi-bin/cduce" title="Online demo" name="proto"/>
<include file="demo.xml"/>
<include file="download.xml"/>
<include file="bench.xml"/>
<include file="papers.xml"/>
<include file="stages.xml"/>
<include file="documentation.xml"/>
<include file="mailing.xml"/>
<include file="examples.xml"/>
<!-- <include file="hacking.xml"/> -->
<!-- Note: this is no longer relevant -->
<include file="tips.xml"/>
<include file="ocaml.xml"/>
<include file="stages.xml"/>
<include file="bench.xml"/>
<include file="contrib.xml"/>
<include file="mailing.xml"/>
<include file="team.xml"/>
<include file="funding.xml"/>
<include file="dtd2cduce.xml"/>
......
......@@ -27,6 +27,9 @@ Sur cette page:
<box title="Publications" link="pub">
<ul>
<!--include-verbatim file="http://www.grappa.univ-lille3.fr/bibtex/tralala.php"/>
maybe some day ...-->
<li>
<paper file="http://www.cduce.org/papers/semantic_pi.pdf">
<title>Semantic subtyping for the pi-calculus</title>
......@@ -86,6 +89,7 @@ practical algorithms needed for typechecking. Most of these algorithms
can be obtained by local modifications to existing ones for a
monomorphic system.</p> </abstract>
</paper>
</li>
......
......@@ -21,7 +21,7 @@ sequences of all names of parents in a <code>ParentBook</code> element:
<sample><![CDATA[
let names (ParentBook -> [Name*])
<parentbook>x -> (map x with <person>[ n _*] -> n)
<parentbook>x -> (map x with <person ..>[ n _*] -> n)
]]></sample>
<p>
......@@ -40,18 +40,25 @@ transformation defined by the subsequent pattern matching. Here <code>map</code>
returns the sequence obtained by replacing each person in <code>x</code> by its
<code>Name</code> element. Note that we use the pattern
</p>
<sample><![CDATA[<person>[ n _*],
<sample><![CDATA[<person ..>[ n _*],
]]></sample>
<p>to match the person elements: <code>n</code> matches (and captures) the <code>Name</code>
element-that is, the first element of the sequence-, <code>_*</code> matches (and discards) the sequence of elements that
follow, and person matches the tag of the person (although the
latter contains an attribute). The interface and the type definitions
<p>to match the person elements: <code>n</code> matches (and captures) the
<code>Name</code> element-that is, the first element of the sequence-,
<code>_*</code> matches (and discards) the sequence of elements that follow, and
<code>person</code> matches the tag of the person. Since elements of type
<code>Person</code> contain attributes (actually, just the attribute gender)
then we use <code>..</code> to match (and discard) them. This is not necessary
for the parentbook elements, but we could have specified it as well as
<code>&lt;parentbook ..>x</code> since <code>..</code> matches any sequence of
attibutes, the empty one as well.
</p><p>
The interface and the type definitions
ensure that the tags will be the expected ones, so we could optimize the
code by defining a body that skips the check of the tags:
</p>
<sample><![CDATA[
<_> x -> (map x with <_>[ n _*] -> n)
<_> x -> (map x with <_ ..>[ n _*] -> n)
]]></sample>
<p>
......@@ -64,16 +71,16 @@ parents with exactly two children, then we had to replace <code>transform</code>
<sample><![CDATA[
let names2 (ParentBook -> [Name*])
<parentbook> x ->
transform x with <person>[ n <children>[Person Person] _*] -> [n]
transform x with <person ..>[ n <children>[Person Person] _*] -> [n]
]]></sample>
<p>
While <code>map</code> must be applicable to all the elements of a sequence,
<code>transform</code> filters only those that make its pattern succeed. The
right-hand sides return sequences which are concatenated in the final result.
In this case <code>transform</code> returns the names only of those persons
that match the pattern <code>&lt;person>[ n &lt;children>[Person Person] _*]</code>.
that match the pattern <code>&lt;person ..>[ n &lt;children>[Person Person] _*]</code>.
Here again, the implementation compiles this pattern exactly as
<code>&lt;_>[ n &lt;_>[_ _] _*]</code>, and in particular avoids checking
<code>&lt;_ ..>[ n &lt;_>[_ _] _*]</code>, and in particular avoids checking
that sub-elements of <code>&lt;children></code> are of type <code>Person</code>
when static-typing enforces this property.
</p>
......@@ -92,7 +99,7 @@ it we have to recursively apply <code>names</code> to the sequence of children:
<sample><![CDATA[
let names (ParentBook -> [Name*])
<parentbook> x -> transform x with
<person> [ n <children>c _*] -> [n]@(names <parentbook>c)
<person ..> [ n <children>c _*] -> [n]@(names <parentbook>c)
]]></sample>
<p>
where <code>@</code> denotes the concatenation of sequences. Note that in order to
......@@ -104,7 +111,7 @@ types denoted by <code>(ParentBook|Children)</code>:
</p>
<sample><![CDATA[
let names ( ParentBook|Children -> [Name*] )
<_>x -> transform x with <person>[ n c _*] -> [n]@(names c)
<_>x -> transform x with <person ..>[ n c _*] -> [n]@(names c)
]]></sample>
<p>
Note here the use of the pattern <code>&lt;_></code> at the beginning of the body which
......@@ -119,7 +126,7 @@ makes it possible for the function to work both on <code>ParentBook</code> and o
<p>
In all these functions we have used the pattern <code>_*</code> to match, and
thus discard, the rest of a sequence. This is nothing but a particular regular expression over types. Type regexps can be used in patterns to match subsequences of a value. For instance the pattern
<code>&lt;person>[ _ _ Tel+]</code> matches all person elements that specify no <code>Email</code> element and at least one <code>Tel</code> element. It may be useful
<code>&lt;person ..>[ _ _ Tel+]</code> matches all person elements that specify no <code>Email</code> element and at least one <code>Tel</code> element. It may be useful
to bind the sequence captured by a (pattern) regular expression to a variable. But since a regexp is not a type, we cannot write, say, <code>x&amp;Tel+</code>. So we introduce a special notation <code>x::%%R%%</code> to bind <code>x</code> to the sequence matched by the type regular expression <code>%%R%%</code>. For instance:
</p>
<sample><![CDATA[
......@@ -140,8 +147,8 @@ non-consecutive elements. For instance:
<sample><![CDATA[
type PhoneItem = {name = String; phones = [String*] }
let agendaitem (Person -> PhoneItem)
<person>[<name>n _ (t::Tel | _)*] ->
{ name = n ; phones = map t with <tel> s ->s }
<person ..>[<name>n _ (t::Tel | _)*] ->
{ name = n ; phones = map t with <tel ..> s ->s }
]]></sample>
<p>
transforms a <code>person</code> element into a record value with two fields containing
......@@ -165,7 +172,7 @@ only if the first fails). Thus we can write a shorter pattern that (applied to <
<p>
Both patterns are compiled into </p>
<sample><![CDATA[
( w::<tel kind="work">_ | t::<tel>_ | e::_)*
( w::<tel kind="work">_ | t::<tel ..>_ | e::_)*
]]></sample>
<p>
since checking the tag suffices to determine if the element is of type <code>Tel</code>.
......@@ -178,8 +185,8 @@ the possible occurrence of a dash:
</p>
<sample><![CDATA[
let agendaitem2 (Person -> {name=String; phones=[Int*]})
<person>[ <name>n _ (t::Tel|_)* ] ->
{ name = n; phones = map t with <tel>[(s::'0'--'9'|_)*] -> int_of s }
<person ..>[ <name>n _ (t::Tel|_)* ] ->
{ name = n; phones = map t with <tel ..>[(s::'0'--'9'|_)*] -> int_of s }
]]></sample>
<p>
In this case <code>s</code> extracts the subsequence formed only by numerical
......@@ -205,7 +212,7 @@ PhoneBook</code> elements. This yields the following <i>overloaded</i> function:
</p><a name="names3"/>
<sample><![CDATA[
let names3 (ParentBook -> [Name*] ; PhoneBook -> [String*])
| <parentbook> x -> (map x with <person>[ n _* ] -> n)
| <parentbook> x -> (map x with <person ..>[ n _* ] -> n)
| <phonebook> x -> (map x with { name=n } -> n)
]]></sample>
<p>
......@@ -217,7 +224,7 @@ alternative pattern:
</p>
<sample><![CDATA[
let names4 (ParentBook -> [Name*] ; PhoneBook -> [String*])
<_> x -> map x with ( <person>[ n _* ] | { name=n } ) -> n
<_> x -> map x with ( <person ..>[ n _* ] | { name=n } ) -> n
]]></sample>
<p>The interface ensures that the two representations will never mix.</p>
</section>
......
......@@ -120,7 +120,7 @@ Note the blank spaces around the colons
Actually only the first blank is necessary. CDuce accepts <code>let x :%%t%% = %%e%% in %%e'%%</code>,
as well
</footnote>.
This is because the XML recommendation allows colons to occur in identifiers: see the User's Manual section on <a href="namespaces.html">namespaces</a>. (the same holds to for the functional arrow symbol <code>-></code> which must be surrounded by blanks and by colons in the formal parameters of a function: see <a
This is because the XML recommendation allows colons to occur in identifiers: see the User's Manual section on <a href="namespaces.html">namespaces</a>. (the same holds true for the functional arrow symbol <code>-></code> which must be surrounded by blanks and by colons in the formal parameters of a function: see <a
href="manual_expressions.html#bnote1">this paragraph</a> of the User's manual).
</box>
......@@ -352,7 +352,7 @@ an optional dash character. Had we wanted to state that a phone number
is an integer with at least, say, 5 digits (of course this is
meaningful only if no phone number starts by 0) we would have used an
interval type such as <code>&lt;tel kind=?"home"|"work"&gt;[10000--*]</code>,
where * here denotes plus infinity. </p>
where <code>*</code> here denotes plus infinity, while on the lefthand side of <code>--</code> (as in <code>*--100</code>) it denotes minus infinity. </p>
<p>
Echar is the type of characters in e-mails
......
......@@ -18,11 +18,22 @@ test it on the <a href="http://reglisse.ens.fr/cgi-bin/cduce">online interpreter
</box>
<box title="Pair and Record Patterns" link="record">
<b style="color:#FF0080">TO BE DONE</b>
</box>
<box title="Sequence patterns" link="seq">
<b style="color:#FF0080">TO BE DONE</b>
</box>
<box title="XML elements and attributes" link="xml">
<p>
Up to now we used for XML elements (and their types) an abbreviated notation
as for <code>&lt;table align="center" valign="top">[...]</code>. Actually, the precise syntax of XML elements is
as for <code>&lt;table align="center" valign="top">[</code><i>some_content</i><code>]</code>. Actually, the precise syntax of XML elements is
</p>
<sample><![CDATA[
<(%%expr1%%) (%%expr2%%)>%%expr3%%
......@@ -45,9 +56,9 @@ particular we allow the programmer to omit the surrounding <code>{{(` )}}</code>
when <code>%%expr1%%</code> is an atom, and to omit the surrounding <code>{{{ }
}}</code> and the infix semicolons <code>{{;}}</code> when
<code>%%expr2%%</code> is a record value. This is why we can write
<code>&lt;table align="center" valign="top">[...]</code>, rather than
<code>&lt;table align="center" valign="top">[</code>...<code>]</code>, rather than
<code>&lt;$$(`$$table$$)$$ $$({$$align="center"$$;$$ valign="top"$$})$$
>[...]</code>
>[</code>...<code>]</code>
</p>
<p> While these abbreviations are quite handy, they demand some care when used in record patterns. As we said, the general form of a record pattern is:
......@@ -64,10 +75,9 @@ attributes), the pattern <code>&lt;(t) (a)>_</code> matches all XML elements
(whatever their tag is) and captures their tag in the variable <code>t</code>
(and their attributes in <code>a</code>). Another point to notice is that
<code>&lt;t>_</code> stands for <code>&lt;t ({})>_</code> (more precisely, for
<code>&lt;(`t) ({})>_</code>). Since <code>{}</code> is the <i>open</i> empty
record type, then it matches all the records. Therefore <code>&lt;t>_</code>
matches all elements of tag <code>t</code> independently from whether they have
attributes or not.
<code>&lt;(`t) ({})>_</code>). Since <code>{}</code> is the <i>closed</i> empty
record type, then it matches only the empty record. Therefore <code>&lt;t>_</code>
matches all elements of tag <code>t</code> that have no attibute. We have seen at the beginning of this tutorial that in order to match all element of tag <code>t</code> independently from whether they have attributes or not, we have to use the pattern <code>&lt;t ..>_</code> (which stands for <code>&lt;(`t) ({..})>_</code>).
</p>
<p>
In the following we enumerate some simple examples to show
......@@ -90,7 +100,7 @@ transform bib with
<book (a)> [ (x::(Any\Url)|_)* ] -> [ <book (a)> x ]
]]></sample>
<p>
returns the list of all books without their Url element.
returns the list of all books without their Url element (if any).
</p>
<sample><![CDATA[
transform bib with
......@@ -138,36 +148,36 @@ As an example to summarize what we said above, consider the the elements
transitional XHTML these elements can have an attribute <code>bgcolor</code>
which is deprecated since in strict XHTML the background color must be specified
by the <code>style</code> attribute. So for instance <code>&lt;table
bgcolor="#ffff00" style="font-family:Arial">...</code>
bgcolor="#ffff00" style="font-family:Arial"></code><i>some_content</i><code></code>
must be rewritten as <code>&lt;table style="bgcolor:#ffff00;
font-family:Arial">...</code> to be XHTML strict compliant. Here is a function
font-family:Arial"></code><i>some_content</i><code></code> to be XHTML strict compliant. Here is a function
that does this transformation on a very simplified version of possibly nested
tables containing strings.
</p>
<sample><![CDATA[
type Table = <table {| bgcolor=?String; style=?String |}>[ Tr+]
type Tr = <tr {| bgcolor=?String; style=?String |}>[ Td+]
type Td = <td {| bgcolor=?String; style=?String |}>[ Table* | PCDATA ]
type Table = <table { bgcolor=?String; style=?String }>[ Tr+]
type Tr = <tr { bgcolor=?String; style=?String }>[ Td+]
type Td = <td { bgcolor=?String; style=?String }>[ Table* | PCDATA ]
let strict ([Table*]->[Table*]; [Tr+]->[Tr+]; [Td+]->[Td+]; [PCDATA]->[PCDATA])
x ->
map x with
<(t) (a& {| bgcolor=c; style=s |})> l
<(t) (a& { bgcolor=c; style=s })> l
-> <(t) (a\bgcolor+{style=(s@"; bgcolor:"@c)})>(strict l)
| <(t) (a& {| bgcolor=c |})> l
| <(t) (a& { bgcolor=c })> l
-> <(t) (a\bgcolor+{style=("bgcolor:"@c)})>(strict l)
| <(t)> l -> <(t)>(strict l)
| <(t) (a)> l -> <(t) (a)>(strict l)
| c -> c
]]></sample>
<p>
As an exercise the reader can try to rewrite the function strict so that the first three branches of the map are condensed into a unique branch.
As an exercise the reader can try to rewrite the function <code>strict</code> so that the first three branches of the map are condensed into a unique branch.
</p>
</box>
<box title="Handling optional attributes" link="optatrr">
<p>
The blend of type type constructors and boolean combinator can be used to
The blend of type constructors and boolean combinators can be used to
reduce verbosity in writing pattern matching. As an example we show how to handle
tags with several optional attributes.
</p>
......@@ -180,7 +190,7 @@ type Sample = <sample highlight=?"true"|"false">String
let content (Sample -> String)
| <sample highlight="false">_ -> "non-higlighted code"
| <sample>_ -> "highlighted code"
| <sample ..>_ -> "highlighted code"
]]></sample>
<p>
......@@ -200,7 +210,7 @@ let content (Sample -> String)
| <sample highlight="false" lineno="false">_ -> "lineno=false, highlight=false"
| <sample lineno="false">_ -> "lineno=false, highlight=true"
| <sample highlight="false">_ -> "lineno=true, highlight=false"
| <sample>_ -> "lineno=true, highlight=true,"
| <sample ..>_ -> "lineno=true, highlight=true,"
]]></sample>
<p>
......@@ -213,15 +223,15 @@ is to resort to intersection and default patterns as follows:
</p>
<sample><![CDATA[
let content (Sample -> String)
| <sample ( ({ highlight = h } | (h {{:=}} "true"))
{{&}}({ lineno = l } | (l {{:=}} "true")) )>_
| <sample ( ({ highlight = h ..} | (h {{:=}} "true"))
{{&}}({ lineno = l ..} | (l {{:=}} "true")) )>_
-> ['lineno=' !l ', highlight=' !h]
]]></sample>
<p>
The intersection pattern <code>&amp;</code> makes both patterns to be matched
against the record of attributes: each pattern checks the presence of a specific
attribute, if it is present it captures the attribute value in a given variables
attribute (the other is ignored by matching it with <code>..</code>), if it is present it captures the attribute value in a given variables
while if the attribute is absent the default sub-pattern is used to assign the
variable a default value.
</p>
......@@ -257,7 +267,9 @@ extracts the first pair of consecutive integers.
</p>
</box>
<box title="Regular expression patterns" link="pre">
<box title="Compiling regular expression patterns" link="pre">
<b style="color:#FF0080">CONNECT WITH SECTION ON SEQUENCE PATTERNS WHEN WRITTEN</b>
<p>
CDuce provides syntactic sugar for defining patterns working on
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment