Commit 6673456a by Pietro Abate

### [r2006-05-29 14:58:18 by ngesbert] -- added a few missing parentheses in type examples (operator

```precedences still aren't documented but the examples are now correct
wrt current implementation, and still will if precedences are changed)
-- slightly changed the description of the general form of a function
declaration in the quick reference card: the number of types need not
be the same as the nnumber of patterns, which the previous description
seemed to imply.

Original author: ngesbert
Date: 2006-05-29 14:58:18+00:00```
parent feb5dc88
 ... ... @@ -369,14 +369,14 @@ type t = [ (t @ t) ? ] (* [s?] where s=[ s? s? ] *) type x = [ Int* ] type y = x @ [ Char* ] (* [ Int* Char* ] *) type t = [Int] @ t | [] (* [ Int* ] *) type t = ([Int] @ t) | [] (* [ Int* ] *) ]]>

however when used in recursive definitions @ but must be right linear so for instance the following definition are not allowed:

... ... @@ -559,7 +559,7 @@ where %%t%% and %%s%% are types. Intuitively, this type corresponds to functions that accept (at least) any argument of type %%t%%, and for such an argument, returns a value of type %%s%%. For instance, the type (Int,Int) -> Int & (Char,Char) -> Char For instance, the type ((Int,Int) -> Int) & ((Char,Char) -> Char) denotes functions that maps any pair of integer to an integer, and any pair of characters to a character.

... ... @@ -569,7 +569,7 @@ The explanation above gives the intuition behind the interpretation of functional types. It is sufficient to understand which subtyping relations and equivalences hold between (boolean combination) of functional types. For instance, Int -> Int & Char -> Char is a subtype (Int -> Int) & (Char -> Char) is a subtype of (Int|Char) -> (Int|Char) because with the intuition above, a function of the first type, when given a value of type Int|Char returns ... ... @@ -581,8 +581,8 @@ a value of type Int or of type Char Formally, the type %%t%% -> %%s%% denotes CDuce abstractions fun (%%t1%% -> %%s1%%; %%...%%; %%tn%% -> %%sn%%)... such that %%t1%% -> %%s1%% & %%...%% & %%tn%% -> %%sn%% is a subtype of %%t%% -> %%s%%. such that (%%t1%% -> %%s1%%) & %%...%% & (%%tn%% -> %%sn%%) is a subtype of %%t%% -> %%s%%.

... ...

 ... ... @@ -204,7 +204,7 @@ field l is not present)
• Expressions:
• General form: fun f (t1->s1;...;tn->sn) p1 -> e1 | ... | pn -> en (f is optional)
• p1 -> e1 | ... | pm -> em (f is optional)
• Simple function: fun f (p : t) : s = e, equivalent to fun f (t -> s) p -> e
• Multiple arguments: fun f (p1 : t1, p2 : t2,...) : s = ... ...
•  ... ... @@ -40,7 +40,7 @@ let %%f%% (%%t1%%->%%s1%%;...;%%tn%%->%%sn%%) %%p1%% -> %%e1%% | ... | %%pm%% ->

Such a function accepts arguments of type (%%t1%%|...|%%tn%%); it has all the types %%ti%%->%%si%%, and, thus, it also has their intersection %%t1%%->%%s1%%&...&%%tn%%->%%sn%% thus, it also has their intersection (%%t1%%->%%s1)%%&...&(%%tn%%->%%sn%%)

... ... @@ -167,7 +167,7 @@ the type checker deduces that the expressions <sons>s and returns for the split function the type (MPerson -> Man) & (FPerson -> Woman). Note that the use of overloading here is critical: although split has also type Person ->(Man | Woman) (since split is of type MPerson->Man & FPerson->Woman, which is a subtype), had we (MPerson->Man) & (FPerson->Woman), which is a subtype), had we declared split of that type, the function would not have type-checked: in the recursive calls we would have been able to deduce for s and for d the type [ (Man | Woman)* ], which is not enough to type-check the ... ...

Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!