[ANN] Die Programmiersprache Scala
Matthias Zenger
Scala programming language. Scala smoothly integrates object-oriented
and functional programming. It is designed to express common
programming patterns in a concise, elegant, and type-safe way. Scala
introduces several innovative language constructs. For instance:
- Abstract types and mixin composition unify ideas from object and
module systems.
- Pattern matching over class hierarchies unifies functional and
object-oriented data access. It greatly simplifies the processing of
XML trees.
- A flexible syntax and type system enables the construction of
advanced libraries and new domain specific languages.
At the same time, Scala is compatible with Java. Java libraries and
frameworks can be used without glue code or additional declarations.
The current implementation of Scala runs on Java VM. It requires JDK
1.4 and can run on Windows, MacOS, Linux, Solaris, and most other
operating systems. A .net version of Scala is currently under
development.
For further information and downloads, please visit:
=====================================================================
Martin Odersky and the Scala team,
Swiss Federal Institute of Technology, Lausanne (EPFL).
Stefan Matthias Aust
> We'd like to announce availability of the first implementation of the
> Scala programming language.
Spannend. IMHO sieht die Sprache ganz schick aus. Im Gegensatz zu
vielen anderen Sprach-Projekten gibt es auch ausreichend (d.h. mehrere
hundert Seiten) Dokumentation. Der Schwerpunkt liegt offenbar (ich
möchte fast sagen leider) in der Lehre, die typischen Beispiele
funktionaler Programmierung werden vorgestellt und erläutert. Dagegen
ist nichts zu sagen, doch welche Anwendungsfälle für die Sprache gibt es
noch? Was wäre etwa mit der typischen Rich-Client-Anwendung mit
Datenbank-Backend? Oder einer Webanwendung... Features wie konsequente
Objektorientierung (keine primitiven Typen), Closures, generische Typen,
usw würde ich eigentlich liebend gerne eher heute als morgen einsetzen
und bei Scala sollte es aufgrund des statischen Typsystems auch möglich
sein, eine IDE-UNterstützung inklusive refactoring und code completion
zur Verfügung zu stellen.
bye
--
Stefan Matthias Aust // "A new beginning always starts at the end" -WT
Aljoscha Rittner
Habe gerade auch etwas Zeit gefunden, die Seiten durchzustöbern und
ich fragte maich, wann du was dazu schreiben würdest ;)
> Matthias Zenger wrote:
>
>> We'd like to announce availability of the first implementation of the
>> Scala programming language.
>
> Spannend. IMHO sieht die Sprache ganz schick aus.
Ja, keine unübersichtlichen Klammerebenen. Außerdem gut durchdacht.
Alles konnte ich noch nicht erfassen, aber es wirkt so, als hatte da
jemand arge Schmerzen mit den aktuellen Sprachen gehabt. Schön so
viele Rosinen wiederzufinden.
> Im Gegensatz zu
> vielen anderen Sprach-Projekten gibt es auch ausreichend (d.h. mehrere
> hundert Seiten) Dokumentation. Der Schwerpunkt liegt offenbar (ich
> möchte fast sagen leider) in der Lehre, die typischen Beispiele
> funktionaler Programmierung werden vorgestellt und erläutert.
So die Seiten der Homepage. Wenn man aber tatsächlich den kompletten
Zugriff auf die Sun-API hat....
> Dagegen
> ist nichts zu sagen, doch welche Anwendungsfälle für die Sprache gibt es
> noch? Was wäre etwa mit der typischen Rich-Client-Anwendung mit
> Datenbank-Backend? Oder einer Webanwendung...
... sehe ich da kein Problem (außer der Konformität). Oder habe ich
was übersehen?
> Features wie konsequente
> Objektorientierung (keine primitiven Typen), Closures, generische Typen,
> usw würde ich eigentlich liebend gerne eher heute als morgen einsetzen
> und bei Scala sollte es aufgrund des statischen Typsystems auch möglich
> sein, eine IDE-UNterstützung inklusive refactoring und code completion
> zur Verfügung zu stellen.
Wenn Scala was taugt, werden Module oder Plugins nicht lange auf sich
warten lassen.
Gruß,
Josch, nun *noch* was zum spielen hat...
--
Computer Language, a system of organizing and defining syntax errors.
Stefan Matthias Aust
> Stefan Matthias Aust schrieb:
>
> Habe gerade auch etwas Zeit gefunden, die Seiten durchzustöbern und
> ich fragte maich, wann du was dazu schreiben würdest ;)
:)
Habe gerade angefangen die PDFs zu studieren. Leider will es mir nicht
gelingen, ScalaOverview.pdf zu drucken, mein Acroread weigert sich
einfach :( Mein Ghostscript schluckt leider auch nicht die PS-Version.
Und die HTML-Version ist verlinkt und nicht einfach ausdruckbar...
> Ja, keine unübersichtlichen Klammerebenen. Außerdem gut durchdacht.
> Alles konnte ich noch nicht erfassen, aber es wirkt so, als hatte da
> jemand arge Schmerzen mit den aktuellen Sprachen gehabt.
Jemand hatte offenbar den starken Wunsch, funktionale Programmierung zu
machen und trotzdem auf Java-Klassen (und später auch .NET-Klassen)
zugreifen zu können...
>>Im Gegensatz zu
>>vielen anderen Sprach-Projekten gibt es auch ausreichend (d.h. mehrere
>>hundert Seiten) Dokumentation. Der Schwerpunkt liegt offenbar (ich
>>möchte fast sagen leider) in der Lehre, die typischen Beispiele
>>funktionaler Programmierung werden vorgestellt und erläutert.
>
> So die Seiten der Homepage. Wenn man aber tatsächlich den kompletten
> Zugriff auf die Sun-API hat....
Ja, allerdings könnte es sein (ich rate jetzt nur ins Blaue hinein) dass
einige Konzepte das ganze noch vereinfachen könnten. So las ich, dass
es weder "break" noch "continue" gibt. Kontrolliertes Aussteigen aus
Schleifen kann aber manchmal sehr praktisch sein und break-mit-Label ist
essentiell, wenn man eigentlich ein goto braucht (was ja mal vorkommen
kann). Das sind nur Kleinigkeiten, aber Unterstützung für properties
und listener wäre interessant (Groovy bietet so was - zumindest ist es
geplant) um auch mit Java-Bibliotheken einfacher zu arbeiten. Ein
besseres Komponentenmodell als mit normalen Methoden simulierte Beans
wäre gut. Das "using" von C#, welches es erlaubt, innerhalb eines
Blocks automatisch angeforderte Ressourcen wieder freizugeben ist ein
weiteres praktisches Konstrukt, das Java nicht bietet, was aber einer
neuen Sprache gut stünde. Schließlich wären glaube ich Meta-Attribute
in der Sprache auch eine sehr wichtige Eigenschaft.
Matthias Zenger
> ...
> wäre gut. Das "using" von C#, welches es erlaubt, innerhalb eines
> Blocks automatisch angeforderte Ressourcen wieder freizugeben ist ein
> weiteres praktisches Konstrukt, das Java nicht bietet, was aber einer
Ich bin mir nicht sicher was du genau meinst, aber in Scala ist
es moeglich auf jeder Ebene Klassen, Methoden, etc. zu importieren.
Man kann z.B. folgendes schreiben:
object Main {
def main(args: Array[String]) = {
import System.out._; // imports all members of System.out into
println("Hello World"); // current scope
}
}
In der Methode main werden alle Members von System.out importiert
(also auch println) sodass man diese in dem Block auch unqualifiziert
verwenden kann. Ausserhalb von der Methode muss man weiterhin
System.out.println(...) schreiben. Meinst du das?
== Matthias
Michael Trocken
> Das "using" von C#, welches es erlaubt, innerhalb eines Blocks
> automatisch angeforderte Ressourcen wieder freizugeben ist ein
> weiteres praktisches Konstrukt, das Java nicht bietet, was aber
> einer neuen Sprache gut stünde.
Der using-Block von C# ist viel zu unhandlich. Für wesentlich
gelungener halte ich das Handle-Konzept der (in Arbeit befindlichen)
C++/CLI-Bindung.
Die Grundidee besteht darin, dass man bei sog. "Handles" das
Speichermanagement zwar der Garbage-Collection überlässt, andere
Ressourcen aber im Destruktor freigibt. (Dabei ist der Destruktor
nicht identisch mit dem "Finalizer".) Ressourcen stehen dann nach
Verlassen des Scopes einer Variablen, da dann der Destruktor
aufgerufen wird, wieder zur Verfügung.
Gruß,
Michael
Stefan Matthias Aust
> Stefan Matthias Aust wrote:
>
>> ...
>
> > wäre gut. Das "using" von C#, welches es erlaubt, innerhalb eines
>
>> Blocks automatisch angeforderte Ressourcen wieder freizugeben ist ein
>> weiteres praktisches Konstrukt, das Java nicht bietet, was aber einer
>
>
> Ich bin mir nicht sicher was du genau meinst, aber in Scala ist
> es moeglich auf jeder Ebene Klassen, Methoden, etc. zu importieren.
Oh, das ist interessant. Ich meinte allerdings etwas anderes. In C#
kann man mittels
using (Foo foo = new Baz()) {
foo...
}
dafür sorgen, dass sowas wie
IDisposable foo = new Baz();
try {
foo...
} finally {
foo.Dispose();
foo = null; // der GC könnte das Objekt *jetzt* wegräumen
}
aufgerufen wird. Spart einfach ein paar Codezeilen. Scheint dort auch
die Brücke zu nicht vom GC verwalteten Objekten zu schlagen, wenn man es
in unsafe-Code verwendet.
Inzwischen denke ich, dass man das wohl auch in Scala selbst bauen kann,
indem man ein def-closure-Konstrukt einsetzt.
Mir kam das "using" einfach als erstes in den Sinn für Erweiterungen der
Sprache gegenüber Java, die aus Bequemlichkeit im täglichen Einsatz
entstanden zu sein scheinen.
Was ich mir übrigens noch in meiner idealen auf der JVM-basierenden
Besser-als-Java-Sprache wünschen würde (vielleicht hat Scala das und ich
habe es nur bislang übersehen):
- Literale Form für Arrays und HashMaps
z.B. [1, 2, 3] und [1=>3, 2=>4]
- Literale Form für Listen (hier denke ich an backquote a la Lisp)
- Strings mit Codeeinschlüssen (wie nennt man das sonst?)
"id = ${3+4}" liefert "id = 7"
- Properties (statt getFoo und setFoo)
- +=, -= usw. (allerdings nicht ++ und --)
- [] und []= Funktionen für einfachen Index-Zugriff
- Intervalle mittels ..
(damit man etwa "abc"[1..2] = "X" schreiben kann)
- break, next und redo für Blöcke
(next entspricht continue, ich ziehe die Namen von Ruby hier vor)
Und noch eine Frage zu Scala: Habe ich das richtig verstanden, dass es
pro Klasse immer nur einen Konstruktor gibt und man diesen nicht
überladen kann?
bye
--
Stefan Matthias Aust // Truth until Paradox!
Stefan Matthias Aust
> Der using-Block von C# ist viel zu unhandlich. Für wesentlich
> gelungener halte ich das Handle-Konzept der (in Arbeit befindlichen)
> C++/CLI-Bindung.
Und wie sähe das syntaktisch aus?
bye
--
Stefan Matthias Aust // Truth until Paradox!
Tobias Vogele
Stefan Matthias Aust spoke:
> - Strings mit Codeeinschlüssen (wie nennt man das sonst?)
> "id = ${3+4}" liefert "id = 7"
Hm, bei so was habe ich immer das Gefühl, daß man sich damit leicht
Sicherheitslücken einfängt.
Wenn man z.B. von außen einen String bekommt, und irgendein böser Mensch
schickt da "bla ${new File("/").delete()} bla" und das wird automatisch
ausgewertet, kann das echt ärgerlich sein.
Ich finde, wenn, dann sollte das entweder auf Variablen-Ersetzungen
beschränkt sein, also
cost = 3+4
print("Kosten: ${cost} Euro")
Oder man mußt die Auswertung explizit aufrufen muß, etwa:
"id = ${3+4}".eval()
Wobei das zweite vielleicht nicht sehr viel besser als das Original ist,
wenn man den String an Bibliotheken übergibt, die dann in ihrem Inneren
irgendwo dieses eval() aufrufen und man das übersehen hat.
Was mir noch einfällt: Ich finde Operatoren, die aus zwei Sonderzeichen
bestehen (also z.B: "=>" oder "::") irgendwie häßlich. Aber anscheinend bin
ich damit allein, wenn man sich die meisten Sprachen so anschaut... :-(
Grüße,
tobi
--
URL: http://www.wartmal.de Email: ne...@wartmal.de
Burak Emir
Stefan Matthias Aust wrote:
> hundert Seiten) Dokumentation. Der Schwerpunkt liegt offenbar (ich
> möchte fast sagen leider) in der Lehre, die typischen Beispiele
> funktionaler Programmierung werden vorgestellt und erläutert. Dagegen
> ist nichts zu sagen, doch welche Anwendungsfälle für die Sprache gibt es
> noch? Was wäre etwa mit der typischen Rich-Client-Anwendung mit
> Datenbank-Backend? Oder einer Webanwendung... Features wie konsequente
Es wird recht bald einen web application server geben, das auf dem Java
Servlet API (aber ohne JSPs) aufbaut. Scala's abkuerzende Schreibweise
fuer XML erlaubt uns, ein etwas sichereres API aufzustellen, da man zum
beispiel mit
val theLink = 'a(Text("mein Link")) % (href <= "scala.epfl.ch");
theLink.toXML
...einen String mit well-formed XML erhaelt.
Geplant ist auch, XML Daten auf eine typsichere Art und Weise zu
verarbeiten (zum beispiel html enhaelt genau head und body...). Hierzu
fehlen der Sprache noch regulaere Typen, um so etwas wie Schema oder
Relax NG Typen ausdruecken zu koennen. Bis dahin gibt es in der
Distribution schon jetzt ein Tool namens dtd2scala, was fuer eine DTD
Scala Klassen und eine Parserkomponente liefert, also "Data Binding Lite".
Auch die Idee, SQL Query konstrukte in der Bibliothek mitzuliefern,
wurde schon angedacht, damit man nichts mehr in Strings schreiben und
sich mit Laufzeitfehlern herumaergern muss.
All diese Dinge sollten natuerlich auch irgendwo und mehr dokumentiert
sein... mea culpa.
cheers,
Burak
Stefan Matthias Aust
>> - Strings mit Codeeinschlüssen (wie nennt man das sonst?)
>> "id = ${3+4}" liefert "id = 7"
>
> Hm, bei so was habe ich immer das Gefühl, daß man sich damit leicht
> Sicherheitslücken einfängt.
Nein, denn so wie ich mir das vorstelle, ist das einfach eine andere
kompakte Syntax für einen StringBuilder (aka StringBuffer), ein
spezielles Objekt, welches man irgendwie über readLine() einlesen kann
und was dann zur Laufzeit evaluiert wird.
Nennen wir es einen String-Konstruktor.
> Was mir noch einfällt: Ich finde Operatoren, die aus zwei Sonderzeichen
> bestehen (also z.B: "=>" oder "::") irgendwie häßlich.
Zu "::" kann ich nichts sagen, aber => gibt es auch als einzelnes
Zeichen, vielleicht nicht auf jeder Tastatur, aber im Unicode. Ich
denke, man sollte langsam mal anfangen, auch Zeichen jenseits von ASCII
einzusetzen, sei es als Syntax oder Namen.
Alexander Reifinger
> Zu "::" kann ich nichts sagen, aber => gibt es auch als einzelnes
> Zeichen, vielleicht nicht auf jeder Tastatur, aber im Unicode. Ich
> denke, man sollte langsam mal anfangen, auch Zeichen jenseits von ASCII
> einzusetzen, sei es als Syntax oder Namen.
Ich habe keine gesteigerten Lustgefühle bei dem Gedanken in Zukunft
ALT-Sequenzen auswendig zu lernen oder für 3 Programmiersprachen 3
verschiedensprachige Tastaturen benutzen zu müssen.
--
Servus,
Alexander Reifinger
Matthias Zenger
> Oh, das ist interessant. Ich meinte allerdings etwas anderes. In C#
> kann man mittels
>
> using (Foo foo = new Baz()) {
> foo...
> }
>
> dafür sorgen, dass sowas wie
>
> IDisposable foo = new Baz();
> try {
> foo...
> } finally {
> foo.Dispose();
> foo = null; // der GC könnte das Objekt *jetzt* wegräumen
> }
>
> aufgerufen wird. Spart einfach ein paar Codezeilen. Scheint dort auch
> die Brücke zu nicht vom GC verwalteten Objekten zu schlagen, wenn man es
> in unsafe-Code verwendet.
>
> Inzwischen denke ich, dass man das wohl auch in Scala selbst bauen kann,
> indem man ein def-closure-Konstrukt einsetzt.
Genau, in Scala kann man dieses using-Konstrukt selbst definieren
(ist im Prinzip nur eine "apply" Funktion). Hier kommt der Code:
def using[T](x: T)(body: T => Unit) = try { body(x); }
finally { x.Dispose(); }
Diese polymorphe Funktion nimmt einen Wert x und eine Funktion body,
wendet die Funktion auf x an und ruft danach die Dipose Methode
von x auf. Damit kann man nun folgendes schreiben:
using(new Baz()) { foo => <code> }
> - Literale Form für Arrays und HashMaps
> z.B. [1, 2, 3] und [1=>3, 2=>4]
Array Literale schreibt man so: Array(1, 2, 3)
Fuer Listen ist das aehnlich: List(1, 2, 3)
Man kann sich auch Funktionen fuer andere Datentypen schreiben:
def Set[T](elems: T*) = (new ListSet).incl(elems);
Dann kann man z.B. schreiben: Set(1, 4, 8, 12). Der * hinter
T gibt an, dass es sich hier um eine Sequenz von Ts handelt.
Für Maps muss man etwas mehr Aufwand treiben. Zur Zeit kann
man z.B. folgende Syntax verwenden:
new ListMap + 1 => 3
+ 2 => 4
+ ...
Das ist kein Bestandteil der Sprache sondern alles benutzer-
definiert. Scala hat einen ziemlich maechtigen Mechanismus fuer
Operatorenueberladung.
> - Properties (statt getFoo und setFoo)
Wenn man ein val-Member definiert wird automatisch eine getter-
Methode erzeugt. Fuer var-Members erhaelt man beides: getter
und setter-Methoden.
> - [] und []= Funktionen für einfachen Index-Zugriff
Das habe ich nicht verstanden. Was meinst du?
> - Intervalle mittels ..
> (damit man etwa "abc"[1..2] = "X" schreiben kann)
Kann man sich hier nicht eine ganz einfache Funktion von Hand
schreiben?
> - break, next und redo für Blöcke
> (next entspricht continue, ich ziehe die Namen von Ruby hier vor)
In Zukunft soll es einmal ein nicht-lokales "return" (non-local
return) geben. Damit kann man dann solche Dinge definieren.
> Und noch eine Frage zu Scala: Habe ich das richtig verstanden, dass es
> pro Klasse immer nur einen Konstruktor gibt und man diesen nicht
> überladen kann?
Die Sprache erlaubt es meherer zu definieren. Hier kommt ein
Beispiel:
class Foo(x: String) {
def this(x: Int) = this(x.toString());
override def toString() = x;
}
Diese Klasse hat zwei Konstruktoren: einen fuer Strings (der sogenannte
"primary constructor") und einen fuer Integers. Es gibt eine Ein-
schraenkung: wenn man die Klasse erweitert, so muss man den primary
constructor in der Unterklasse aufrufen.
Ich persoenlich verwende niemals zwei Konstruktoren. Oftmals ueberlaedt
man Konstruktoren um optional default-Werte zu ueberschreiben. Das kann
man in Scala schoener mit einem Klassen-Refinement loesen. Statt
new HashMap(20) zu verwenden muss man dann halt:
new HashMap { def initialCapacity = 20; } schreiben. Ist laenger aber
dafuer selbsterklaerend.
== Matthias
Stefan Matthias Aust
>> - Literale Form für Arrays und HashMaps
>> z.B. [1, 2, 3] und [1=>3, 2=>4]
>
> Array Literale schreibt man so: Array(1, 2, 3)
> Fuer Listen ist das aehnlich: List(1, 2, 3)
(Wurde das in dem Overview oder dem "By Example" erwähnt und ich habe
beim Überfliegen übersehen?)
Ist das jetzt eine globale Funktion oder ein Konstruktor ohne "new" -
den man ja wohl zumindest bei "case"-Klassen weglassen darf. Ist "new"
immer optional? Ist das eine Funktion mit variabler Argumentzahl? Ist
das allgemein möglich? Falls nein, es wäre IMHO nützlich.
> Man kann sich auch Funktionen fuer andere Datentypen schreiben:
>
> def Set[T](elems: T*) = (new ListSet).incl(elems);
Ist das die Syntax für eine Funktion mit Variabler Argumentzahl? Ich
muss dringend die Sprachbeschreibung lesen...
> Dann kann man z.B. schreiben: Set(1, 4, 8, 12). Der * hinter
> T gibt an, dass es sich hier um eine Sequenz von Ts handelt.
> Für Maps muss man etwas mehr Aufwand treiben. Zur Zeit kann
> man z.B. folgende Syntax verwenden:
>
> new ListMap + 1 => 3
> + 2 => 4
> + ...
Das finde ich leider sehr unübersichtlich. Dann schon lieber
ListMap new
add: 1 -> 3;
add: 2 -> 4;
yourself
Das kann jedenfalls ich besser lesen :) So löblich ich auch den Versuch
finde, möglichst wenig Syntax zu haben und möglichst viel mit den
Basiskonzepten der Sprache zu realisieren, ein bisschen mehr Syntax wäre
hier gut für die Lesbarkeit. Warum könnte man denn nicht
ListMap(1 => 3, 2 => 4, ...)
schreiben?
>> - Properties (statt getFoo und setFoo)
>
> Wenn man ein val-Member definiert wird automatisch eine getter-
> Methode erzeugt. Fuer var-Members erhaelt man beides: getter
> und setter-Methoden.
Kann ich diese auch überschreiben, sodass ich etwa im Setter noch eine
Konsistenzprüfung machen kann? Wenn auch das Typsystem von Scala wohl
ClastCastExceptions (weitestgehend?) eindämmen kann,
NullPointerExceptions können (im Gegensatz zu Nice) doch wohl immer noch
auftreten, oder?
>> - [] und []= Funktionen für einfachen Index-Zugriff
>
> Das habe ich nicht verstanden. Was meinst du?
Ein Ausdruck wie "anArray[4]" sei syntaktischer Zucker für etwas in der
Art "anArray.index(4)" und ein Ausdruck wie "anArray[4] = 0" ist Zucker
für "anArray.indexSetter(4, 0)". Basisklassen wie Strings, Arrays,
Maps, usw sollten eine derartige Zugriffsoperation auf ihre Elemente
haben, eigenen Klassen sollte man selbstverständlich ebenfalls damit
ausstatten können. Die Anzahl und der Typ der Parameter und der
Rückgabetyp sind beliebig, insbesondere sollte die Funktion überladbar sein.
>> - Intervalle mittels ..
>> (damit man etwa "abc"[1..2] = "X" schreiben kann)
>
> Kann man sich hier nicht eine ganz einfache Funktion von Hand
> schreiben?
Ich finde halt "1..5" schicker als "Interval(1, 5)". Und
"anArray[1..2]" einfacher lesbar als "anArray.get(Interval(1, 5))".
>> - break, next und redo für Blöcke
>> (next entspricht continue, ich ziehe die Namen von Ruby hier vor)
>
> In Zukunft soll es einmal ein nicht-lokales "return" (non-local
> return) geben. Damit kann man dann solche Dinge definieren.
Das wäre gut. Ich finde non-local-returns wie z.B. Smalltalk sie bei
seinen Blöcken bietet sehr hilfreich.
> Die Sprache erlaubt es meherer zu definieren. Hier kommt ein
> Beispiel:
>
> class Foo(x: String) {
> def this(x: Int) = this(x.toString());
Hm... warum "this" statt "Foo"?
> Ich persoenlich verwende niemals zwei Konstruktoren. Oftmals ueberlaedt
> man Konstruktoren um optional default-Werte zu ueberschreiben. Das kann
> man in Scala schoener mit einem Klassen-Refinement loesen. Statt
> new HashMap(20) zu verwenden muss man dann halt:
> new HashMap { def initialCapacity = 20; } schreiben. Ist laenger aber
> dafuer selbsterklaerend.
Auch nicht schlecht. Erinnert mich an Lisp (oder an Cecil). Warum
benötigt man das "def" in der Syntax? Ist das ";" zwingend?
bye
--
Stefan Matthias Aust
> Es wird recht bald einen web application server geben, das auf dem Java
> Servlet API (aber ohne JSPs) aufbaut.
Schön. Es ist gut zu wissen, das Scala nicht eine reine Lehrsprache
sein und bleiben wird. Würde es nicht ausreichen, einfach ScalaServlets
in einen Servlet-Container wie Tomcat zu hängen? Warum ein ganz eigener
Server? Als "Beweis" für die Mächtigkeit der Sprache?
> Scala's abkuerzende Schreibweise
> fuer XML erlaubt uns, ein etwas sichereres API aufzustellen, da man zum
> beispiel mit
>
> val theLink = 'a(Text("mein Link")) % (href <= "scala.epfl.ch");
Ich denke, daran muss man sich erst einmal gewöhnen. Das "'" finde ich
okay, das Text ist lästig, aber das "%" für die Attribute finde ich sehr
gewöhnungsbedürftig. Curl hat es sehr geschickt verstanden, seine
Syntax an die Bedürfnisse anzupassen. LAML von Nørmark finde ich
ebenfalls recht lesbar (als Lisp-Kenner). Könnte man nicht besser
Datentypen mischen, etwa
'a(href:"...", "Hallo")
So ähnlich macht, bzw. will Groovy es machen. Dort kann man allerdings
momentan nicht Attribut-Assoziationen (a:b) und normale Attribute mischen.
Allerdings finde ich persönlich XML nicht so spannend (auch wenn mir
bewusst ist, dass dies ein wichtiger Grund für die Existenz von Scala
ist). Support für Baumstrukturen ist allerdings in jedem Fall gut.
> All diese Dinge sollten natuerlich auch irgendwo und mehr dokumentiert
> sein... mea culpa.
:)
Matthias Zenger
>> Fuer Listen ist das aehnlich: List(1, 2, 3)
>
> (Wurde das in dem Overview oder dem "By Example" erwähnt und ich habe
> beim Überfliegen übersehen?)
Nein, das wurde (leider) nicht erwaehnt. Aber Burak hat das
anscheinend schon in die FAQ gesetzt. Die wird dann veroeffentlicht,
wenn genug Leute genuegend interessante Fragen gestellt haben... :-)
> Ist das jetzt eine globale Funktion oder ein Konstruktor ohne "new" -
> den man ja wohl zumindest bei "case"-Klassen weglassen darf. Ist "new"
> immer optional? Ist das eine Funktion mit variabler Argumentzahl? Ist
"new" ist nur bei case-Klassen optional. Beides sind Funktionen
mit einer variablen Anzahl von Argumenten.
>> def Set[T](elems: T*) = (new ListSet).incl(elems);
>
> Ist das die Syntax für eine Funktion mit Variabler Argumentzahl? Ich
Ja!
>> new ListMap + 1 => 3
>> + 2 => 4
>> + ...
Sorry, das sollte heissen: new ListMap + 1 -> 3 + 2 -> 4 ...
> Das finde ich leider sehr unübersichtlich. Dann schon lieber
>
> ListMap new
> add: 1 -> 3;
> add: 2 -> 4;
> yourself
>
> Das kann jedenfalls ich besser lesen :) So löblich ich auch den Versuch
Vielleicht gefaellt dir die Syntax fuer "mutable" Maps besser:
val map = new HashMap;
map(1) = 3;
map(2) = 4;
...
Wie gesagt, das ist alles benutzerdefiniert und nicht Teil der Sprache
selbst. Obige Syntax ist eine Abkuerzung fuer:
val map = new HashMap;
map.update(1, 3);
map.update(1, 4);
...
> hier gut für die Lesbarkeit. Warum könnte man denn nicht
>
> ListMap(1 => 3, 2 => 4, ...)
>
> schreiben?
Weil dann "=>" ein Operator (bzw. eine Methode) von der Klasse Any
sein muesste. Als explizite Syntax von Scala ist es auch nicht
akzeptabel da man in Scala nichts von Maps weiss. Die sind ja
benutzerdefiniert.
>> Wenn man ein val-Member definiert wird automatisch eine getter-
>> Methode erzeugt. Fuer var-Members erhaelt man beides: getter
>> und setter-Methoden.
>
> Kann ich diese auch überschreiben, sodass ich etwa im Setter noch eine
> Konsistenzprüfung machen kann? Wenn auch das Typsystem von Scala wohl
Ja, die kann man ueberschreiben. Hier kommt ein Beispiel:
class A {
var x = 1;
}
class B extends A {
override def x_$eq(y: int) = {
Console.println("x = " + y);
super.x_$eq(y);
}
}
object C extends B with Application {
x = 2;
}
Wenn man das Objekt C ausfuehrt dann sollte man folgende Ausgabe
erhalten:
x = 1
x = 2
Leider fehlt beim aktuellen Compiler die erste Zeile. Das muss
aber ein Bug sein. Die initiale Zuweisung an x sollte auch
ueber die selbstdefinierte setter-Methode laufen.
> ClastCastExceptions (weitestgehend?) eindämmen kann,
> NullPointerExceptions können (im Gegensatz zu Nice) doch wohl immer noch
> auftreten, oder?
Genau, die Referenztypen ohne Null von Nice gibt es in Scala nicht.
Braucht man die wirklich?
>>> - [] und []= Funktionen für einfachen Index-Zugriff
>>
>>
>> Das habe ich nicht verstanden. Was meinst du?
>
> Ein Ausdruck wie "anArray[4]" sei syntaktischer Zucker für etwas in der
> Art "anArray.index(4)" und ein Ausdruck wie "anArray[4] = 0" ist Zucker
> für "anArray.indexSetter(4, 0)". Basisklassen wie Strings, Arrays,
Ach so, die Frage sollte schon beantwortet sein. "obj(x) = y" ist
syntaktischer Zucker fuer "obj.update(x, y)" in Scala.
>> class Foo(x: String) {
>> def this(x: Int) = this(x.toString());
>
>
> Hm... warum "this" statt "Foo"?
Das ist halt wie in Java...
> Auch nicht schlecht. Erinnert mich an Lisp (oder an Cecil). Warum
> benötigt man das "def" in der Syntax? Ist das ";" zwingend?
Das ";" ist nicht zwingend. Das "def" muss man natuerlich
schreiben da "initialCapacity" ja schliesslich nichts anderes
als eine Methode (ohne Parameter) ist.
== Matthias
Matthias Zenger
>> Hm, bei so was habe ich immer das Gefühl, daß man sich damit leicht
>> Sicherheitslücken einfängt.
>
> Nein, denn so wie ich mir das vorstelle, ist das einfach eine andere
> kompakte Syntax für einen StringBuilder (aka StringBuffer), ein
> spezielles Objekt, welches man irgendwie über readLine() einlesen kann
> und was dann zur Laufzeit evaluiert wird.
Ich glaube man kann soetwas in Scala per Hand schreiben:
def String(parts: Any*) = {
val buf = new StringBuffer();
parts.elements foreach { p => buf.append(p) }
buf.toString()
}
Folgendes ist dann z.B. moeglich:
val x = 1, y = 2;
String("x + y = ", x + y, "!!!")
Hier wird der String "x + y = 3!!!" gebaut.
>> Was mir noch einfällt: Ich finde Operatoren, die aus zwei Sonderzeichen
>> bestehen (also z.B: "=>" oder "::") irgendwie häßlich.
:: ist ueblicherweise der Cons-Operator (bei funktionalen
Programmiersprachen).
== Matthias
Andreas Jaeger
Begeisterung breitmacht, wollte ich mal nachfragen,
was 1.) genau eine contra/covariant fashion ist ...
http://scala.epfl.ch/intro/subclassing.html
class Point(xc: Int, yc: Int) {
val x: Int = xc;
val y: Int = yc;
def move(dx: Int, dy: Int): Point =
new Point(x + dx, y + dy);
}
class ColorPoint(u: Int, v: Int, c: String) extends Point(u, v) {
val color: String = c;
def compareWith(pt: ColorPoint): Boolean =
(pt.x == x) && (pt.y == y) && (pt.color == color);
override def move(dx: Int, dy: Int): ColorPoint =
new ColorPoint(x + dy, y + dy, color);
}
... und warum 2.) bei Java die Return-Typ-Einengung
nicht implementiert ist. Was spricht dagegen, oder
kommt das auch in 1.5? Ich frage deswegen, weil es
mir manchmal ziemlich auf den Nerv fällt, extra
Casts in den Code einzubauen, die ziemlich unnötig
erscheinen.
--
---------------------------------------------
Andreas Jaeger
http://afi.uni-muenster.de
afi - Institut für Agrar- und Forstinformatik
an der Universität Münster
---------------------------------------------
Matthias Zenger
> was 1.) genau eine contra/covariant fashion ist ...
Man kann in Scala beim Ueberschreiben einer Methode einen
"besseren" (kleineren) Resultatstyp angeben und "schlechtere"
(groessere) Parametertypen. Folgender Code ist deswegen
legal (Any ist die Oberklasse aller Klassen):
class A(y: Int) {
def foo(x: Int): A = new A(x);
}
class B(y: String) extends A(0) {
override def foo(x: Any): B = new B(x.toString());
}
> ... und warum 2.) bei Java die Return-Typ-Einengung
> nicht implementiert ist. Was spricht dagegen, oder
> kommt das auch in 1.5? Ich frage deswegen, weil es
Ab Java 1.5 wird das auch zulaessig sein.
== Matthias
Burak Emir
> Burak Emir wrote:
>
>> Es wird recht bald einen web application server geben, das auf dem
>> Java Servlet API (aber ohne JSPs) aufbaut.
>
>
> Schön. Es ist gut zu wissen, das Scala nicht eine reine Lehrsprache
> sein und bleiben wird. Würde es nicht ausreichen, einfach ScalaServlets
> in einen Servlet-Container wie Tomcat zu hängen? Warum ein ganz eigener
> Server? Als "Beweis" für die Mächtigkeit der Sprache?
>
unserer scala-bugtracking webapp definieren wir einige JSP Taglibs mit
Scala, nach und nach werde ich wohl auch den Rest portieren. Einfach
weniger Zeilen zu lesen :)
Zur Frage warum man denn einen eigenen App-Server braucht: Ich finde,
wenn man schon eine Sprache mit besseren Typen hat, macht es auch Sinn,
dass diese Typen in besseren APIs ihre Anwendung finden. Typen, die XML
dtds ausdruecken zum Beispiel (auf der todo-Liste). Bei den meisten
Servlets waere es ein Vorteil, wenn sie nur valides XHTML produzieren
wuerden.
>> val theLink = 'a(Text("mein Link")) % (href <= "scala.epfl.ch");
>
>
> Ich denke, daran muss man sich erst einmal gewöhnen. Das "'" finde ich
> okay, das Text ist lästig, aber das "%" für die Attribute finde ich sehr
> gewöhnungsbedürftig. Curl hat es sehr geschickt verstanden, seine
Auch dass die Attribute hinten angefuegt werden ist etwas laestig, aber
da laesst sich vielleicht noch etwas machen. Allerdings gibt es viele
Einschraenkungen, da Attributdefinitionen nicht mit der Sprache, sondern
durch Libraries behandelt werden sollten.
cheers,
Burak
Stefan Matthias Aust
> Zur Frage warum man denn einen eigenen App-Server braucht: Ich finde,
> wenn man schon eine Sprache mit besseren Typen hat, macht es auch Sinn,
> dass diese Typen in besseren APIs ihre Anwendung finden.
Ja. Aber abzuwägen bleibt, ob nicht die vorhandene Lösung zwar
theoretisch weniger schön ist, dafür aber besser von Werkzeugen und
Dokumentation unterstützt werden. So finde ich zwar die Sprache Java
nur so la-la, aber bis eine andere Sprache das selbe bietet, was ich mit
Eclipse an Produktivität erzielen kann, dauert es einfach.
> Typen, die XML
> dtds ausdruecken zum Beispiel (auf der todo-Liste). Bei den meisten
> Servlets waere es ein Vorteil, wenn sie nur valides XHTML produzieren
> wuerden.
Ich bin nun nicht so der große Serverseiten-Entwickler, aber mit validem
XHTML hatte ich in meinen Programmen eigentlich nie Schwierigkeiten.
Ich als Entwickler kämpfe meist endlos lange (und ich ärgere mich jedes
Mal über die verschwendete Zeit) ein Design derart hinzubekommen, dass
es unter Mozilla und IE gleich aussieht, dann das Ergebnis aber in ein
HTML-Template zu übersetzen, was ich aus einem Servlet anspreche war nie
ein Problem.
Mich stört eher, dass jede Kombination von HTML und Programmiersprache -
sei es mittels JSP oder PHP oder sonstwas - immer häßlich und ein Bruch
ist. Ich bin nach wie vor nicht davon überzeugt, das man in jedem Fall
Präsentation und Logik trennen sollte, weil das häufig nur unter
Schmerzen geht und den Code umständlicher macht als er sonst wäre.
Daher fand ich Curls Ansatz (den ich leider nie praktisch ausprobiert
habe) gut, der eine gemeinsame Syntax für Markup und Logik präsentiert.
Ähnliches habe ich mal in kleinem Stil für Rebol probiert und
versucht, bei einem eigenen Template-Rahmenwerk zu berücksichtigen.
Nachteil dort, man konnte nicht vernünftig entwickeln, weil wieder alle
Werkzeuge fehlten (und ich einfach nur "da ist was falsch" als
Fehlermeldung lieferte, nicht die Zeile und den genaueren Grund :)
Die JBoss-Leute haben sich bei ihrem Nuke wohl dafür entschieden, Seiten
als Objekte zu verstehen, die sich selbst ausgeben können. Das ist IMHO
ein naheliegender objektorientierter Ansatz, der aber laut deren
Tutorial zu vielen "print <html>"-Statements in der "emit"-Methode
führt. Hier müsste eine bessere Syntax her.
> Auch dass die Attribute hinten angefuegt werden ist etwas laestig, aber
> da laesst sich vielleicht noch etwas machen. Allerdings gibt es viele
> Einschraenkungen, da Attributdefinitionen nicht mit der Sprache, sondern
> durch Libraries behandelt werden sollten.
Wenn XML-Verarbeitung und -Erzeugung ein so wichtiger Teil der Sprache
sein soll, ist doch vielleicht auch etwas Syntax erlaubt... Künstlicher
Minimalismus auf Krampf ist auch nicht gut :)