Skip to content
This repository

Updates Scala specification for 2.10 #20

Closed
wants to merge 1 commit into from

5 participants

Josh Suereth Paolo G. Giarrusso Adriaan Moors odersky
soc commented May 14, 2012
  • Removed Octal literals
  • Disallowed FP literals without digit after dot
  • Removed val in for comprehension value definitions (Fixes SI-4918)
  • Added ## to the list of non-NPE-throwing Null methods (Fixes SI-4311)
  • Adapted some wording around AnyRef/AnyVal
  • Removed primitive type aliases (Fixes SI-4628)
  • Casting of null (Fixes second part of SI-4437)
  • Removed ScalaObject from the spec (Closes SI-4648)
  • Merged the changes of the PDF-only Scala-2.9-Draft manually
Updates Scala specification for 2.10
- Removed Octal literals
- Disallowed FP literals without digit after dot
- Removed val in for comprehension value definitions (Fixes SI-4918)
- Added ## to the list of non-NPE-throwing Null methods (Fixes SI-4311)
- Adapted some wording around AnyRef/AnyVal
- Removed primitive type aliases (Fixes SI-4628)
- Casting of null (Fixes second part of SI-4437)
- Removed ScalaObject from the spec (Closes SI-4648)
- Merged the changes of the PDF-only Scala-2.9-Draft manually
39337a8
Josh Suereth
Collaborator

Review by: @odersky

soc commented June 30, 2012

Any news on this?

  • Removed Octal literals is SI-5205
  • Disallowed FP literals without digit after dot is related to SI-265 (found no better issue)

I added links from the issues to this pull request, so that people don't mistakenly duplicate work.

Adriaan Moors adriaanm referenced this pull request in scala/scala April 04, 2013
Merged

SI-7292 Deprecate octal escape literals #2342

Paolo G. Giarrusso Blaisorblade commented on the diff June 27, 2013
documentation/src/reference/ReferencePart.tex
((8 lines not shown))
5784  
-trait Dynamic {
5785  
-  def applyDynamic (name: String, args: Any*): Any
5786  
-  ...
5787  
-}
5788  
-\end{lstlisting}
5789  
-Assume a selection of the form $e.x$ where the type of $e$ conforms to \lstinline@scala.Dynamic@.
5790  
-Further assuming the selection is not followed by any function arguments, such an expression can be rewitten under the conditions given in \sref{sec:impl-conv} to:
5791  
-\begin{lstlisting}
5792  
-$e$.applyDynamic("$x$")
5793  
-\end{lstlisting}
5794  
-If the selection is followed by some arguments, e.g.\ $e.x(\args)$, then that expression
5795  
-is rewritten to
5796  
-\begin{lstlisting}
5797  
-$e$.applyDynamic("$x$", $\args$)
5798  
-\end{lstlisting}
  5760
+% TODO
1

This doesn't seem mentioned in the issue description, and Scala does have scala.Dynamic (with some slightly different details). So I'm against merging this bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Paolo G. Giarrusso

I'd hope that some technical uncontroversial changes (say, to the grammar) could be merged after review by @adriaanm. If that were possible (and I think that should be possible and overdue), probably splitting somewhat the changes of this commit would help reviewing. Personally I'd have a commit per fixed issue, but that's my taste.

OTOH, I can totally get why @odersky would restrict maintenance of, say, the type system spec to type theory experts (or even to himself).

@soc wrote:

Merged the changes of the PDF-only Scala-2.9-Draft manually

Is that why you removed so much from documentation/src/reference/ImplementationStatus.tex and documentation/src/reference/RationalePart.tex? Because such changes can only be reviewed by @odersky himself, unless he already did them.

So I'd say that should be a separate commit at least for this part, also to ease reviewing.

Also, why is so much removed from "Dynamic Member Selection"?

Paolo G. Giarrusso

OTOH, I can totally get why @odersky would restrict maintenance of, say, the type system spec to type theory experts (or even to himself).

But yet again OTOH, I'd say that changes like scala/scala@e28c3ed should also be reflected in the spec: I'd like to know what exactly that change does, and I wouldn't want to debug a type error following the affected part of the spec.

soc commented June 27, 2013

@Blaisorblade I don't think the spec is updated anymore in its current form. I guess this commit probably only exists to remind people of the sad state. Sadly, I have heard no news about the new spec format since the guy who did it was hired (by Google?!) ... not sure about the details anymore.

Paolo G. Giarrusso

