From f31ddb42716fc04c9fc61ae349149aa8999c8f9b Mon Sep 17 00:00:00 2001 From: michelou Date: Mon, 19 Jan 2004 16:39:47 +0000 Subject: *** empty log message *** --- doc/reference/ScalaRationale.tex | 166 --------------------------------------- 1 file changed, 166 deletions(-) delete mode 100644 doc/reference/ScalaRationale.tex diff --git a/doc/reference/ScalaRationale.tex b/doc/reference/ScalaRationale.tex deleted file mode 100644 index 56c3234259..0000000000 --- a/doc/reference/ScalaRationale.tex +++ /dev/null @@ -1,166 +0,0 @@ -%% $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. - - - - - -- cgit v1.2.3