From 8a94b49aab6f7802b80f65592c27189377607cc0 Mon Sep 17 00:00:00 2001 From: schinz Date: Fri, 22 Aug 2003 08:42:57 +0000 Subject: - removed obsolete files (which were renamed) --- doc/reference/rationale-chapter.verb.tex | 125 ------------------------------- 1 file changed, 125 deletions(-) delete mode 100644 doc/reference/rationale-chapter.verb.tex (limited to 'doc/reference/rationale-chapter.verb.tex') diff --git a/doc/reference/rationale-chapter.verb.tex b/doc/reference/rationale-chapter.verb.tex deleted file mode 100644 index 5187663f1e..0000000000 --- a/doc/reference/rationale-chapter.verb.tex +++ /dev/null @@ -1,125 +0,0 @@ -%% $Id$ - -There are hundreds of programming languages in active use, and many more are -being designed each year. It is therefore very hard to justify the development -of yet another language. Nevertheless, this is what I attempt to do here. My -argument rests 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} -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. - -To back up the second claim, one notes that today's object-oriented languages -are not very good tools for analyzing and transforming the trees which -conceptually model XML data. Because these 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 is to represent trees in a generic way, where all tree nodes are -values of a common type. This approach is used in DOM, for instance. It -facilitates the implementation of generic traversal functions, but forces -applications to operate on a very low conceptual level, which often loses -important semantic distinctions that are present in the XML data. A -semantically more precise alternative would be to use different internal types -to 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. - -Web services can be constructed using such a transformation language -together with some middleware framework such as Corba to handle -distribution and an object-oriented language for the ``application -logic''. The downside of this approach is that the necessary amount -of cross-language glue can make applications cumbersome to write, -verify, and maintain. Better productivity and trustworthiness is -achievable using a single notation and conceptual framework that would -express object-oriented, concurrent, as well as functional aspects of -an application. Hence, a case for so called ``multi-paradigm'' -languages can be made. But one needs to be careful not to simply -replace cross-language glue by awkward interfaces between different -paradigms within the language itself. The benefits of integration are -realized fully only if the common language achieves a meaningful -unification of concepts rather than being merely an agglutination of -different programming paradigms. This 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} - -%The 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