From 14b1a37788f373c99524bcaddac125233c7ac7c6 Mon Sep 17 00:00:00 2001 From: Matthias Zenger Date: Thu, 21 Aug 2003 10:54:38 +0000 Subject: Fixed some smaller typographic bugs. --- doc/reference/Makefile | 16 +++-- doc/reference/Rationale.tex | 125 +++++++++++++++++++++++++++++++++++++++ doc/reference/Scala.bib | 20 +++++++ doc/reference/ScalaByExample.tex | 9 ++- doc/reference/ScalaReference.tex | 20 ++++--- 5 files changed, 171 insertions(+), 19 deletions(-) create mode 100644 doc/reference/Rationale.tex create mode 100644 doc/reference/Scala.bib (limited to 'doc') diff --git a/doc/reference/Makefile b/doc/reference/Makefile index dc47a23dd3..f0192974a8 100644 --- a/doc/reference/Makefile +++ b/doc/reference/Makefile @@ -21,15 +21,13 @@ LATEX_FORMATS += dvi LATEX_FORMATS += ps LATEX_FORMATS += pdf -LATEX_TARGETS += $(LATEX_FORMATS:%=rationale.%) -LATEX_TARGETS += $(LATEX_FORMATS:%=reference.%) -LATEX_TARGETS += $(LATEX_FORMATS:%=examples.%) - -LATEX_SOURCES += examples.tex -LATEX_SOURCES += examples.bib -LATEX_SOURCES += rationale.tex -LATEX_SOURCES += reference.tex -LATEX_SOURCES += rationale-chapter.tex +LATEX_TARGETS += $(LATEX_FORMATS:%=ScalaReference.%) +LATEX_TARGETS += $(LATEX_FORMATS:%=ScalaByExample.%) + +LATEX_SOURCES += ScalaByExample.tex +LATEX_SOURCES += ScalaReference.tex +LATEX_SOURCES += Scala.bib +LATEX_SOURCES += Rationale.tex # latex TEXINPUTS := $(PROJECT_SUPPORTDIR)/latex:$(TEXINPUTS): diff --git a/doc/reference/Rationale.tex b/doc/reference/Rationale.tex new file mode 100644 index 0000000000..5187663f1e --- /dev/null +++ b/doc/reference/Rationale.tex @@ -0,0 +1,125 @@ +%% $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. + diff --git a/doc/reference/Scala.bib b/doc/reference/Scala.bib new file mode 100644 index 0000000000..a0bbd57115 --- /dev/null +++ b/doc/reference/Scala.bib @@ -0,0 +1,20 @@ + +@Book{ abelson-sussman:structure, + author = {Harold Abelson and Gerald Jay Sussman and Julie Sussman}, + title = {The Structure and Interpretation of Computer Programs, 2nd + edition}, + year = {1996}, + publisher = {MIT Press}, + address = {Cambridge, Massachusetts} +} + +@InProceedings{ odersky-et-al:fool10, + author = {Martin Odersky and Vincent Cremet and Christine R\"ockl + and Matthias Zenger}, + title = {A Nominal Theory of Objects with Dependent Types}, + booktitle = {Proc. FOOL 10}, + year = 2003, + month = jan, + note = {\verb@http://www.cis.upenn.edu/~bcpierce/FOOL/FOOL10.html@} + +} diff --git a/doc/reference/ScalaByExample.tex b/doc/reference/ScalaByExample.tex index fdc2c60598..51877e0ed9 100644 --- a/doc/reference/ScalaByExample.tex +++ b/doc/reference/ScalaByExample.tex @@ -1,3 +1,4 @@ +% $Id$ \documentclass[a4paper,12pt,twoside,titlepage]{book} \usepackage{scaladoc} @@ -21,7 +22,7 @@ \newcommand{\rewriteby}[1]{\mbox{\tab\tab\rm(#1)}} \renewcommand{\doctitle}{Scala By Example\\[33mm]\ } -\renewcommand{\docauthor}{Martin Odersky} +\renewcommand{\docauthor}{Martin Odersky\\[53mm]\ } \begin{document} @@ -34,7 +35,7 @@ \chapter{\label{chap:intro}Introduction} -\input{rationale-chapter.tex} +\input{Rationale} The rest of this document is structured as follows. Chapters~\ref{chap:example-one} and @@ -5416,6 +5417,10 @@ class Bidder (auction: Process, minBid: int, maxBid: int) \end{lstlisting} } %\todo{We also need some XML examples.} + +\bibliographystyle{alpha} +\bibliography{Scala} + \end{document} diff --git a/doc/reference/ScalaReference.tex b/doc/reference/ScalaReference.tex index b564adbb21..e45bf98d64 100644 --- a/doc/reference/ScalaReference.tex +++ b/doc/reference/ScalaReference.tex @@ -2,7 +2,11 @@ \documentclass[a4paper,12pt,twoside,titlepage]{book} \usepackage{scaladoc} -\usepackage{fleqn,modefs,math,scaladefs} +\usepackage{fleqn} +\usepackage{modefs} +\usepackage{math} +\usepackage{scaladefs} + \newcommand{\tps}{\mbox{\sl tps}} \newcommand{\psig}{\mbox{\sl psig}} \newcommand{\args}{\mbox{\sl args}} @@ -14,9 +18,9 @@ \ifpdf \pdfinfo { /Author (Martin Odersky, Philippe Altherr, Vincent Cremet, - Burak Emir, St\'ephane Micheloud, Nikolay Mihaylov, Michel Schinz, - Erik Stenman, Matthias Zenger) - /Title (Report on the Programming Language Scala) + Burak Emir, Stephane Micheloud, Nikolay Mihaylov, + Michel Schinz, Erik Stenman, Matthias Zenger) + /Title (The Scala Language Specification) /Keywords (Scala) /Subject () /Creator (TeX) @@ -33,8 +37,8 @@ \renewcommand{\todo}[1]{{$\clubsuit$\bf todo: #1$\spadesuit$}} \newcommand{\notyet}{\footnote{not yet implemented.}} -\renewcommand{\doctitle}{\LARGE The Scala Language \\ Specification} -\renewcommand{\docauthor}{\normalsize Martin Odersky \\ +\renewcommand{\doctitle}{The Scala Language \\ Specification \\ \ } +\renewcommand{\docauthor}{Martin Odersky \\ Philippe Altherr \\ Vincent Cremet \\ Burak Emir \\ @@ -42,7 +46,7 @@ St\'ephane Micheloud \\ Nikolay Mihaylov \\ Michel Schinz \\ Erik Stenman \\ -Matthias Zenger} +Matthias Zenger \\[25mm]\ } \begin{document} @@ -58,7 +62,7 @@ Matthias Zenger} \chapter{Rationale} -\input{rationale-chapter} +\input{Rationale} \subsection*{Status of This Document} -- cgit v1.2.3