forked from GitHub/gf-core
843 lines
22 KiB
HTML
843 lines
22 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="generator" CONTENT="http://txt2tags.sf.net">
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
|
|
<TITLE>Transfer language reference</TITLE>
|
|
</HEAD><BODY BGCOLOR="white" TEXT="black">
|
|
<P ALIGN="center"><CENTER><H1>Transfer language reference</H1>
|
|
<FONT SIZE="4">
|
|
<I>Author: Björn Bringert <bringert@cs.chalmers.se></I><BR>
|
|
Last update: Wed Mar 1 13:52:22 2006
|
|
</FONT></CENTER>
|
|
|
|
<P></P>
|
|
<HR NOSHADE SIZE=1>
|
|
<P></P>
|
|
<UL>
|
|
<LI><A HREF="#toc1">Current implementation status</A>
|
|
<LI><A HREF="#toc2">Layout syntax</A>
|
|
<LI><A HREF="#toc3">Imports</A>
|
|
<LI><A HREF="#toc4">Function declarations</A>
|
|
<LI><A HREF="#toc5">Data type declarations</A>
|
|
<LI><A HREF="#toc6">Lambda expressions</A>
|
|
<LI><A HREF="#toc7">Local definitions</A>
|
|
<LI><A HREF="#toc8">Types</A>
|
|
<UL>
|
|
<LI><A HREF="#function_types">Function types</A>
|
|
<LI><A HREF="#toc10">Basic types</A>
|
|
<LI><A HREF="#toc11">Records</A>
|
|
<LI><A HREF="#tuples">Tuples</A>
|
|
<LI><A HREF="#toc13">Lists</A>
|
|
</UL>
|
|
<LI><A HREF="#toc14">Case expressions</A>
|
|
<LI><A HREF="#patterns">Patterns</A>
|
|
<UL>
|
|
<LI><A HREF="#toc16">Constructor patterns</A>
|
|
<LI><A HREF="#toc17">Variable patterns</A>
|
|
<LI><A HREF="#toc18">Wildcard patterns</A>
|
|
<LI><A HREF="#toc19">Record patterns</A>
|
|
<LI><A HREF="#toc20">Disjunctive patterns</A>
|
|
<LI><A HREF="#toc21">List patterns</A>
|
|
<LI><A HREF="#toc22">Tuple patterns</A>
|
|
<LI><A HREF="#toc23">String literal patterns</A>
|
|
<LI><A HREF="#toc24">Integer literal patterns</A>
|
|
</UL>
|
|
<LI><A HREF="#metavariables">Metavariables</A>
|
|
<LI><A HREF="#toc26">Overloaded functions</A>
|
|
<UL>
|
|
<LI><A HREF="#toc27">Type class extension</A>
|
|
<LI><A HREF="#toc28">Extending multiple classes</A>
|
|
</UL>
|
|
<LI><A HREF="#prelude">Standard prelude</A>
|
|
<LI><A HREF="#toc30">Operators</A>
|
|
<UL>
|
|
<LI><A HREF="#toc31">Unary operators</A>
|
|
<LI><A HREF="#toc32">Binary operators</A>
|
|
</UL>
|
|
<LI><A HREF="#toc33">Compositional functions</A>
|
|
<LI><A HREF="#toc34">do notation</A>
|
|
</UL>
|
|
|
|
<P></P>
|
|
<HR NOSHADE SIZE=1>
|
|
<P></P>
|
|
<P>
|
|
<B>WARNING: The Transfer language is still experimental. Its syntax, type system and semantics may change without notice. I will try to help you with any problems this might cause, but I will not refrain from changing the language solely for reasons of backwards compatibility.</B>
|
|
</P>
|
|
<P>
|
|
This document describes the features of the Transfer language.
|
|
See the <A HREF="transfer-tutorial.html">Transfer tutorial</A>
|
|
for an example of a Transfer program, and how to compile and use
|
|
Transfer programs.
|
|
</P>
|
|
<P>
|
|
Transfer is a dependently typed functional programming language
|
|
with eager evaluation. The language supports generalized algebraic
|
|
datatypes, pattern matching and function overloading.
|
|
</P>
|
|
<A NAME="toc1"></A>
|
|
<H2>Current implementation status</H2>
|
|
<P>
|
|
<B>Not all features of the Transfer language have been implemented yet</B>. The most
|
|
important missing piece is the type checker. This means that there are almost
|
|
no checks done on Transfer programs before they are run. It also means that
|
|
the values of metavariables are not inferred. Thus metavariables cannot
|
|
be used where their values matter. For example, dictionaries for overloaded
|
|
functions must be given explicitly, not as metavariables.
|
|
</P>
|
|
<A NAME="toc2"></A>
|
|
<H2>Layout syntax</H2>
|
|
<P>
|
|
Transfer uses layout syntax, where the indentation of a piece of code
|
|
determines which syntactic block it belongs to.
|
|
</P>
|
|
<P>
|
|
To give the block structure without using layout
|
|
syntax, you can enclose the block in curly braces and
|
|
separate the parts of the blocks with semicolons.
|
|
</P>
|
|
<P>
|
|
For example, this case expression:
|
|
</P>
|
|
<PRE>
|
|
case x of
|
|
p1 -> e1
|
|
p2 -> e2
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
is equivalent to this one:
|
|
</P>
|
|
<PRE>
|
|
case x of {
|
|
p1 -> e1 ;
|
|
p2 -> e2
|
|
}
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Here the layout is insignificant, as the structure is given with
|
|
braces and semicolons. Thus it is equivalent to:
|
|
</P>
|
|
<PRE>
|
|
case x of { p1 -> e1 ; p2 -> e2 }
|
|
</PRE>
|
|
<P></P>
|
|
<A NAME="toc3"></A>
|
|
<H2>Imports</H2>
|
|
<P>
|
|
A Transfer module starts with some imports. Most modules will have to
|
|
import the prelude, which contains definitons used by most programs:
|
|
</P>
|
|
<PRE>
|
|
import prelude
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
For more information about the standard prelude, see <A HREF="#prelude">Standard prelude</A>.
|
|
</P>
|
|
<A NAME="toc4"></A>
|
|
<H2>Function declarations</H2>
|
|
<P>
|
|
Functions need to be given a type and a definition. The type is given
|
|
by a typing judgement on the form:
|
|
</P>
|
|
<PRE>
|
|
f : T
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
where <CODE>f</CODE> is the function's name, and <CODE>T</CODE> its type. See
|
|
<A HREF="#function_types">Function types</A> for a how the types of functions
|
|
are written.
|
|
</P>
|
|
<P>
|
|
The definition of the function is then given as a sequence of pattern
|
|
equations. The first equation whose patterns match the function arguments
|
|
is used when the function is called. Pattern equations are on the form:
|
|
</P>
|
|
<PRE>
|
|
f p11 ... p1m = exp1
|
|
...
|
|
f pn1 ... pnm = expn
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
where <CODE>p11</CODE> to <CODE>pnm</CODE> are patterns, see <A HREF="#patterns">Patterns</A>.
|
|
</P>
|
|
<P>
|
|
Pattern equations can also have guards, boolean expressions which determine
|
|
whether to use the equation when the pattern has been matched. Pattern equations
|
|
with guards are written:
|
|
</P>
|
|
<PRE>
|
|
f p11 ... p1m | guard1 = exp1
|
|
...
|
|
f pn1 ... pnm | guardn = expn
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Pattern equations with and without guards can be mixed in the definiton of
|
|
a function.
|
|
</P>
|
|
<P>
|
|
Any variables bound in the patterns are in scope in the guards and
|
|
right hand sides of each pattern equation.
|
|
</P>
|
|
<A NAME="toc5"></A>
|
|
<H2>Data type declarations</H2>
|
|
<P>
|
|
Transfer supports Generalized Algebraic Datatypes.
|
|
They are declared thusly:
|
|
</P>
|
|
<PRE>
|
|
data D : T where
|
|
c1 : Tc1
|
|
...
|
|
cn : Tcn
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Here <CODE>D</CODE> is the name of the data type, <CODE>T</CODE> is the type of the type
|
|
constructor, <CODE>c1</CODE> to <CODE>cn</CODE> are the data constructor names, and
|
|
<CODE>Tc1</CODE> to <CODE>Tcn</CODE> are their types.
|
|
</P>
|
|
<P>
|
|
FIXME: explain the constraints on the types of type and data constructors.
|
|
</P>
|
|
<A NAME="toc6"></A>
|
|
<H2>Lambda expressions</H2>
|
|
<P>
|
|
<I>Lambda expressions</I> are terms which express functions, without
|
|
giving names to them. For example:
|
|
</P>
|
|
<PRE>
|
|
\x -> x + 1
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
is the function which takes an argument, and returns the value of the
|
|
argument + 1.
|
|
</P>
|
|
<A NAME="toc7"></A>
|
|
<H2>Local definitions</H2>
|
|
<P>
|
|
To give local definition to some names, use:
|
|
</P>
|
|
<PRE>
|
|
let x1 = exp1
|
|
...
|
|
xn = expn
|
|
in exp
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Here, the variables <CODE>x1</CODE> to <CODE>xn</CODE> are in scope in all the expressions
|
|
<CODE>exp1</CODE> to <CODE>expn</CODE>, and in <CODE>exp</CODE>. Thus let-defined functions can be
|
|
mutually recursive.
|
|
</P>
|
|
<A NAME="toc8"></A>
|
|
<H2>Types</H2>
|
|
<A NAME="function_types"></A>
|
|
<H3>Function types</H3>
|
|
<P>
|
|
Functions types are of the form:
|
|
</P>
|
|
<PRE>
|
|
A -> B
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
This is the type of functions which take an argument of type
|
|
<CODE>A</CODE> and returns a result of type <CODE>B</CODE>.
|
|
</P>
|
|
<P>
|
|
To write functions which take more than one argument, we use <I>currying</I>.
|
|
A function which takes n arguments is a function which takes one
|
|
argument and returns a function which takes n-1 arguments. Thus,
|
|
</P>
|
|
<PRE>
|
|
A -> (B -> C)
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
or, equivalently, since <CODE>-></CODE> associates to the right:
|
|
</P>
|
|
<PRE>
|
|
A -> B -> C
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
is the type of functions which take teo arguments, the first of type
|
|
<CODE>A</CODE> and the second of type <CODE>B</CODE>. This arrangement lets us do
|
|
<I>partial application</I> of function to fewer arguments than the function
|
|
is declared to take, returning a new function which takes the rest
|
|
of the arguments.
|
|
</P>
|
|
<H4>Dependent function types</H4>
|
|
<P>
|
|
In a function type, the value of an argument can be used later
|
|
in the type. Such dependent function types are written:
|
|
</P>
|
|
<PRE>
|
|
(x : A) -> B
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Here, <CODE>x</CODE> is in scope in <CODE>B</CODE>.
|
|
</P>
|
|
<A NAME="toc10"></A>
|
|
<H3>Basic types</H3>
|
|
<H4>Integers</H4>
|
|
<P>
|
|
The type of integers is called <CODE>Integer</CODE>.
|
|
Standard decmial integer literals, such as <CODE>0</CODE> and <CODE>1234</CODE> are used to
|
|
represent values of this type.
|
|
</P>
|
|
<H4>Floating-point numbers</H4>
|
|
<P>
|
|
The only currently supported floating-point type is <CODE>Double</CODE>, which supports
|
|
IEEE-754 double-precision floating-point numbers. Double literals are written
|
|
in decimal notation, e.g. <CODE>123.456</CODE>.
|
|
</P>
|
|
<H4>Strings</H4>
|
|
<P>
|
|
There is a primitive <CODE>String</CODE> type. String literals are written
|
|
with double quotes, e.g. <CODE>"this is a string"</CODE>.
|
|
FIXME: This might be replaced by a list of
|
|
characters representation in the future.
|
|
</P>
|
|
<H4>Booleans</H4>
|
|
<P>
|
|
Booleans are not a built-in type, though some features of the Transfer language
|
|
depend on them. The <CODE>Bool</CODE> type is defined in the
|
|
<A HREF="#prelude">Standard prelude</A>.
|
|
</P>
|
|
<PRE>
|
|
data Bool : Type where
|
|
True : Bool
|
|
False : Bool
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
In addition to normal pattern matching on booleans, you can use the built-in
|
|
if-expression:
|
|
</P>
|
|
<PRE>
|
|
if exp1 then exp2 else exp3
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
where <CODE>exp1</CODE> must be an expression of type <CODE>Bool</CODE>.
|
|
</P>
|
|
<A NAME="toc11"></A>
|
|
<H3>Records</H3>
|
|
<H4>Record types</H4>
|
|
<P>
|
|
Record types are created by using a <CODE>sig</CODE> expression:
|
|
</P>
|
|
<PRE>
|
|
sig { l1 : T1; ... ; ln : Tn }
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Here, <CODE>l1</CODE> to <CODE>ln</CODE> are the field labels and <CODE>T1</CODE> to <CODE>Tn</CODE> are field types.
|
|
</P>
|
|
<H4>Record values</H4>
|
|
<P>
|
|
Record values are constructed using <CODE>rec</CODE> expressions:
|
|
</P>
|
|
<PRE>
|
|
rec { l1 = exp1; ... ; ln = expn }
|
|
</PRE>
|
|
<P></P>
|
|
<H4>Record projection</H4>
|
|
<P>
|
|
Fields are selected from records using the <CODE>.</CODE> operator. This expression selects
|
|
the field <CODE>l</CODE> from the record value <CODE>r</CODE>:
|
|
</P>
|
|
<PRE>
|
|
r.l
|
|
</PRE>
|
|
<P></P>
|
|
<H4>Records and layout syntax</H4>
|
|
<P>
|
|
The curly braces and semicolons are simply explicit layout syntax, so
|
|
the record type and record expression above can also be written as:
|
|
</P>
|
|
<PRE>
|
|
sig l1 : T1
|
|
...
|
|
ln : Tn
|
|
</PRE>
|
|
<P></P>
|
|
<PRE>
|
|
rec l1 = exp1
|
|
...
|
|
ln = expn
|
|
</PRE>
|
|
<P></P>
|
|
<A NAME="record_subtyping"></A>
|
|
<H4>Record subtyping</H4>
|
|
<P>
|
|
A record of some type R1 can be used as a record of any type R2
|
|
such that for every field <CODE>p1 : T1</CODE> in R2, <CODE>p1 : T1</CODE> is also a
|
|
field of T1.
|
|
</P>
|
|
<A NAME="tuples"></A>
|
|
<H3>Tuples</H3>
|
|
<P>
|
|
Tuples on the form:
|
|
</P>
|
|
<PRE>
|
|
(exp1, ..., expn)
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
are syntactic sugar for records with fields <CODE>p1</CODE> to <CODE>pn</CODE>. The expression
|
|
above is equivalent to:
|
|
</P>
|
|
<PRE>
|
|
rec { p1 = exp1; ... ; pn = expn }
|
|
</PRE>
|
|
<P></P>
|
|
<A NAME="toc13"></A>
|
|
<H3>Lists</H3>
|
|
<P>
|
|
The <CODE>List</CODE> type is not built-in, though there is some special syntax for it.
|
|
The list type is declared as:
|
|
</P>
|
|
<PRE>
|
|
data List : Type -> Type where
|
|
Nil : (A:Type) -> List A
|
|
Cons : (A:Type) -> A -> List A -> List A
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
The empty list can be written as <CODE>[]</CODE>. There is an operator <CODE>::</CODE> which can
|
|
be used instead of <CODE>Cons</CODE>. These are just syntactic sugar for expressions
|
|
using <CODE>Nil</CODE> and <CODE>Cons</CODE>, with the type arguments hidden.
|
|
</P>
|
|
<A NAME="toc14"></A>
|
|
<H2>Case expressions</H2>
|
|
<P>
|
|
Pattern matching is done in pattern equations and with the
|
|
<CODE>case</CODE> construct:
|
|
</P>
|
|
<PRE>
|
|
case exp of
|
|
p1 | guard1 -> rhs1
|
|
...
|
|
pn | guardn -> rhsn
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
where <CODE>p1</CODE> to <CODE>pn</CODE> are patterns, see <A HREF="#patterns">Patterns</A>.
|
|
<CODE>guard1</CODE> to <CODE>guardn</CODE> are boolean expressions. Case arms can also be written
|
|
without guards, such as:
|
|
</P>
|
|
<PRE>
|
|
pk -> rhsk
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
This is the same as writing:
|
|
</P>
|
|
<PRE>
|
|
pk | True -> rhsk
|
|
</PRE>
|
|
<P></P>
|
|
<A NAME="patterns"></A>
|
|
<H2>Patterns</H2>
|
|
<A NAME="toc16"></A>
|
|
<H3>Constructor patterns</H3>
|
|
<P>
|
|
Constructor patterns are written as:
|
|
</P>
|
|
<PRE>
|
|
C p1 ... pn
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
where <CODE>C</CODE> is a data constructor which takes <CODE>n</CODE> arguments.
|
|
If the value to be matched is <CODE>C v1 ... vn</CODE>,
|
|
then <CODE>v1</CODE> to <CODE>vn</CODE> will be matched against <CODE>p1</CODE> to <CODE>pn</CODE>.
|
|
</P>
|
|
<A NAME="toc17"></A>
|
|
<H3>Variable patterns</H3>
|
|
<P>
|
|
A variable pattern is a single identifier:
|
|
</P>
|
|
<PRE>
|
|
x
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
A variable pattern matches any value, and binds the variable name to the
|
|
value. A variable may not occur more than once in a pattern.
|
|
Note that variable patterns may not use the same identifier as data constructors
|
|
which are in scope, since they will then be interpreted as constructor
|
|
patterns.
|
|
</P>
|
|
<A NAME="toc18"></A>
|
|
<H3>Wildcard patterns</H3>
|
|
<P>
|
|
Wildcard patterns are written with a single underscore:
|
|
</P>
|
|
<PRE>
|
|
_
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Wildcard patterns match all values and bind no variables.
|
|
</P>
|
|
<A NAME="toc19"></A>
|
|
<H3>Record patterns</H3>
|
|
<P>
|
|
Record patterns match record values:
|
|
</P>
|
|
<PRE>
|
|
rec { l1 = p1; ... ; ln = pn }
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
A record value matches a record pattern if the record value has all the
|
|
fields <CODE>l1</CODE> to <CODE>ln</CODE>, and their values match <CODE>p1</CODE> to <CODE>pn</CODE>.
|
|
</P>
|
|
<P>
|
|
Note that a record value may have more fields than the record pattern.
|
|
The values of these fields do not influence the pattern matching.
|
|
</P>
|
|
<A NAME="toc20"></A>
|
|
<H3>Disjunctive patterns</H3>
|
|
<P>
|
|
It is possible to write a pattern on the form:
|
|
</P>
|
|
<PRE>
|
|
p1 || ... || pn
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
A value will match this pattern if it matches any of the patterns <CODE>p1</CODE> to <CODE>pn</CODE>.
|
|
FIXME: talk about how this is expanded
|
|
</P>
|
|
<A NAME="toc21"></A>
|
|
<H3>List patterns</H3>
|
|
<P>
|
|
When pattern matching on lists, there are two special constructs.
|
|
A whole list can by matched be a list of patterns:
|
|
</P>
|
|
<PRE>
|
|
[p1, ... , pn]
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
This pattern will match lists of length n, such that each element
|
|
in the list matches the corresponding pattern. The empty list pattern:
|
|
</P>
|
|
<PRE>
|
|
[]
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
is a special case of this. It matches the empty list, oddly enough.
|
|
</P>
|
|
<P>
|
|
Non-empty lists can also be matched with <CODE>::</CODE>-patterns:
|
|
</P>
|
|
<PRE>
|
|
p1::p2
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
This pattern matches non-empty lists such that the first element of
|
|
the list matches <CODE>p1</CODE> and the rest of the list matches <CODE>p2</CODE>.
|
|
</P>
|
|
<A NAME="toc22"></A>
|
|
<H3>Tuple patterns</H3>
|
|
<P>
|
|
Tuples patterns on the form:
|
|
</P>
|
|
<PRE>
|
|
(p1, ... , pn)
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
are syntactic sugar for record patterns, in the same way as
|
|
tuple expressions, see <A HREF="#tuples">Tuples</A>.
|
|
</P>
|
|
<A NAME="toc23"></A>
|
|
<H3>String literal patterns</H3>
|
|
<P>
|
|
String literals can be used as patterns.
|
|
</P>
|
|
<A NAME="toc24"></A>
|
|
<H3>Integer literal patterns</H3>
|
|
<P>
|
|
Integer literals can be used as patterns.
|
|
</P>
|
|
<A NAME="metavariables"></A>
|
|
<H2>Metavariables</H2>
|
|
<P>
|
|
Metavariables are written as questions marks:
|
|
</P>
|
|
<PRE>
|
|
?
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
A metavariable is a way to tell the type checker that:
|
|
"you should be able to figure out what this should be,
|
|
I can't be bothered to tell you".
|
|
</P>
|
|
<P>
|
|
Metavariables can be used to avoid having to give type
|
|
and dictionary arguments explicitly.
|
|
</P>
|
|
<A NAME="toc26"></A>
|
|
<H2>Overloaded functions</H2>
|
|
<P>
|
|
In Transfer, functions can be overloaded by having them take a record
|
|
of functions as an argument. For example, the functions for equality
|
|
and inequality in the Transfer <A HREF="#prelude">Prelude</A> are defined as:
|
|
</P>
|
|
<PRE>
|
|
Eq : Type -> Type
|
|
Eq A = sig eq : A -> A -> Bool
|
|
|
|
eq : (A : Type) -> Eq A -> A -> A -> Bool
|
|
eq _ d = d.eq
|
|
|
|
neq : (A : Type) -> Eq A -> A -> A -> Bool
|
|
neq A d x y = not (eq A d x y)
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
We call <CODE>Eq</CODE> a <I>type class</I>, though it's actually just a record type
|
|
used to pass function implementations to overloaded functions. We
|
|
call a value of type <CODE>Eq A</CODE> an Eq <I>dictionary</I> for the type A.
|
|
The dictionary is used to look up the version of some function for the
|
|
particular type we want to use the function on. Thus, in order to use
|
|
the <CODE>eq</CODE> function on two integers, we need a dictionary of type
|
|
<CODE>Eq Integer</CODE>:
|
|
</P>
|
|
<PRE>
|
|
eq_Integer : Eq Integer
|
|
eq_Integer = rec eq = prim_eq_Integer
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
where <CODE>prim_eq_Integer</CODE> is the built-in equality function for
|
|
integers. To check whether two numbers <CODE>x</CODE> and <CODE>y</CODE> are equal, we
|
|
can then call the overloaded <CODE>eq</CODE> function with the dictionary:
|
|
</P>
|
|
<PRE>
|
|
eq Integer eq_Integer x y
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
Giving the type at which to use the overloaded function, and the appropriate
|
|
dictionary can be cumbersome. <A HREF="#metavariables">Metavariables</A> come to the rescue:
|
|
</P>
|
|
<PRE>
|
|
eq ? ? x y
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
The type checker can in most cases figure out the values of the type and
|
|
dictionary arguments. <B>NOTE: this is not implemented yet.</B>
|
|
</P>
|
|
<A NAME="toc27"></A>
|
|
<H3>Type class extension</H3>
|
|
<P>
|
|
By using record subtyping, see <A HREF="#record_subtyping">Record subtyping</A>, we can
|
|
create type classes which extend other type classes. A dictionary for the
|
|
new type class can also be used as a dictionary for old type class.
|
|
</P>
|
|
<P>
|
|
For example, we can extend the <CODE>Eq</CODE> type class above to <CODE>Ord</CODE>, a type
|
|
class for orderings:
|
|
</P>
|
|
<PRE>
|
|
Ord : Type -> Type
|
|
Ord A = sig eq : A -> A -> Bool
|
|
compare : A -> A -> Ordering
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
To extend an existing class, we keep the fields of the class we want to
|
|
extend, and add any new fields that we want. Because of record subtyping,
|
|
for any type <CODE>A</CODE>, a value of type <CODE>Ord A</CODE> is also a value of type <CODE>Eq A</CODE>.
|
|
</P>
|
|
<A NAME="toc28"></A>
|
|
<H3>Extending multiple classes</H3>
|
|
<P>
|
|
A type class can also extend several classes, by simply having all the fields
|
|
from all the classes we want to extend. The <CODE>Num</CODE> class in the
|
|
<A HREF="#prelude">Standard prelude</A> is an example of this.
|
|
</P>
|
|
<A NAME="prelude"></A>
|
|
<H2>Standard prelude</H2>
|
|
<P>
|
|
The standard prelude, see <A HREF="../transfer/lib/prelude.tra">prelude.tra</A>,
|
|
contains definitions of a number of standard types, functions and
|
|
type classes.
|
|
</P>
|
|
<A NAME="toc30"></A>
|
|
<H2>Operators</H2>
|
|
<P>
|
|
Most built-in operators in the Transfer language are translated
|
|
to calls to overloaded functions. This means that they can be
|
|
used at any type for which there is a dictionary for the type class
|
|
in question.
|
|
</P>
|
|
<A NAME="toc31"></A>
|
|
<H3>Unary operators</H3>
|
|
<TABLE CELLPADDING="4" BORDER="1">
|
|
<TR>
|
|
<TH>Operator</TH>
|
|
<TH>Precedence</TH>
|
|
<TH>Translation</TH>
|
|
</TR>
|
|
<TR>
|
|
<TD><CODE>-</CODE></TD>
|
|
<TD ALIGN="center">10</TD>
|
|
<TD ALIGN="center"><CODE>-x => negate ? ? x</CODE></TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<P></P>
|
|
<A NAME="toc32"></A>
|
|
<H3>Binary operators</H3>
|
|
<TABLE CELLPADDING="4" BORDER="1">
|
|
<TR>
|
|
<TH>Operator</TH>
|
|
<TH>Precedence</TH>
|
|
<TH>Associativity</TH>
|
|
<TH>Translation of <CODE>x op y</CODE></TH>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>>>=</CODE></TD>
|
|
<TD ALIGN="center">3</TD>
|
|
<TD ALIGN="center">left</TD>
|
|
<TD ALIGN="center"><CODE>bind ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>>></CODE></TD>
|
|
<TD ALIGN="center">3</TD>
|
|
<TD ALIGN="center">left</TD>
|
|
<TD ALIGN="center"><CODE>bind ? ? x (\_ -> y)</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>||</CODE></TD>
|
|
<TD ALIGN="center">4</TD>
|
|
<TD ALIGN="center">right</TD>
|
|
<TD ALIGN="center"><CODE>if x then True else y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>&&</CODE></TD>
|
|
<TD ALIGN="center">5</TD>
|
|
<TD ALIGN="center">right</TD>
|
|
<TD ALIGN="center"><CODE>if x then y else False</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>==</CODE></TD>
|
|
<TD ALIGN="center">6</TD>
|
|
<TD ALIGN="center">none</TD>
|
|
<TD ALIGN="center"><CODE>eq ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>/=</CODE></TD>
|
|
<TD ALIGN="center">6</TD>
|
|
<TD ALIGN="center">none</TD>
|
|
<TD ALIGN="center"><CODE>neq ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE><</CODE></TD>
|
|
<TD ALIGN="center">6</TD>
|
|
<TD ALIGN="center">none</TD>
|
|
<TD ALIGN="center"><CODE>lt ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE><=</CODE></TD>
|
|
<TD ALIGN="center">6</TD>
|
|
<TD ALIGN="center">none</TD>
|
|
<TD ALIGN="center"><CODE>le ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>></CODE></TD>
|
|
<TD ALIGN="center">6</TD>
|
|
<TD ALIGN="center">none</TD>
|
|
<TD ALIGN="center"><CODE>gt ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>>=</CODE></TD>
|
|
<TD ALIGN="center">6</TD>
|
|
<TD ALIGN="center">none</TD>
|
|
<TD ALIGN="center"><CODE>ge ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>::</CODE></TD>
|
|
<TD ALIGN="center">7</TD>
|
|
<TD ALIGN="center">right</TD>
|
|
<TD ALIGN="center"><CODE>Cons ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>+</CODE></TD>
|
|
<TD ALIGN="center">8</TD>
|
|
<TD ALIGN="center">left</TD>
|
|
<TD ALIGN="center"><CODE>plus ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>-</CODE></TD>
|
|
<TD ALIGN="center">8</TD>
|
|
<TD ALIGN="center">left</TD>
|
|
<TD ALIGN="center"><CODE>minus ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>*</CODE></TD>
|
|
<TD ALIGN="center">9</TD>
|
|
<TD ALIGN="center">left</TD>
|
|
<TD ALIGN="center"><CODE>times ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>/</CODE></TD>
|
|
<TD ALIGN="center">9</TD>
|
|
<TD ALIGN="center">left</TD>
|
|
<TD ALIGN="center"><CODE>div ? ? x y</CODE></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN="center"><CODE>%</CODE></TD>
|
|
<TD ALIGN="center">9</TD>
|
|
<TD ALIGN="center">left</TD>
|
|
<TD ALIGN="center"><CODE>mod ? ? x y</CODE></TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<P></P>
|
|
<A NAME="toc33"></A>
|
|
<H2>Compositional functions</H2>
|
|
<A NAME="toc34"></A>
|
|
<H2>do notation</H2>
|
|
<P>
|
|
Sequences of operations in the Monad type class can be written
|
|
using do-notation, like in Haskell:
|
|
</P>
|
|
<PRE>
|
|
do x <- f
|
|
y <- g x
|
|
h y
|
|
</PRE>
|
|
<P></P>
|
|
<P>
|
|
is equivalent to:
|
|
</P>
|
|
<PRE>
|
|
f >>= \x -> g x >>= \y -> h y
|
|
</PRE>
|
|
|
|
<!-- html code generated by txt2tags 2.0 (http://txt2tags.sf.net) -->
|
|
<!-- cmdline: txt2tags transfer-reference.txt -->
|
|
</BODY></HTML>
|