diff options
author | Martin Odersky <odersky@gmail.com> | 2004-01-19 14:58:26 +0000 |
---|---|---|
committer | Martin Odersky <odersky@gmail.com> | 2004-01-19 14:58:26 +0000 |
commit | 1be73373facebd0a8c4d6b7ce6f9d5bab3e282a1 (patch) | |
tree | 353b4e075fcbfe5031e1d1b218bbff5326fd585b | |
parent | c72f7b292fb5976c656ee666044e0a9b6ede1459 (diff) | |
download | scala-1be73373facebd0a8c4d6b7ce6f9d5bab3e282a1.tar.gz scala-1be73373facebd0a8c4d6b7ce6f9d5bab3e282a1.tar.bz2 scala-1be73373facebd0a8c4d6b7ce6f9d5bab3e282a1.zip |
*** empty log message ***
-rw-r--r-- | doc/reference/RationalPart.tex | 166 | ||||
-rw-r--r-- | doc/reference/ScalaRationale.tex | 166 | ||||
-rw-r--r-- | sources/scala/Predef.scala | 2 |
3 files changed, 333 insertions, 1 deletions
diff --git a/doc/reference/RationalPart.tex b/doc/reference/RationalPart.tex new file mode 100644 index 0000000000..56c3234259 --- /dev/null +++ b/doc/reference/RationalPart.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. + + + + + diff --git a/doc/reference/ScalaRationale.tex b/doc/reference/ScalaRationale.tex new file mode 100644 index 0000000000..56c3234259 --- /dev/null +++ b/doc/reference/ScalaRationale.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. + + + + + diff --git a/sources/scala/Predef.scala b/sources/scala/Predef.scala index 81b2ce59f3..4c7c22a16d 100644 --- a/sources/scala/Predef.scala +++ b/sources/scala/Predef.scala @@ -70,4 +70,4 @@ object Predef { type Function[-a,+b] = Function1[a,b]; } -* + |