- was 'Rationale.tex'.

1 files changed, 166 insertions, 0 deletions

diff --git a/doc/reference/RationalePart.tex b/doc/reference/RationalePart.tex
new file mode 100644
index 0000000000..56c3234259
--- /dev/null
+++ b/doc/reference/RationalePart.tex
@@ -0,0 +1,166 @@
+%% $Id$
+
+There are hundreds of programming languages in active use, and many
+more are being designed each year. It is therefore hard to justify the
+development of yet another language. Nevertheless, this is what we
+attempt to do here.  Our effort is based on two claims:
+\begin{itemize}
+\item[] {\em Claim 1:} The raise in importance of web services and
+other distributed software is a fundamental paradigm
+shift in programming. It is comparable in scale to the shift 20 years ago
+from character-oriented to graphical user interfaces.
+\item[] {\em Claim 2:} That paradigm shift will provide demand
+for new programming languages, just as graphical user interfaces
+promoted the adoption of object-oriented languages.
+\end{itemize}
+For the last 20 years, the most common programming model was
+object-oriented: System components are objects, and computation is
+done by method calls.  Methods themselves take object references as
+parameters. Remote method calls let one extend this programming model
+to distributed systems. The problem of this model is that it does not
+scale up very well to wide-scale networks where messages can be
+delayed and components may fail. Web services address the message
+delay problem by increasing granularity, using method calls with
+larger, structured arguments, such as XML trees.  They address the
+failure problem by using transparent replication and avoiding server
+state.  Conceptually, they are {\em tree transformers} that consume
+incoming message documents and produce outgoing ones.  \comment{ To
+back up the first claim, one observes that web services and other
+distributed software increasingly tend to communicate using structured
+or semi-structured data. A typical example is the use of XML to
+describe data managed by applications as well as the messages between
+applications. This tends to affect the role of a program in a
+fundamental way. Previously, programs could be seen as objects that
+reacted to method calls and in turn called methods of other
+objects. Some of these method calls might originate from users while
+others might originate from other computers via remote invocations.
+These method calls have simple unstructured parameters or object
+references as arguments.  Web services, on the other hand, communicate
+with each other by transmitting asynchronous messages that carry
+structured documents, usually in XML format. Programs then
+conceptually become {\em tree transformers} that consume incoming
+message documents and produce outgoing ones.  }
+
+Why should this have an effect on programming languages? There are at
+least two reasons: First, today's object-oriented languages are not
+very good at analyzing and transforming XML trees. Because such trees
+usually contain data but no methods, they have to be decomposed and
+constructed from the ``outside'', that is from code which is external
+to the tree definition itself. In an object-oriented language, the
+ways of doing so are limited. The most common solution \cite{w3c:dom} is
+to represent trees in a generic way, where all tree nodes are values
+of a common type.  This makes it easy to write generic traversal
+functions, but forces applications to operate on a very low conceptual
+level, which often loses important semantic distinctions present in
+the XML data.  More semantic precision is obtained if different
+internal types model different kinds of nodes.  But then tree
+decompositions require the use of run-time type tests and type casts
+to adapt the treatment to the kind of node encountered. Such type
+tests and type casts are generally not considered good object-oriented
+style. They are rarely efficient, nor easy to use.
+
+By contrast, tree transformation is the natural domain of functional
+languages. Their algebraic data types, pattern matching and
+higher-order functions make these languages ideal for the task. It's
+no wonder, then, that specialized languages for transforming XML data
+such as XSLT are functional.
+
+Another reason why functional language constructs are attractive for
+web-services is that mutable state is problematic in this setting.
+Components with mutable state are harder to replicate or to restore
+after a failure. Data with mutable state is harder to cache than
+immutable data. Functional language constructs make it relatively easy
+to construct components without mutable state.
+
+Many web services are constructed by combining different languages.
+For instance, a service might use XSLT to handle document
+transformation, XQuery for database access, and Java for the
+``business logic''.  The downside of this approach is that the
+necessary amount of cross-language glue can make applications
+cumbersome to write, verify, and maintain. A particular problem is
+that cross-language interfaces are usually not statically typed.
+Hence, the benefits of a static type system are missing where they are
+needed most -- at the join points of components written in different
+paradigms.  
+
+Conceivably, the glue problem could be addressed by a ``multi-paradigm''
+language that would express object-oriented, concurrent, as well
+as functional aspects of an application.  But one needs to be careful
+not to simply replace cross-language glue by awkward interfaces
+between different paradigms within the language itself.  Ideally, one
+would hope for a fusion which unifies concepts found in different
+paradigms instead of an agglutination, which merely includes them side
+by side.  This fusion is what we try to achieve with Scala\footnote{Scala
+stands for ``Scalable Language''.}.
+
+Scala is both an an object-oriented and functional language.  It is a
+pure object-oriented language in the sense that every value is an
+object. Types and behavior of objects are described by
+classes. Classes can be composed using mixin composition.  Scala is
+designed to interact well with mainstream object-oriented languages,
+in particular Java and C\#.
+
+Scala is also a functional language in the sense that every function
+is a value. Nesting of function definitions and higher-order functions
+are naturally supported. Scala also supports a general notion of
+pattern matching which can model the algebraic types used in many
+functional languages. Furthermore, this notion of pattern matching
+naturally extends to the processing of XML data.
+
+The design of Scala is driven by the desire to unify object-oriented
+and functional elements. Here are three examples how this is achieved:
+\begin{itemize}
+\item
+Since every function is a value and every value is an object, it
+follows that every function in Scala is an object. Indeed, there is a
+root class for functions which is specialized in the Scala standard
+library to data structures such as arrays and hash tables.
+\item
+Data structures in many functional languages are defined using
+algebraic data types. They are decomposed using pattern matching.
+Object-oriented languages, on the other hand, describe data with class
+hierarchies. Algebraic data types are usually closed, in that the
+range of alternatives of a type is fixed when the type is defined.  By
+contrast, class hierarchies can be extended by adding new leaf
+classes.  Scala adopts the object-oriented class hierarchy scheme for
+data definitions, but allows pattern matching against values coming
+from a whole class hierarchy, not just values of a single type.
+This can express both closed and extensible data types, and also
+provides a convenient way to exploit run-time type information in
+cases where static typing is too restrictive.
+\item
+Module systems of functional languages such as SML or Caml excel in
+abstraction; they allow very precise control over visibility of names
+and types, including the ability to partially abstract over types.  By
+contrast, object-oriented languages excel in composition; they offer
+several composition mechanisms lacking in module systems, including
+inheritance and unlimited recursion between objects and classes.
+Scala unifies the notions of object and module, of module signature
+and interface, as well as of functor and class. This combines the
+abstraction facilities of functional module systems with the
+composition constructs of object-oriented languages. The unification
+is made possible by means of a new type system based on path-dependent
+types \cite{odersky-et-al:fool10}.
+\end{itemize}
+Ther are several other languages that try to bridge the gap between
+the functional and object oriented
+paradigms. Smalltalk\cite{goldberg-robson:smalltalk-language},
+Python\cite{rossum:python}, or Ruby\cite{matsumtoto:ruby} come to
+mind. Unlike these languages, Scala has an advanced static type
+system, which contains several innovative constructs.  This aspect
+makes the Scala definition a bit more complicated than those of the
+languages above. On the other hand, Scala enjoys the robustness,
+safety and scalability benefits of strong static typing. Furthermore,
+Scala incorporates recent advances in type inference, so that
+excessive type annotations in user programs can usually be avoided.
+
+% rest of this report is structured as follows. Chapters
+%\ref{sec:simple-examples} to \ref{sec:concurrency} give an informal overview of
+%Scala by means of a sequence of program examples.  The remaining
+%chapters contain the language definition. The definition is formulated
+%in prose but tries to be precise.
+
+
+
+
+