Last I knew, Martin had exclusive maintainership of the spec and was swamped on other work, I thought that was the reason (can't find the message in scala-internals or Google unfortunately). And a (partial? abandoned?) migration to some new format sounds a less valid argument. Would it be possible to do something?

soc commented June 27, 2013

Well, there is not much I can do about it ... I have accepted that the turn-around time has to be measured in months (spec), weeks (code) or years (website).

Adriaan Moors
Owner

I have scheduled some time to update the spec, but due to limited resources it'll have to wait until M5 at the earliest.

soc commented July 01, 2013

Nice to hear! (Although this pull request is probably not what you are looking for.) I had already split up the changes into 1 PR per change, but there hasn't been much progress recently (Iain seems to be pretty busy + more reasons here: iainmcgin/scala-ref-markdown#19): https://github.com/iainmcgin/scala-ref-markdown/pulls

George Leontiev folone referenced this pull request in scala/scala-lang July 30, 2013
Closed

Update language reference link #80

odersky
Collaborator

Thanks for the changes. (and sorry for not responding sooner, I was not aware of the request). Can you please split the pull request into separate ones for each topic? Most of them look good but a few warrant further discussion. For instance, I am inclined to leave the rationale in for historic reasons. Many thanks in advance.

I'm currently extremely busy (exams), but I'll split them as soon as I have some time.

@odersky Done. See #97, #98, #99, #100, #101, #102, #103.

odersky odersky closed this October 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 1 unique commit by 1 author.

May 15, 2012
Updates Scala specification for 2.10
- Removed Octal literals
- Disallowed FP literals without digit after dot
- Removed val in for comprehension value definitions (Fixes SI-4918)
- Added ## to the list of non-NPE-throwing Null methods (Fixes SI-4311)
- Adapted some wording around AnyRef/AnyVal
- Removed primitive type aliases (Fixes SI-4628)
- Casting of null (Fixes second part of SI-4437)
- Removed ScalaObject from the spec (Closes SI-4648)
- Merged the changes of the PDF-only Scala-2.9-Draft manually
39337a8
This page is out of date. Refresh to see the latest.
50  documentation/src/reference/ImplementationStatus.tex
... ...
@@ -1,50 +0,0 @@
1  
-
2  
-The present Scala compiler does not yet implement all of the Scala
3  
-specification. Its currently existing omissions and deviations are
4  
-listed below. We are working on a refined implementation that
5  
-addresses these issues.
6  
-\begin{enumerate}
7  
-\item
8  
-Unicode support is still limited. At present we only permit Unicode
9  
-encodings \verb@\uXXXX@ in strings and backquote-enclosed identifiers.
10  
-To define or access a Unicode identifier, you need to put it in
11  
-backquotes and use the \verb@\uXXXX@ encoding.
12  
-\item 
13  
-The unicode operator ``$\Rightarrow$''
14  
-(\sref{sec:idents}) is not yet recognized; you need to use the two
15  
-character ASCII equivalent ``\code{=>}'' instead.
16  
-\item
17  
-The current implementation does not yet support run-time types.
18  
-All types are erased (\sref{sec:erasure}) during compilation. This means that
19  
-the following operations give potentially wrong results.
20  
-\begin{itemize}
21  
-\item
22  
-Type tests and type casts to parameterized types. Here it is only tested
23  
-that a value is an instance of the given top-level type constructor.
24  
-\item
25  
-Type tests and type casts to type parameters and abstract types.  Here
26  
-it is only tested that a value is an instance of the type parameter's upper bound.  
27  
-\item
28  
-Polymorphic array creation. If \code{t} is a type variable or abstract type, then
29  
-\code{new Array[t]} will yield an array of the upper bound of \code{t}.
30  
-\end{itemize}
31  
-\item
32  
-Return expressions are not yet permitted inside an anonymous function
33  
-or inside a call-by-name argument (i.e.\ a function argument corresponding to a 
34  
-\code{def} parameter).
35  
-\item
36  
-Members of the empty package (\sref{sec:packagings}) cannot yet be
37  
-accessed from other source files.  Hence, all library classes and
38  
-objects have to be in some package.
39  
-\item
40  
-At present, auxiliary constructors (\sref{sec:constr-defs}) are only permitted
41  
-for monomorphic classes.
42  
-\item
43  
-The \code{Array} class supports as yet only a restricted set of
44  
-operations as given in \sref{cls:array}. It is planned to extend that
45  
-interface. In particular, arrays will implement the \code{scala.Seq}
46  
-trait as well as the methods needed to support for-comprehensions.
47  
-\item
48  
-At present, all classes used as mixins must be accessible to the Scala
49  
-compiler in source form.
50  
-\end{enumerate}
163  documentation/src/reference/RationalePart.tex
... ...
@@ -1,163 +0,0 @@
1  
-
2  
-There are hundreds of programming languages in active use, and many
3  
-more are being designed each year. It is therefore hard to justify the
4  
-development of yet another language. Nevertheless, this is what we
5  
-attempt to do here.  Our argument is based on two claims:
6  
-\begin{itemize}
7  
-\item[] {\em Claim 1:} The raise in importance of web services and
8  
-other distributed software is a fundamental paradigm
9  
-shift in programming. It is comparable in scale to the shift 20 years ago
10  
-from character-oriented to graphical user interfaces.
11  
-\item[] {\em Claim 2:} That paradigm shift will provide demand
12  
-for new programming languages, just as graphical user interfaces
13  
-promoted the adoption of object-oriented languages.
14  
-\end{itemize}
15  
-For the last 20 years, the most common programming model was
16  
-object-oriented: System components are objects, and computation is
17  
-done by method calls.  Methods themselves take object references as
18  
-parameters. Remote method calls let one extend this programming model
19  
-to distributed systems. The problem of this model is that it does not
20  
-scale up very well to wide-scale networks where messages can be
21  
-delayed and components may fail. Web services address the message
22  
-delay problem by increasing granularity, using method calls with
23  
-larger, structured arguments, such as XML trees.  They address the
24  
-failure problem by using transparent replication and avoiding server
25  
-state.  Conceptually, they are {\em tree transformers} that consume
26  
-incoming message documents and produce outgoing ones.  \comment{ To
27  
-back up the first claim, one observes that web services and other
28  
-distributed software increasingly tend to communicate using structured
29  
-or semi-structured data. A typical example is the use of XML to
30  
-describe data managed by applications as well as the messages between
31  
-applications. This tends to affect the role of a program in a
32  
-fundamental way. Previously, programs could be seen as objects that
33  
-reacted to method calls and in turn called methods of other
34  
-objects. Some of these method calls might originate from users while
35  
-others might originate from other computers via remote invocations.
36  
-These method calls have simple unstructured parameters or object
37  
-references as arguments.  Web services, on the other hand, communicate
38  
-with each other by transmitting asynchronous messages that carry
39  
-structured documents, usually in XML format. Programs then
40  
-conceptually become {\em tree transformers} that consume incoming
41  
-message documents and produce outgoing ones.  }
42  
-
43  
-Why should this have an effect on programming languages? There are at
44  
-least two reasons: First, today's object-oriented languages are not
45  
-very good at analyzing and transforming XML trees. Because such trees
46  
-usually contain data but no methods, they have to be decomposed and
47  
-constructed from the ``outside'', that is from code which is external
48  
-to the tree definition itself. In an object-oriented language, the
49  
-ways of doing so are limited. The most common solution \cite{w3c:dom} is
50  
-to represent trees in a generic way, where all tree nodes are values
51  
-of a common type.  This makes it easy to write generic traversal
52  
-functions, but forces applications to operate on a very low conceptual
53  
-level, which often loses important semantic distinctions present in
54  
-the XML data.  More semantic precision is obtained if different
55  
-internal types model different kinds of nodes.  But then tree
56  
-decompositions require the use of run-time type tests and type casts
57  
-to adapt the treatment to the kind of node encountered. Such type
58  
-tests and type casts are generally not considered good object-oriented
59  
-style. They are rarely efficient, nor easy to use.
60  
-
61  
-
62  
-By contrast, tree transformation is the natural domain of functional
63  
-languages. Their algebraic data types, pattern matching and
64  
-higher-order functions make these languages ideal for the task. It's
65  
-no wonder, then, that specialized languages for transforming XML data
66  
-such as XSLT are functional.
67  
-
68  
-Another reason why functional language constructs are attractive for
69  
-web-services is that mutable state is problematic in this setting.
70  
-Components with mutable state are harder to replicate or to restore
71  
-after a failure. Data with mutable state is harder to cache than
72  
-immutable data. Functional language constructs make it relatively easy
73  
-to construct components without mutable state.
74  
-
75  
-Many web services are constructed by combining different languages.
76  
-For instance, a service might use XSLT to handle document
77  
-transformation, XQuery for database access, and Java for the
78  
-``business logic''.  The downside of this approach is that the
79  
-necessary amount of cross-language glue can make applications
80  
-cumbersome to write, verify, and maintain. A particular problem is
81  
-that cross-language interfaces are usually not statically typed.
82  
-Hence, the benefits of a static type system are missing where they are
83  
-needed most -- at the join points of components written in different
84  
-paradigms.  
85  
-
86  
-Conceivably, the glue problem could be addressed by a ``multi-paradigm''
87  
-language that would express object-oriented, concurrent, as well
88  
-as functional aspects of an application.  But one needs to be careful
89  
-not to simply replace cross-language glue by awkward interfaces
90  
-between different paradigms within the language itself.  Ideally, one
91  
-would hope for a fusion which unifies concepts found in different
92  
-paradigms instead of an agglutination, which merely includes them side
93  
-by side.  This fusion is what we try to achieve with Scala
94  
-\footnote{Scala stands for ``Scalable Language''. The term means
95  
-  ``Stairway'' in Italian}.
96  
-
97  
-Scala is both an object-oriented and functional language.  It is a
98  
-pure object-oriented language in the sense that every value is an
99  
-object. Types and behavior of objects are described by
100  
-classes. Classes can be composed using mixin composition.  Scala is
101  
-designed to work seamlessly with mainstream object-oriented languages,
102  
-in particular Java and C\#.
103  
-
104  
-Scala is also a functional language in the sense that every function
105  
-is a value. Nesting of function definitions and higher-order functions
106  
-are naturally supported. Scala also supports a general notion of
107  
-pattern matching which can model the algebraic types used in many
108  
-functional languages. Furthermore, this notion of pattern matching
109  
-naturally extends to the processing of XML data.
110  
-
111  
-The design of Scala is driven by the desire to unify object-oriented
112  
-and functional elements. Here are three examples how this is achieved:
113  
-\begin{itemize}
114  
-\item
115  
-Since every function is a value and every value is an object, it
116  
-follows that every function in Scala is an object. Indeed, there is a
117  
-root class for functions which is specialized in the Scala standard
118  
-library to data structures such as arrays and hash tables.
119  
-\item
120  
-Data structures in many functional languages are defined using
121  
-algebraic data types. They are decomposed using pattern matching.
122  
-Object-oriented languages, on the other hand, describe data with class
123  
-hierarchies. Algebraic data types are usually closed, in that the
124  
-range of alternatives of a type is fixed when the type is defined.  By
125  
-contrast, class hierarchies can be extended by adding new leaf
126  
-classes.  Scala adopts the object-oriented class hierarchy scheme for
127  
-data definitions, but allows pattern matching against values coming
128  
-from a whole class hierarchy, not just values of a single type.
129  
-This can express both closed and extensible data types, and also
130  
-provides a convenient way to exploit run-time type information in
131  
-cases where static typing is too restrictive.
132  
-\item
133  
-Module systems of functional languages such as SML or Caml excel in
134  
-abstraction; they allow very precise control over visibility of names
135  
-and types, including the ability to partially abstract over types.  By
136  
-contrast, object-oriented languages excel in composition; they offer
137  
-several composition mechanisms lacking in module systems, including
138  
-inheritance and unlimited recursion between objects and classes.
139  
-Scala unifies the notions of object and module, of module signature
140  
-and interface, as well as of functor and class. This combines the
141  
-abstraction facilities of functional module systems with the
142  
-composition constructs of object-oriented languages. The unification
143  
-is made possible by means of a new type system based on path-dependent
144  
-types \cite{odersky-et-al:fool10}.
145  
-\end{itemize}
146  
-There are several other languages that try to bridge the gap between
147  
-the functional and object oriented
148  
-paradigms. Smalltalk\cite{goldberg-robson:smalltalk-language},
149  
-Python\cite{rossum:python}, or Ruby\cite{matsumtoto:ruby} come to
150  
-mind. Unlike these languages, Scala has an advanced static type
151  
-system, which contains several innovative constructs.  This aspect
152  
-makes the Scala definition a bit more complicated than those of the
153  
-languages above. On the other hand, Scala enjoys the robustness,
154  
-safety and scalability benefits of strong static typing. Furthermore,
155  
-Scala incorporates recent advances in type inference, so that
156  
-excessive type annotations in user programs can usually be avoided.
157  
-
158  
-% rest of this report is structured as follows. Chapters
159  
-%\ref{sec:simple-examples} to \ref{sec:concurrency} give an informal overview of
160  
-%Scala by means of a sequence of program examples.  The remaining
161  
-%chapters contain the language definition. The definition is formulated
162  
-%in prose but tries to be precise.
163  
-
129  documentation/src/reference/ReferencePart.tex
@@ -409,13 +409,11 @@ \section{Literals}\label{sec:literals}
409 409
 \subsection{Integer Literals}
410 410
 
411 411
 \syntax\begin{lstlisting}
412  
-integerLiteral  ::=  (decimalNumeral | hexNumeral | octalNumeral) [`L' | `l']
  412
+integerLiteral  ::=  (decimalNumeral | hexNumeral) [`L' | `l']
413 413
 decimalNumeral  ::=  `0' | nonZeroDigit {digit}
414 414
 hexNumeral      ::=  `0' `x' hexDigit {hexDigit}
415  
-octalNumeral    ::=  `0' octalDigit {octalDigit}
416 415
 digit           ::=  `0' | nonZeroDigit
417 416
 nonZeroDigit    ::=  `1' | $\cdots$ | `9'
418  
-octalDigit      ::=  `0' | $\cdots$ | `7'
419 417
 \end{lstlisting}
420 418
 Integer literals are usually of type \lstinline@Int@, or of type
421 419
 \lstinline@Long@ when followed by a \lstinline@L@ or
@@ -441,13 +439,13 @@ \subsection{Integer Literals}
441 439
 \example
442 440
 Here are some integer literals:
443 441
 \begin{lstlisting}
444  
-0          21          0xFFFFFFFF       0777L
  442
+0          21          0xFFFFFFFF       -42L
445 443
 \end{lstlisting}
446 444
 
447 445
 \subsection{Floating Point Literals}
448 446
 
449 447
 \syntax\begin{lstlisting}
450  
-floatingPointLiteral  ::=  digit {digit} `.' {digit} [exponentPart] [floatType]
  448
+floatingPointLiteral  ::=  digit {digit} `.' digit {digit} [exponentPart] [floatType]
451 449
                         |  `.' digit {digit} [exponentPart] [floatType]
452 450
                         |  digit {digit} exponentPart [floatType]
453 451
                         |  digit {digit} [exponentPart] floatType
@@ -472,16 +470,10 @@ \subsection{Floating Point Literals}
472 470
 \end{lstlisting}
473 471
 
474 472
 \example
475  
-The phrase `\lstinline@1.toString@' parses as three different tokens:
476  
-`\lstinline@1@', `\lstinline@.@', and `\lstinline@toString@'. On the
477  
-other hand, if a space is inserted after the period, the phrase
478  
-`\lstinline@1. toString@' parses as the floating point literal
479  
-`\lstinline@1.@' followed by the identifier `\lstinline@toString@'.
480  
-
481  
-
482  
-
483  
-
484  
-
  473
+`\lstinline@1.@' is not a valid floating point literal, because the 
  474
+mandatory digit after the `\lstinline@.@' is missing. For instance 
  475
+the phrase `\lstinline@1.toString@' parses as three different tokens:
  476
+`\lstinline@1@', `\lstinline@.@', and `\lstinline@toString@'.
485 477
 
486 478
 \subsection{Boolean Literals}
487 479
 
@@ -544,11 +536,11 @@ \subsubsection*{Multi-Line String Literals}
544 536
 
545 537
 A multi-line string literal is a sequence of characters enclosed in
546 538
 triple quotes ~\lstinline@""" ... """@. The sequence of characters is
547  
-arbitrary, except that it may contain three or more consuctive quote characters
548  
-only at the very end. Characters
549  
-must not necessarily be printable; newlines or other
550  
-control characters are also permitted.  Unicode escapes work as everywhere else, but none
551  
-of the escape sequences in (\sref{sec:escapes}) is interpreted.
  539
+arbitrary, except that it may contain three or more consecutive quote
  540
+characters only at the very end. Characters must not necessarily be
  541
+printable; newlines or other control characters are also permitted.
  542
+Unicode escapes work as everywhere else, but none of the escape sequences
  543
+in (\sref{sec:escapes}) is interpreted.
552 544
 
553 545
 \example Here is a multi-line string literal:
554 546
 \begin{lstlisting}
@@ -1007,7 +999,7 @@ \subsection{Tuple Types}\label{sec:tuple-types}
1007 999
 extends Product$n$[T1, ..., T$n$] {}
1008 1000
 
1009 1001
 trait Product$n$[+T1, +T2, +T$n$] {
1010  
-  override def arity = $n$
  1002
+  override def productArity = $n$
1011 1003
   def _1: T1
1012 1004
   ...
1013 1005
   def _$n$:T$n$
@@ -1929,7 +1921,7 @@ \section{Value Declarations and Definitions}
1929 1921
 
1930 1922
 1. If the pattern $p$ has bound variables $x_1 \commadots x_n$, where $n > 1$:
1931 1923
 \begin{lstlisting}
1932  
-val $\Dollar x$ = $e$ match {case $p$ => {$x_1 \commadots x_n$}}
  1924
+val $\Dollar x$ = $e$ match {case $p$ => ($x_1 \commadots x_n$)}
1933 1925
 val $x_1$ = $\Dollar x$._1
1934 1926
 $\ldots$
1935 1927
 val $x_n$ = $\Dollar x$._n  .
@@ -1959,7 +1951,7 @@ \section{Value Declarations and Definitions}
1959 1951
 \begin{lstlisting}
1960 1952
 val x = f() match { case Some(x) => x }
1961 1953
 
1962  
-val x$\Dollar$ = mylist match { case x :: xs => {x, xs} }
  1954
+val x$\Dollar$ = mylist match { case x :: xs => (x, xs) }
1963 1955
 val x = x$\Dollar$._1 
1964 1956
 val xs = x$\Dollar$._2 
1965 1957
 \end{lstlisting}
@@ -2029,7 +2021,7 @@ \section{Variable Declarations and Definitions}
2029 2021
 \lstinline@0.0f@ & if $T$ is \code{Float},\\
2030 2022
 \lstinline@0.0d@ & if $T$ is \code{Double},\\
2031 2023
 \code{false} & if $T$ is \code{Boolean},\\
2032  
-\lstinline@{}@ & if $T$ is \code{Unit}, \\
  2024
+\lstinline@()@ & if $T$ is \code{Unit}, \\
2033 2025
 \code{null} & for all other types $T$.
2034 2026
 \end{tabular}\end{quote}
2035 2027
 When they occur as members of a template, both forms of variable
@@ -2285,7 +2277,7 @@ \section{Variance Annotations}\label{sec:variances}
2285 2277
 the variance position of the enclosing type ~\lstinline@$S$[$\ldots T \ldots$ ]@.
2286 2278
 \end{itemize}
2287 2279
 \todo{handle type aliases}
2288  
-References to the type parameters in object-private values, variables,
  2280
+References to the type parameters in object-private or object-protected values, variables,
2289 2281
 or methods (\sref{sec:modifiers}) of the class are not checked for their variance
2290 2282
 position. In these members the type parameter may appear anywhere
2291 2283
 without restricting its legal variance annotations.
@@ -2519,7 +2511,7 @@ \subsection{Procedures}\label{sec:procedures}
2519 2511
 \end{lstlisting}
2520 2512
 
2521 2513
 Special syntax exists for procedures, i.e.\ functions that return the
2522  
-\verb@Unit@ value \verb@{}@. 
  2514
+\verb@Unit@ value \verb@()@. 
2523 2515
 A procedure declaration is a function declaration where the result type
2524 2516
 is omitted. The result type is then implicitly completed to the
2525 2517
 \verb@Unit@ type. E.g., ~\lstinline@def $f$($\ps$)@~ is equivalent to
@@ -2769,17 +2761,6 @@ \section{Templates}
2769 2761
 the first parent class of a template is a regular superclass
2770 2762
 constructor, not a trait reference.
2771 2763
 
2772  
-The list of parents of every class is also always implicitly extended
2773  
-by a reference to the \code{scala.ScalaObject} trait as last
2774  
-mixin. E.g.\
2775  
-\begin{lstlisting}
2776  
-$sc$ with $mt_1$ with $\ldots$ with $mt_n$ {$\stats\,$}
2777  
-\end{lstlisting}
2778  
-becomes
2779  
-\begin{lstlisting}
2780  
-$mt_1$ with $\ldots$ with $mt_n$ with ScalaObject {$\stats\,$}.
2781  
-\end{lstlisting}
2782  
-
2783 2764
 The list of parents of a template must be well-formed. This means that
2784 2765
 the class denoted by the superclass constructor $sc$ must be a
2785 2766
 subclass of the superclasses of all the traits $mt_1 \commadots mt_n$.
@@ -2947,10 +2928,8 @@ \subsection{Class Linearization}\label{sec:linearization}
2947 2928
 \end{lstlisting}
2948 2929
 Then the linearization of class \lstinline@Iter@ is
2949 2930
 \begin{lstlisting}
2950  
-{ Iter, RichIterator, StringIterator, AbsIterator, ScalaObject, AnyRef, Any }
  2931
+{ Iter, RichIterator, StringIterator, AbsIterator, AnyRef, Any }
2951 2932
 \end{lstlisting}
2952  
-Trait \lstinline@ScalaObject@ appears in this list because it 
2953  
-is added as last mixin to every Scala class (\sref{sec:templates}).
2954 2933
 
2955 2934
 Note that the linearization of a class refines the inheritance
2956 2935
 relation: if $C$ is a subclass of $D$, then $C$ precedes $D$ in any
@@ -2960,13 +2939,13 @@ \subsection{Class Linearization}\label{sec:linearization}
2960 2939
 as a suffix.  For instance, the linearization of
2961 2940
 \lstinline@StringIterator@ is
2962 2941
 \begin{lstlisting}
2963  
-{ StringIterator, AbsIterator, ScalaObject, AnyRef, Any }
  2942
+{ StringIterator, AbsIterator, AnyRef, Any }
2964 2943
 \end{lstlisting}
2965 2944
 which is a suffix of the linearization of its subclass \lstinline@Iter@.
2966 2945
 The same is not true for the linearization of mixins.
2967 2946
 For instance, the linearization of \lstinline@RichIterator@ is
2968 2947
 \begin{lstlisting}
2969  
-{ RichIterator, AbsIterator, ScalaObject, AnyRef, Any }
  2948
+{ RichIterator, AbsIterator, AnyRef, Any }
2970 2949
 \end{lstlisting}
2971 2950
 which is not a suffix of the linearization of \lstinline@Iter@.
2972 2951
 
@@ -3279,7 +3258,7 @@ \section{Modifiers}
3279 3258
 templates inside $C$.
3280 3259
 
3281 3260
 An different form of qualification is \code{private[this]}. A member
3282  
-$M$ marked with this modifier can be accessed only from within
  3261
+$M$ marked with this modifier is called {\em object-protected}; it can be accessed only from within
3283 3262
 the object in which it is defined. That is, a selection $p.M$ is only
3284 3263
 legal if the prefix is \code{this} or \lstinline@$O$.this@, for some
3285 3264
 class $O$ enclosing the reference. In addition, the restrictions for
@@ -4036,9 +4015,10 @@ \section{The {\em Null} Value}
4036 4015
 \item
4037 4016
 \lstinline@isInstanceOf[$T\,$]@ always returns \code{false}.
4038 4017
 \item
4039  
-\lstinline@asInstanceOf[$T\,$]@ returns the ``null'' object itself if
4040  
-$T$ conforms to \lstinline@scala.AnyRef@, and throws a
4041  
-\lstinline@NullPointerException@ otherwise.
  4018
+\lstinline@asInstanceOf[$T\,$]@ returns the default value of that type, as
  4019
+specified in \sref{sec:vardef}.
  4020
+\item
  4021
+\lstinline@##@ returns \lstinline@0@.
4042 4022
 \end{itemize}
4043 4023
 A reference to any other member of the ``null'' object causes a
4044 4024
 \code{NullPointerException} to be thrown. 
@@ -4912,7 +4892,7 @@ \section{For Comprehensions and For Loops}\label{sec:for-comprehensions}
4912 4892
   Enumerators    ::=  Generator {semi Enumerator}
4913 4893
   Enumerator     ::=  Generator 
4914 4894
                    |  Guard
4915  
-                   |  `val' Pattern1 `=' Expr
  4895
+                   |  Pattern1 `=' Expr
4916 4896
   Generator      ::=  Pattern1 `<-' Expr [Guard]
4917 4897
   Guard          ::=  `if' PostfixExpr
4918 4898
 \end{lstlisting}
@@ -5409,7 +5389,7 @@ \subsection{Value Conversions}
5409 5389
 \paragraph{\em View Application}
5410 5390
 If none of the previous conversions applies, and $e$'s type
5411 5391
 does not conform to the expected type $\proto$, it is attempted to convert
5412  
-$e$ to the expected type with a view (\sref{sec:views}).\bigskip
  5392
+$e$ to the expected type with a view (\sref{sec:views}).
5413 5393
 
5414 5394
 \paragraph{\em Dynamic Member Selection}
5415 5395
 If none of the previous conversions applies, and $e$ is a prefix
@@ -5777,25 +5757,7 @@ \subsection{Eta Expansion}\label{sec:eta-expand}
5777 5757
 
5778 5758
 \subsection{Dynamic Member Selection}\label{sec:dyn-mem-sel}
5779 5759
 
5780  
-The standard Scala library defines a trait \lstinline@scala.Dynamic@ which defines a member
5781  
-\@invokeDynamic@ as follows:
5782  
-\begin{lstlisting}
5783  
-package scala
5784  
-trait Dynamic {
5785  
-  def applyDynamic (name: String, args: Any*): Any
5786  
-  ...
5787  
-}
5788  
-\end{lstlisting}
5789  
-Assume a selection of the form $e.x$ where the type of $e$ conforms to \lstinline@scala.Dynamic@.
5790  
-Further assuming the selection is not followed by any function arguments, such an expression can be rewitten under the conditions given in \sref{sec:impl-conv} to:
5791  
-\begin{lstlisting}
5792  
-$e$.applyDynamic("$x$")
5793  
-\end{lstlisting}
5794  
-If the selection is followed by some arguments, e.g.\ $e.x(\args)$, then that expression
5795  
-is rewritten to
5796  
-\begin{lstlisting}
5797  
-$e$.applyDynamic("$x$", $\args$)
5798  
-\end{lstlisting}
  5760
+% TODO
5799 5761
 
5800 5762
 \chapter{Implicit Parameters and Views}\label{sec:implicits}
5801 5763
 
@@ -6726,11 +6688,7 @@ \section{Type Patterns}\label{sec:type-patterns}
6726 6688
 flag the possible loss of type-safety.
6727 6689
 
6728 6690
 A {\em type variable pattern} is a simple identifier which starts with
6729  
-a lower case letter. However, the predefined primitive type aliases
6730  
-\lstinline@unit@, \lstinline@boolean@, \lstinline@byte@,
6731  
-\lstinline@short@, \lstinline@char@, \lstinline@int@,
6732  
-\lstinline@long@, \lstinline@float@, and \lstinline@double@ are not
6733  
-classified as type variable patterns.
  6691
+a lower case letter.
6734 6692
 
6735 6693
 \section{Type Parameter Inference in Patterns}\label{sec:type-param-inf-pat}
6736 6694
 
@@ -7229,10 +7187,10 @@ \section{Programs}
7229 7187
 would work as well. 
7230 7188
 
7231 7189
 \code{HelloWorld} can also be defined without a \code{main} method 
7232  
-by inheriting from \code{Application} instead:
  7190
+by inheriting from \code{App} instead:
7233 7191
 \begin{lstlisting}
7234 7192
 package test 
7235  
-object HelloWord extends Application {
  7193
+object HelloWord extends App {
7236 7194
   println("hello world")
7237 7195
 }
7238 7196
 \end{lstlisting}
@@ -7583,16 +7541,13 @@ \section{Root Classes}
7583 7541
 subclasses: \code{AnyRef} and \code{AnyVal}.
7584 7542
 
7585 7543
 The subclass \code{AnyRef} represents all values which are represented
7586  
-as objects in the underlying host system. Every user-defined Scala
7587  
-class inherits directly or indirectly from this class. Furthermore,
7588  
-every user-defined Scala class also inherits the trait
7589  
-\code{scala.ScalaObject}.  Classes written in other languages still
7590  
-inherit from \code{scala.AnyRef}, but not from
7591  
-\code{scala.ScalaObject}.
  7544
+as objects in the underlying host system. A user-defined Scala class 
  7545
+inherits directly or indirectly from this class (except when inheriting 
  7546
+from \code{AnyVal} explicitly).  Classes written in other languages 
  7547
+inherit from \code{scala.AnyRef}.
7592 7548
 
7593  
-The class \code{AnyVal} has a fixed number of subclasses, which describe
7594  
-values which are not implemented as objects in the underlying host
7595  
-system.
  7549
+Subclasses of \code{AnyVal} describe values which are not implemented 
  7550
+as objects in the underlying host system.
7596 7551
 
7597 7552
 Classes \code{AnyRef} and \code{AnyVal} are required to provide only
7598 7553
 the members declared in class \code{Any}, but implementations may add
@@ -7650,8 +7605,6 @@ \section{Root Classes}
7650 7605
   def synchronized[T](body: => T): T // execute `body` in while locking `this`.
7651 7606
 }                           
7652 7607
 
7653  
-/** A mixin class for every user-defined Scala class */
7654  
-trait ScalaObject extends AnyRef 
7655 7608
 \end{lstlisting}
7656 7609
 
7657 7610
 The type test \lstinline@$x$.isInstanceOf[$T$]@ is equivalent to a typed
@@ -7930,7 +7883,7 @@ \subsection{The \large{\code{Tuple}} classes}
7930 7883
 
7931 7884
 \begin{lstlisting}
7932 7885
 package scala 
7933  
-case class Tuple$n$[+a_1, ..., +a_n](_1: a_1, ..., _$n$: a_$n$) {
  7886
+case class Tuple$n$[+A_1, ..., +A_n](_1: A_1, ..., _$n$: A_$n$) {
7934 7887
   def toString = "(" ++ _1 ++ "," ++ $\ldots$ ++ "," ++ _$n$ ++ ")"
7935 7888
 }
7936 7889
 \end{lstlisting}
@@ -7947,8 +7900,8 @@ \subsection{The \large{\code{Function}} Classes}
7947 7900
 
7948 7901
 \begin{lstlisting}
7949 7902
 package scala 
7950  
-trait Function$n$[-a_1, ..., -a_$n$, +b] {
7951  
-  def apply(x_1: a_1, ..., x_$n$: a_$n$): b 
  7903
+trait Function$n$[-A_1, ..., -A_$n$, +B] {
  7904
+  def apply(x_1: A_1, ..., x_$n$: A_$n$): B 
7952 7905
   def toString = "<function>" 
7953 7906
 }
7954 7907
 \end{lstlisting}
10  documentation/src/reference/ScalaReference.tex
@@ -66,7 +66,7 @@
66 66
 \renewcommand{\doctitle}{Scala By Example\\[33mm]\ }
67 67
 \renewcommand{\docauthor}{Martin Odersky\\[53mm]\ }
68 68
 \renewcommand{\doctitle}{The Scala Language \\ Specification \\
69  
-\Large  Version 2.8 \ }
  69
+\Large  Version 2.10 \ }
70 70
 
71 71
 \comment{
72 72
 \renewcommand{\docauthor}{Martin Odersky \\
@@ -89,14 +89,6 @@
89 89
 \mainmatter
90 90
 \sloppy
91 91
 
92  
-%\todo{`:' as synonym for $\EXTENDS$?}
93  
-
94  
-%\part{Rationale}
95  
-
96  
-%\input{RationalePart}
97  
-
98  
-%\part{The Scala Language Specification}
99  
-
100 92
 \input{ReferencePart}
101 93
 
102 94
 \bibliographystyle{alpha}
8  documentation/src/reference/SyntaxSummary.tex
@@ -24,16 +24,14 @@ \chapter{Scala Syntax Summary}\label{sec:syntax}
24 24
                      |  `\`' stringLit `\`'
25 25
   idrest           ::=  {letter | digit} [`_' op]
26 26
 
27  
-  integerLiteral   ::=  (decimalNumeral | hexNumeral | octalNumeral) [`L' | `l']
  27
+  integerLiteral   ::=  (decimalNumeral | hexNumeral) [`L' | `l']
28 28
   decimalNumeral   ::=  `0' | nonZeroDigit {digit}
29 29
   hexNumeral       ::=  `0' `x' hexDigit {hexDigit}
30  
-  octalNumeral     ::=  `0' octalDigit {octalDigit}
31 30
   digit            ::=  `0' | nonZeroDigit
32 31
   nonZeroDigit     ::=  `1' | $\cdots$ | `9'
33  
-  octalDigit       ::=  `0' | $\cdots$ | `7'
34 32
 
35 33
   floatingPointLiteral 
36  
-                   ::=  digit {digit} `.' {digit} [exponentPart] [floatType]
  34
+                   ::=  digit {digit} `.' digit {digit} [exponentPart] [floatType]
37 35
                      |  `.' digit {digit} [exponentPart] [floatType]
38 36
                      |  digit {digit} exponentPart [floatType]
39 37
                      |  digit {digit} [exponentPart] floatType
@@ -160,7 +158,7 @@ \chapter{Scala Syntax Summary}\label{sec:syntax}
160 158
   Enumerators       ::=  Generator {semi Enumerator}
161 159
   Enumerator        ::=  Generator
162 160
                       |  Guard
163  
-                      |  `val' Pattern1 `=' Expr
  161
+                      |  Pattern1 `=' Expr
164 162
   Generator         ::=  Pattern1 `<-' Expr [Guard]
165 163
 
166 164
   CaseClauses       ::=  CaseClause { CaseClause }
Commit_comment_tip

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.