publicscala/scala-dist

Subversion checkout URL

You can clone with HTTPS or Subversion.

Closed
wants to merge 1 commit into from
 +45 315

5 participants

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
 soc 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
Collaborator

Review by: @odersky

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.

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

SI-7292 Deprecate octal escape literals #2342

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 Blaisorblade added a note June 27, 2013 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

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"?

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.

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.

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?

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).

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.

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

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

Collaborator
commented on 39337a8 September 23, 2013

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.

closed this October 22, 2013

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
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 = ""  7953 7906  } 7954 7907  \end{lstlisting}
10  documentation/src/reference/ScalaReference.tex
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 }

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.