diff options
Diffstat (limited to 'doc/reference/reference.verb.tex')
-rw-r--r-- | doc/reference/reference.verb.tex | 567 |
1 files changed, 323 insertions, 244 deletions
diff --git a/doc/reference/reference.verb.tex b/doc/reference/reference.verb.tex index ecc43834dd..56bdbbb9b1 100644 --- a/doc/reference/reference.verb.tex +++ b/doc/reference/reference.verb.tex @@ -993,13 +993,6 @@ parameters (\sref{sec:parameters}) of type $[]T$, because its result would violate the well-formedness rules for anonymous functions (\sref{sec:closures}). Hence, methods with call-by-name parameters always need to be applied to arguments immediately. -\item -If $p$ is a path (\sref{sec:paths}), then $p$ is implicitly converted to a -value of type \verb@p.type@ if the context requires it. -\item If an integer literal appears in a context which requires -one of the types \ver@byte@, \verb@short@, or \verb@char@, it -is implicity converted to that type, provided the value of the literal fits in -the numeric range described by the type. \end{itemize} \chapter{Basic Declarations and Definitions} @@ -1178,9 +1171,6 @@ inference (\sref{sec:local-type-inf}). VarDef \>::=\> Id [`:' Type] `=' Expr \> |\> Id `:' Type `=' `_' \end{verbatim} -\ifundefvar{ - PureDef \>::= \> $\VAR$ ValDcl {`,' ValDcl} -} A variable declaration \verb@var x: T@ is equivalent to declarations of a {\em getter function} \verb@x@ and a {\em setter function} @@ -1213,11 +1203,11 @@ The default value depends on the type \verb@T@ as follows: \verb@null@ & for all other types $T$. \end{tabular}\end{quote} -Both forms of variable defintion also introduce a getter function -\verb@x@ which returns the value currently assigned to the variable, -as well as a setter function \verb@x_=@ which changes the value -currently assigned to the variable. The functions have the same -signatures as for a variable declaration. +When they occur as members of a template, both forms of variable +defintion also introduce a getter function \verb@x@ which returns the +value currently assigned to the variable, as well as a setter function +\verb@x_=@ which changes the value currently assigned to the variable. +The functions have the same signatures as for a variable declaration. \example The following example shows how {\em properties} can be simulated in Scala. It defines a class \verb@TimeOfDayVar@ of time @@ -1227,7 +1217,7 @@ values to be assigned to these fields. The user code, on the other hand, accesses these fields just like normal variables. \begin{verbatim} -class TimeOfDayVar with { +class TimeOfDayVar { private var h: int = 0, m: int = 0, s: int = 0; def hours \== h; def hours_= (h: int) \>= \=if (0 <= h && h < 24) this.h = h @@ -1520,9 +1510,10 @@ definition. A constructor invocation is a function application \sref{sec:stable-ids}), \verb@c@ is a type name which either designates a class or defines an alias type for one, and \verb@(args)@ is an argument list, which matches one of the constructors of that -class. The prefix \verb@x.@ can be omitted. The argument list -\verb@(args)@ can also be omitted, in which case an empty argument -list \verb@()@ is implicitly added. +class. The prefix \verb@x.@ can be omitted. The class \verb@c@ must +conform to \verb@scala.AnyRef@, i.e.\ it may not be a value type. The +argument list \verb@(args)@ can also be omitted, in which case an +empty argument list \verb@()@ is implicitly added. \subsection{Base Classes} \label{sec:base-classes} @@ -2216,24 +2207,49 @@ module FileSystem with { \> |\> Id `#' Id \> |\> SimpleExpr TypeArgs \> |\> SimpleExpr ArgumentExpr + ArgumentExpr \>::=\> `(' Expr ')' + \> |\> BlockExpr + BlockExpr \>::=\> `{' CaseClause {CaseClause} `}' + \> |\> `{' Block `}' + Block \>::=\> {BlockStat `;'} [Expr] Exprs \>::= \> Expr {`,' Expr} \end{verbatim} Expressions are composed of operators and operands. Expression forms are -discussed subsequently in decreasing order of precedence. +discussed subsequently in decreasing order of precedence. \section{Literals} \syntax\begin{verbatim} SimpleExpr \=::= \= literal + literal \>::= \> intLit + \> |\> floatLit + \> |\> charLit + \> |\> stringLit + \> |\> symbolLit \end{verbatim} -Typing and evaluation of literals are analogous to Java. +Typing and evaluation of literals are generally as in Java. +An integer literal denotes an integer number. Its type is normally +\verb@int@. However, if the expected type \verb@pt@ of the expression +is either \verb@byte@, \verb@short@, or \verb@char@ and the integer +number fits in the numeric range defined by the type, then the number +is converted to \verb@pt@ and the expression's type is \verb@pt@. A +floating point literal denotes a single-precision or double precision +IEEE floating point number. A character literal denotes a Unicode +character. A string literal denotes a member of +\verb@java.lang.String@. + +A symbol literal \verb@'id@ is a shorthand for the expression +\verb@scala.Symbol("id")@. If the symbol literal is followed by an +actual parameters, as in \verb@'id(args)@, then the whole expression +is taken to be a shorthand for +\verb@scala.Labelled(scala.Symbol("id"), args)@. \section{Boolean constants} \begin{verbatim} - SimpleExpr \=::= \= true | false + SimpleExpr \=::= \= true | false \end{verbatim} The boolean truth values are denoted by the reserved words \verb@true@ @@ -2279,6 +2295,12 @@ it was $(\VAL;y=e\semi y.x)$ for some fresh name $y$. The typing rules for blocks implies that in that case $x$'s type may not refer to any abstract type member of \verb@e@. +The type of a designator is normally the type of the entity it refers +to. However, if the designator is a path \sref{sec:paths} \verb@p@ +it's type is \verb@p.type@, provided the expression's expected type is +a singleton type, or \verb@p@ occurs as the prefix of a selection, +type selection, or mixin super expression. + The selection $e.x$ is evaluated by first evaluating the qualifier expression $e$. The selection's result is then the value to which the selector identifier is bound in the selected object designated by $e$. @@ -2292,27 +2314,28 @@ selector identifier is bound in the selected object designated by $e$. \end{verbatim} The expression \verb@this@ can appear in the statement part of a -template or compound typw. It stands for the object being defined by +template or compound type. It stands for the object being defined by the innermost template or compound type enclosing the reference. If -this is a template forming part of a module or class definition, the -type of \verb@this@ is the self type of the definition; otherwise the -type of \verb@this@ is the type of the innermost enclosing template or -compund type itself. +this is a compound type, the type of \verb@this@ is the compount type. +If it is a template of an instance creation expression, the type of +\verb@this@ is the type of that template. If it is a template of a +class or object definition with simple name \verb@C@, the type of this +is the same as the type of \verb@C.this@. The expression \verb@C.this@ is legal in the statement part of an enclosing class or object definition with simple name \verb@C@. It stands for the object being defined by the innermost such definition. -Its type is the self type of that definition. +Its type is the self type of that definition if one is given; +otherwise its type is \verb@C.this.type@. A reference \verb@super.$m$@ in a template refers to the definition of \verb@m@ in the actual superclass (\sref{sec:base-classes}) of the template. A reference \verb@C.super.m@ refers to the definition of \verb@m@ in the actual superclass of the innermost enclosing class or -object definition enclosing the reference. The referred-to definition -of \verb@m@ must be concrete, or the template containing the reference -must contain a definition which has an \verb@override@ modifier and -which overrides \verb@m@. - +object definition enclosing the reference. The definition referred to +by \verb@super@ or \verb@C.super@ must be concrete, or the template +containing the reference must contain a definition which has an +\verb@override@ modifier and which overrides \verb@m@. \example\label{ex:super} Consider the following class definitions @@ -2344,8 +2367,8 @@ depending on whether \verb@B@ is used as defining class or as a mixin class. \end{verbatim} In the statement part of a template -the reference \verb@M # m@ refers to the definition of the member \verb@m@ in -the mixin parent class of the template with simple name \verb@@M. +the reference \verb@M#m@ refers to the definition of the member \verb@m@ in +the mixin parent class of the template with simple name \verb@M@. \example Consider the following class definitions: \begin{verbatim} @@ -2371,7 +2394,8 @@ trait Colored extends Shape { } \end{verbatim} -All three definitions of \verb@equals@ are combined in the class below, which makes use of \verb@super@ as well as mixin +All three definitions of \verb@equals@ are combined in the class +below, which makes use of \verb@super@ as well as mixin super references. \begin{verbatim} class BorderedColoredShape extends Shape with Bordered with Colored { @@ -2411,7 +2435,7 @@ of evaluating the rewritten right-hand side is finally converted to the function's declared result type, if one is given. The case where of a formal \verb@def@-parameter with a parameterless -method type \verb@[\,]T@ is treated specially. In this case, the +method type \verb@[]T@ is treated specially. In this case, the corresponding actual argument expression is not evaluated before the application. Instead, every use of the formal parameter on the right-hand side of the rewrite rule entails a re-evaluation of the @@ -2433,7 +2457,33 @@ will never produce a division-by-zero error at run-time, since the expression \verb@(y = 1/x)@ will be evaluated in the body of \verb@while@ only if the condition parameter is false. -\subsection{References to Overloaded Bindings} +\section{Type Applications} +\label{sec:type-app} +\syntax\begin{verbatim} + SimpleExpr \=::= \= SimpleExpr `[' Types `]' +\end{verbatim} + +A type application \verb@f[T$_1$, ..., T$_n$]@ instantiates a +polymorphic value \verb@f@ of type +\verb@[a$_1$ >: L$_1$ <: U$_1$, ..., a$_n$ >: L$_n$ <: U$_n$]S@ with +argument types \verb@T$_1$, ..., T$_n$@. Every argument type +\verb@T$_i$@ must obey corresponding bounds \verb@L$_i$@ and +\verb@U$_i$@. That is, for each \verb@i = 1 \commadots n@, we must +have \verb@L$_i \sigma$ <: T$_i$ <: U$_i \sigma$@, where $\sigma$ is the +substitution \verb@[a$_1$ := T$_1$, ..., a$_n$ := T$_n$]@. The type +of the application is \verb@S$\sigma$@. + +The function part \verb@f@ may also have some value type. In this case +the type application is taken to be equivalent to +\verb@f.apply[\verb@T$_1$, ..., T$_n$]@, i.e.\ the +application of an \verb@apply@ function defined by \verb@f@. + +Type applications can be omitted if local type inference +(\sref{sec:local-type-inf}) can infer best type parameters for a +polymorphic functions from the types of the actual function arguments +and the expected result type. + +\section{References to Overloaded Bindings} \label{sec:overloaded-refs} If a name \verb@f@ referenced in an identifier or selection is @@ -2443,137 +2493,89 @@ way this is done depends on whether or not \verb@f@ is used as a function. Let $\AA$ be the set of all type alternatives of \verb@f@. -Assume first that \verb@f@ is used as a function, as in -\verb@f(args)@. If there is precisely one alternative in \verb@\AA@ -which is a (possibly polymorphic) method type whose arity matches the -number of arguments given, that alternative is chosen. +Assume first that \verb@f@ appears as a function in an application, as +in \verb@f(args)@. If there is precisely one alternative in +\verb@\AA@ which is a (possibly polymorphic) method type whose arity +matches the number of arguments given, that alternative is chosen. Otherwise, let \verb@argtypes@ be the vector of types obtained by typing each argument with an undefined prototype. One determines first -the set of applicable alternatives. A method type alternative is -applicable if each type in \verb@argtypes@ conforms to the +the set of applicable alternatives. A method type alternative is {\em +applicable} if each type in \verb@argtypes@ is compatible with the corresponding formal parameter type in the alternative, and, if a -prototype is given, the method's result type conforms to it. A +prototype is given, the method's result type is compatible to it. A polymorphic method type is applicable if local type inference can determine type arguments so that the instantiated method type is -applicable. - -Let $\BB$ be the set of applicable alternatives. It is an error of -$\BB$ is empty. Otherwise, one chooses the most specific alternative - - - - +applicable. +Here, a type \verb@T@ is {\em compatible} to a type \verb@U@ if one of the +following three clauses applies: +\begin{enumerate} +\item +\verb@T@ conforms to \verb@U@. +\item +\verb@T@ is a parameterless method type \verb@[]T'@ and \verb@T'@ +conforms to \verb@U@. +\item +\verb@T@ is a monomorphic method type \verb@(ps$_1$) ... (ps$_n$)S@ which +can be converted to a function type \verb@T'@ by using the rules for +implicit conversions \sref{sec:impl-conv} and \verb@T'@ conforms to +\verb@U@. +\end{enumerate} - - - -and let \veeb@pt@ be the expected (result-) type of the expression. - - - - - -Let \verb@n $\geq$ 0@ be maximal such that there is a method -type of arity \verb@\geq n@ in \verb@\AA@, and \verb@f@ is a applied -to at least \verb@n@ argument lists, e.g.\ it is used as in -\verb@f;(args$_1$) \ldots (args$_n$)@. Let \verb@T$_p$@ be the -expected type of \verb@f;(args$_1$) \ldots (args$_n$)@ (which may be -partially undefined). For \verb@i \in 1 \commadots n@ let -\verb@{ts$_i$}@ be the list of types of \verb@{args$_i$}@ which are -obtained by typing each argument in \verb@{args$_i$}@ with a -completely undefined prototype. - -Among all {\em applicable} alternative types in \verb@\AA@ the compiler -selects one which {\em specializes} all others. - -A method type alternative of arity \verb@m \geq n@ is {\em applicable} if a -non-overloaded function of that type could legally be applied to -stable identifier lists \verb@{xs$_1$} \commadots xs$_n$@ of the argument types -\verb@{ts$_1$} -\commadots {ts$_n$}@, and the application's result type would match -\verb@T$_p$@. - -\comment{ -Method types which do not have a class constructor -\verb@class T@ as their result type always specialize -method types which do. For other pairs of method types, the -following applies: } -A parameterized method type \verb@(ps$_1$) -\ldots (ps$_m$) T@ where \verb@m > 0@ {\em specializes} some other -type \verb@U@ if \verb@U@ is applicable to arguments \verb@(ps$_1$)@ \ldots \verb@(ps$_m$)@. -A polymorphic method type \verb@[a$_1$ -\extends S$_1$ -\commadots a$_k$ \extends S$_k$] (ps$_1$) \ldots (ps$_m$) T@ specializes -a type \verb@U@ if \verb@(ps$_1$) \ldots (ps$_m$) T@ is more -specific than \verb@U@ under the assumption that for \verb@i = 1 \commadots k@ -each \verb@a$_i$@ is an abstract type name bounded by \verb@S$_i$@. - -If there is no applicable signature which specializes all other -applicable signatures, or if there is more than one, the application -is rejected for being ambiguous. +Let $\BB$ be the set of applicable alternatives. It is an error if +$\BB$ is empty. Otherwise, one chooses the {\em most specific} +alternative among the alternatives in $\BB$, according to the +following definition of being ``more specific''. +\begin{itemize} +\item +A method type \verb@(ps)T@ is more specific than some other +type \verb@S@ if \verb@S@ is applicable to arguments \verb@(ps)@. +\item +A polymorphic method type +\verb@[a$_1$ >: L$_1$ <: U$_1$, ..., a$_n$ >: L$_n$ <: U$_n$](ps)T@ is +more specific than some other type \verb@S@ if \verb@(ps)T@ is more +specific than \verb@S@ under the assumption that for +\verb@i = 1 \commadots n@ each \verb@a$_i$@ is an abstract type name +bounded from below by \verb@L$_i$@ and from above by \verb@U$_i$@. +\item +Any other type is always more specific than a parameterized method +type or a polymorphic type. +\end{itemize} +It is an error if there is no unique alternative in $\BB$ which is +more specific than all other alternatives in $\BB$. + +Assume next that \verb@f@ appears as a function in a type +application, as in \verb@f[targs]@. Then we choose an alternative in +$\AA$ which takes the same number of type parameters as there are +type arguments in \verb@targs@. It is an error if no such alternative +exists, or if it is not unique. + +Assume finally that \verb@f@ does not appear as a function in either +an application or a type application. If an expected type is given, +let \verb@BB@ be the set of those alternatives in \verb@AA@ which are +compatible to it. Otherwise, let \verb@BB@ be the same as \verb@AA@. +We choose in this case the most specific alternative among all +alternatives in \verb@BB@. It is an error if there is no unique +alternative in $\BB$ which is more specific than all other +alternatives in $\BB$. \example Consider the following definitions: \begin{verbatim} - class S extends B with {} - def f(x: S)(y: B) = ... - def f(x: B)(y: B) = ... - val s: S, b: B + class A extends B {} + def f(x: B, y: B) = ... + def f(x: A, y: B) = ... + val a: A, b: B \end{verbatim} -Then the application \verb@f(s)(s)@ refers to the first -definition of \verb@f@ whereas the application \verb@f(b)(b)@ +Then the application \verb@f(b, b)@ refers to the first +definition of \verb@f@ whereas the application \verb@f(a, a)@ refers to the second. Assume now we add a third overloaded definition \begin{verbatim} - def f(x: B)(y: S) = ... -\end{verbatim} -Then the application \verb@f(s)(s)@ is rejected for being ambiguous, since - no most specific applicable signature exists. - -\comment{ -\example Consider the following definitions - -\begin{verbatim} - class Point() with { ... } - module Point with { val origin = 0.0 } + def f(x: B, y: A) = ... \end{verbatim} - -Then the term namespace contains the overloaded binding -\verb@Point: ()constr Point \verb@\overload@ Point\verb@\Dollar@class@ -where \verb@C_{Point}@ stands for the (invisible) type of the module -\verb@Point@. Therefore the name \verb@Point@ identifies the -\verb@Point@ module, the expression \verb@Point.origin@ selects its \verb@origin@ -field, but \verb@Point()@ is an invocation of the \verb@Point@ -constructor. -} - -\section{Type Applications} -\label{sec:type-app} -\syntax\begin{verbatim} - SimpleExpr \=::= \= SimpleExpr `[' Types `]' -\end{verbatim} - -A type application \verb@f[T$_1$\commadots T$_n$]@ instantiates a polymorphic -value \verb@f@ of type \verb@[a$_1$ \extends B$_1$ \commadots a$_n$ \extends B$_n$] U@ with -argument types \verb@T$_1$ \commadots T$_n$@. Every argument type \verb@T$_i$@ must -conform to the corresponding bound type \verb@B$_i$@. That is, for each \verb@i = 1 -\commadots n@, we must have \verb@T$_i$ \conforms B$_i$\sigma@, where \verb@\sigma@ is -the substitution \verb@[a$_1$ := T$_1$, ..., a$_n$ := T$_n$]@. The type of the -application is \verb@U\sigma@. If the function part \verb@f@ has an overloaded -type \verb@T$_1$ \overload \ldots \overload T$_n$@ then excatly one alternative -\verb@T$_i$@ must have an \verb@n@-ary type parameter list, and this alternative -will be instantiated. - -The function part \verb@f@ may also have some value type. In this case the -type application is taken to be equivalent to -\verb@\verb@f@.apply[\verb@T$_1$\commadots T$_n$@]@, -i.e.\ the application of an \verb@apply@ function defined by \verb@f@. - -Type applications can be omitted if local type inference -(\sref{sec:local-type-inf}) can infer best type parameters for a -polymorphic functions from the types of the actual function arguments -and the expected result type. +Then the application \verb@f(a, a)@ is rejected for being ambiguous, since +no most specific applicable signature exists. \section{Instance Creation Expressions} \label{sec:inst-creation} @@ -2582,75 +2584,105 @@ and the expected result type. Expr4 \=::= \= new Template \end{verbatim} -A simple instance creation expression is \verb@\NEW;c@ where \verb@c@ is a -constructor invocation (\sref{sec:constr-invoke}). If \verb@c@ has type -\verb@class T@, then \verb@new c@ has type \verb@T@. -This type must conform to -type \verb@scala.AnyRef@. -The expression -is evaluated by creating a fresh object of type \verb@T@, which is is -initialized by evaluating \verb@c@. +A simple instance creation expression is \verb@new c@ where \verb@c@ +is a constructor invocation (\sref{sec:constr-invoke}). Let \verb@T@ +be the type of \verb@c@. Then \verb@T@ must denote a (a type instance +of) a reference class which is non-abstract, and which conforms to its self +type. The expression is evaluated by creating a fresh object of the +type \verb@T@, which is is initialized by evaluating \verb@c@. The +type of the expression is \verb@T@'s self type (which might be less +specific than \verb@T@). A general instance creation expression is -\verb@@\NEW;sc;\WITH;mc$_1$;\WITH;\ldots;\WITH;mc$_n$;\WITH;(stats)\verb@@ where \verb@n \geq -0@, \verb@sc@ as well as \verb@mc$_1$ \commadots mc$_n$@ are constructor invocations -(of types \verb@\CLASS;S, \CLASS;T$_1$ \commadots \CLASS;T$_n$@, say) and +\verb@new sc with mc$_1$ with ... with mc$_n$ {stats}@ where +\verb@n $\geq$ 0@, \verb@sc@ as well as \verb@mc$_1$, ..., mc$_n$@ are +constructor invocations (of types \verb@S, T$_1$, ...,T$_n$@, say) and \verb@stats@ is a statement sequence containing initializer statements and member definitions (\sref{sec:members}). The type of such an instance creation expression is then the compound type -\verb@S;\WITH;T$_1$;\WITH;\ldots;\WITH;T$_n$;\WITH;R@, where \verb@R@ is a -refinement (\sref{sec:refinements}) which declares exactly those -members of \verb@stats@ that override a member of \verb@S@ or \verb@T$_1$ \commadots -T$_n$@. This type must conform to -type \verb@scala.AnyRef@. -For this type to be well-formed, \verb@R@ may not reference types -defined in \verb@stats@ which do not themselves form part of \verb@R@. +\verb@S with T$_1$ with ... with T$_n$ {R}@, where \verb@{R}@ is a +refinement (\sref{sec:compound-types}) which declares exactly those +members of \verb@stats@ that override a member of \verb@S@ or +\verb@T$_1$, ..., T$_n$@. For this type to be well-formed, \verb@R@ +may not reference types defined in \verb@stats@ which do not +themselves form part of \verb@R@. The instance creation expression is evaluated by creating a fresh object, which is initialized by evaluating the expression template. \example Consider the class \begin{verbatim} -abstract class C with { - type T - val x: T - def f(x: T): Object +abstract class C { + type T; val x: T; def f(x: T): Object } \end{verbatim} and the instance creation expression \begin{verbatim} -C with { - type T = Int - val x: T = 1 - def f(x: T): T = y - val y: T = 2 -} +C { type T = Int; val x: T = 1; def f(x: T): T = y; val y: T = 2 } \end{verbatim} Then the created object's type is: \begin{verbatim} -C with { - type T = Int - val x: T - def f(x: T): T -} +C { type T = Int; val x: T; def f(x: T): T } \end{verbatim} The value \verb@y@ is missing from the type, since \verb@y@ does not override a member of \verb@C@. +\section{Blocks} +\label{sec:blocks} + +\syntax\begin{verbatim} + BlockExpr \=::= \= `{' Block `}' + Block \>::= \> [{BlockStat `;'} Expr] +\end{verbatim} + +A block expression +\verb@{s$_1$; ...; s$_n$; e} is constructed from a sequence of block statements \verb@s$_1$ +, ..., s$_n$@ and a final expression \verb@e@. The final expression +can be omitted, in which case the unit value \verb@()@ is assumed. + +%Whether or not the scope includes the statement itself +%depends on the kind of definition. + +The expected type of the final expression \verb@e@ is the expected +type of the block. The expected type of all preceding statements is +undefined. + +The type of a block \verb@s$_1$; ...; s$_n$; e@ is usually the type of +\verb@e@. That type must be equivalent to a type which does not refer +to an entity defined locally in the block. If this condition is +violated, but a fully defined expected type is given, the type of the +block is instead assumed to be the expected type. + +Evaluation of the block entails evaluation of its statement sequence, +followed by an evaluation of the final expression \verb@e@, which +defines the result of the block. + +\example +Written in isolation, +the block \verb@{ class C extends B {...} ; new C }@ is illegal, since its type +refers to class \verb@C@, which is defined locally in the block. + +However, when used in a definition such as +\begin{verbatim} +val x: B = { class C extends B {...} ; new C } +\end{verbatim} +the block is well-formed, since the problematic type \verb@C@ can be +replaced by the expected type \verb@B@. + \section{Prefix, Infix, and Postfix Operations} \label{sec:infix-operations} \syntax\begin{verbatim} - Expr2 \=::= \= Expr3 [id] - Expr3 \>::= \> Expr4 - \> | \> Expr3 Id Expr3 - Expr4 \>::= \> SimpleExpr - \> |\> (`+' | `-' | `!') Expr4 + PostfixExpr \>::=\> InfixExpr [Id] + InfixExpr \>::=\> PrefixExpr + \> |\> InfixExpr Id InfixExpr + PrefixExpr \>::=\> [`-' | `+' | `!' | `~'] SimpleExpr \end{verbatim} Expressions can be constructed from operands and operators. A prefix -operation \verb@op;e@ consists of a prefix operator \verb@op@, which must be one -of \verb@+@, \verb@-@, \verb@!@, and a simple expression \verb@e@. The +operation \verb@op e@ consists of a prefix operator \verb@op@, +which must be one of \verb@+@, \verb@-@, \verb@!@, or \verb@~@, +and a simple expression \verb@e@. The expression is equivalent to the postfix method application \verb@e.op@. Prefix operators are different from normal function applications in @@ -2681,10 +2713,9 @@ precedence, with characters on the same line having the same precedence. That is, operators starting with a letter have lowest precedence, followed by operators starting with `\verb@|@', etc. -The {\em associativity} of an operator -is also determined by the operator's first character. - Operators starting with a colon -`\verb@:@' are right-associative. All other operators are left-associative. +The {\em associativity} of an operator is determined by the operator's +last character. Operators ending with a colon `\verb@:@' are +right-associative. All other operators are left-associative. Precedence and associativity of operators determine the grouping of parts of an expression as follows. @@ -2693,40 +2724,42 @@ parts of an expression as follows. expression, then operators with higher precedence bind more closely than operators with lower precedence. \item If there are consecutive infix -operations \verb@e$_0$;op$_1$;e$_1$;op$_2$\ldots;op$_n$;e$_n$@ with operators \verb@op$_1$ -\commadots op$_n$@ of the same precedence, then all these operators must +operations \verb@e$_0$ op$_1$ e$_1$ op$_2$ ... op$_n$ e$_n$@ +with operators \verb@op$_1$, ..., op$_n$@ of the same precedence, +then all these operators must have the same associativity. If all operators are left-associative, -the sequence is interpreted as \verb@(\ldots(e$_0$;op$_1$;e$_1$);op$_2$;\ldots); -op$_n$;e$_n$@. Otherwise, if all operators are right-associative, the +the sequence is interpreted as +\verb@(...(e$_0$ op$_1$ e$_1$) op$_2$...) op$_n$ e$_n$@. +Otherwise, if all operators are right-associative, the sequence is interpreted as -\verb@e$_0$;op$_1$;(e$_1$;op$_2$;(\ldots;op$_n$;e$_n$)\ldots)@. +\verb@e$_0$ op$_1$ (e$_1$ op$_2$ (... op$_n$ e$_n$)...)@. \item Postfix operators always have lower precedence than infix -operators. E.g.\ \verb@e$_1$;op$_1$;e$_2$;op$_2$@ is always equivalent to -\verb@(e$_1$;op$_1$;e$_2$);op$_2$@. +operators. E.g.\ \verb@e$_1$ op$_1$ e$_2$ op$_2$@ is always equivalent to +\verb@(e$_1$ op$_1$ e$_2$) op$_2$@. \end{itemize} A postfix operation \verb@e;op@ is interpreted as \verb@e.op@. A -left-associative binary operation \verb@e$_1$;op;e$_2$@ is interpreted as +left-associative binary operation \verb@e$_1$ op e$_2$@ is interpreted as \verb@e$_1$.op(e$_2$)@. If \verb@op@ is right-associative, the same operation is -interpreted as \verb@(\VAL;x=e$_1$ -\semi e$_2$.op(x))@, where \verb@x@ is a fresh name. +interpreted as \verb@(val x=e$_1$; e$_2$.op(x))@, +where \verb@x@ is a fresh name. \section{Typed Expressions} \syntax\begin{verbatim} - Expr1 \=::= \= Expr2 [`:' Type] + Expr \=::= \= PostfixExpr [`:' Type1] \end{verbatim} -The typed expression \verb@e: T@ has type \verb@T@. The type of expression \verb@e@ -is required to conform to \verb@T@. The result of the expression is the -value of \verb@e@ converted to type \verb@T@. +The typed expression \verb@e: T@ has type \verb@T@. The type of +expression \verb@e@ is expected to conform to \verb@T@. The result of +the expression is the value of \verb@e@ converted to type \verb@T@. \example Here are examples of well-typed and illegal typed expressions. \begin{verbatim} - 1: Int \=// legal, of type Int - 1: Long \>// legal, of type Long - // 1: String \>// illegal + 1: int \=// legal, of type int + 1: long \>// legal, of type long + // 1: string \>// illegal \end{verbatim} \section{Assignments} @@ -2737,15 +2770,83 @@ value of \verb@e@ converted to type \verb@T@. \end{verbatim} An assignment to a simple variable \verb@x = e@ is interpreted as the invocation -\verb@\verb@x@$_=$(\verb@e@)@ of the setter function for variable +\verb@x_=(e)@ of the setter function for variable \verb@x@ (\sref{sec:vardef}). -Analogously, an assignment \verb@f.a = e@ to a field \verb@a@ is interpreted -as the invocation \verb@\verb@f.a@_=(\verb@e@)@. +Analogously, an assignment \verb@f.x = e@ to a field \verb@x@ is interpreted +as the invocation \verb@f.x_=(e)@. -An assignment \verb@f(is) = e@ with a function application to the -left of the ``\verb@=@' operator is interpreted as \verb@\verb@f@.update(\verb@is, e@)@, i.e.\ +An assignment \verb@f(args) = e@ with a function application to the +left of the ``\verb@=@' operator is interpreted as +\verb@f.update(args, e)@, i.e.\ the invocation of an \verb@update@ function defined by \verb@f@. +\example Here is the usual imperative code for matrix multiplication. + +\begin{verbatim} +def matmul(xs: Array[Array[double]], ys: Array[Array[double]]) = { + val zs: Array[Array[double]] = new Array(xs.length, ys.length); + var i = 0; + while (i < xs.length) { + var j = 0; + while (j < ys(0).length) { + var acc = 0.0; + var k = 0; + while (k < ys.length) { + acc = acc + xs(i)(k) * ys(k)(j); + k = k + 1 + } + zs(i)(j) = acc; + j = j + 1 + } + i = i + 1 + } + zs +} +\end{verbatim} +Desugaring the array accesses and assignments yields the following +expanded version: +\begin{verbatim} +def matmul(xs: Array[Array[double]], ys: Array[Array[double]]) = { + val zs: Array[Array[double]] = new Array(xs.length, ys.length); + var i = 0; + while (i < xs.length) { + var j = 0; + while (j < ys(0).length) { + var acc = 0.0; + var k = 0; + while (k < ys.length) { + acc = acc + xsa.apply(i).apply(k) * ys.apply(k).apply(j); + k = k + 1 + } + zs.apply(i).update(j, acc); + j = j + 1 + } + i = i + 1 + } + zs +} +\end{verbatim} + +\begin{verbatim} +def matmul(xss: Array[Array[double]], yss: Array[Array[double]]) = { + val ysst = transpose(yss); + for (val xs <- xs) yield + for (val ys <- ysst) yield + scalprod(xs, ys) +} + +def transpose[a](xss: Array[Array[a]]) { + for (val i <- Array.range(0, xss(0).length)) yield + Array(for (val xs <- xss) yield xs(i)) + +def scalprod(xs: Array[double], ys: Array[double]) { + var acc = 0.0; + for (val Pair(x, y) <- xs zip ys) do acc = acc + x * y; + acc +} +\end{verbatim} + + \section{Conditional Expressions} \syntax\begin{verbatim} @@ -3049,31 +3150,6 @@ $(T_1 \commadots T_n) U$. The expression is interpreted as \>// variable count and returns the new value. \end{verbatim} -\section{Blocks} -\label{sec:blocks} - -\syntax\begin{verbatim} - Block \=::= \= [{BlockStat `;'} Expr] -\end{verbatim} - -A block $s_1 \semi\ldots\semi s_n \semi e$ -is constructed from a sequence of block statements $s_1 \commadots s_n$ -and a final expression $e$. The final expression can be omitted, in -which case the unit value $()$ is assumed. - -Block statements may be definitions which bind local names in the -block. No modifiers are allowed in block-local definitions. - -%Whether or not the scope includes the statement itself -%depends on the kind of definition. - -The type of a block $s_1 \semi\ldots\semi s_n \semi e$ is the type of $e$. That -type must be equivalent to a type which does not refer to an entity -defined locally in the block. -Evaluation of the block entails -evaluation of its statement sequence, followed by an evaluation of the final expression -$e$, which defines the result of the block. - \section{Statements} \label{sec:statements} @@ -3097,6 +3173,9 @@ declarations. An expression that is used as a statement can have an arbitrary value type. An expression statement $e$ is evaluated by evaluating $e$ and discarding the result of the evaluation. +Block statements may be definitions which bind local names in the +block. No modifiers are allowed in block-local definitions. + With the exception of overloaded definitions (\sref{sec:overloaded-defs}), a statement sequence making up a block or template may not contain two definitions or declarations that bind |