[ANN] The Scala Programming Language
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).
Christian Szegedy
> We'd like to announce availability of the first implementation of the
> Scala programming language.
Wow! This is the coolest thing since Haskell and Ruby!
I am currently implementing an application in Java. If I go over
to Scala, can I use the existing stuff and link it with the new
Scala code?
Is Scala stable enough to generate correct code for a larger
scale real life projects? Isn't it dangerous to relay on a
fresh project?
Jeff Massung
news:690aec1a.04012...@posting.google.com:
> A .net version of Scala is currently under
> development.
Is there an ETA?
--
Best regards,
Jeff jma[at]mfire.com
http://www.jm-basic.com
Matthias Zenger
> I am currently implementing an application in Java. If I go over
> to Scala, can I use the existing stuff and link it with the new
> Scala code?
Accessing Java classes from Scala code is no problem at all. Using a Scala
class from Java can get tricky, in particular if your Scala class uses
advanced features like generics, polymorphic methods, or abstract types.
Since Java doesn't have such language features, you have to know something
about the encoding scheme of Scala classes. Otherwise, there should be
no problems.
BTW, our current implementation of the Scala compiler mixes Scala
and Java code. The frontend is mostly written in Scala, whereas the
backends are still implemented in Java.
> Is Scala stable enough to generate correct code for a larger
> scale real life projects? Isn't it dangerous to relay on a
> fresh project?
You should give it a try. It's quite stable and if you encounter
an issue, you can submit the bug and we try to fix it as quickly as
possible. As a workaround you can always implement the problematic
part in Java.
== Matthias
Christian Szegedy
so that the user does not have to install the
full Scala environment?
Basically, I just want to give the user a jar
file which can be started by java -jar ... .
Joachim Durchholz
> We'd like to announce availability of the first implementation of the
> 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.
From a short look at the web site, I have seen that Scala addresses the
right questions. It will be interesting to see whether it also gives the
right answers (of course, what constitutes a "right" answer is, to a
substantial fraction, a matter of personal perspective).
I've got a couple of questions which will massively affect the
usefulness of Scala for people outside the Scala development team:
What are the plans for Scala in the near future, and in the long term?
If there's a long-term perspective, what are current ideas of how
anybody could (should) contribute?
What's the licensing conditions of the available Scala code? Does the
Scala team endorse a specific license?
Questions on Java interoperability:
How easy is it to convert Java data structures to Scala, and vice versa?
Do I have to write a separate wrapper for every kind of structure, or is
there a way to partially automate the process?
(Background: Since Scala doesn't seem to come with any libraries except
the absolute minimum, it's important how easy it is to use Java
libraries. And the biggest obstactle of using a foreign-language library
has always been the data conversion - usually a trivial but
time-consuming, boring, and error-prone task.)
Hope I'm asking the right questions :-)
Regards,
Jo
--
Currently looking for a new job.
Matthias Zenger
The Scala distribution comes with several jar files
in the lib subdirectory. If you want to package your
Scala application in a way that doesn't require the
user to install the full Scala environment, you simply
have to distribute a copy of the lib/scala.jar file
together with your application. You can even copy the
content of the scala.jar file into your own jar file
if you prefer this.
Currently, Scala is distributed under a BSD-style
license. Consequently, there are almost no implications
when redistributing the Scala binaries.
== Matthias
Matthias Zenger
> If there's a long-term perspective, what are current ideas of how
> anybody could (should) contribute?
Our Scala implementation is intended to be an open-source project.
We will release the full source code as soon as we think it is
stable enough so that others can contribute as well.
> What's the licensing conditions of the available Scala code? Does the
> Scala team endorse a specific license?
Scala is distributed under a BSD license.
> How easy is it to convert Java data structures to Scala, and vice versa?
You do not have to convert Java data structures at all for using them
in Scala. You can use them "as is". For instance, Scala classes can
subclass Java classes, you can instantiate Java classes in Scala, you
can access methods, fields (even if they are static), etc.
> Do I have to write a separate wrapper for every kind of structure, or is
> there a way to partially automate the process?
There are no wrappers to write, Scala is designed to interact directly
with Java abstractions. The Scala compiler generates all the necessary
code that is required when Java classes are accessed in Scala.
> (Background: Since Scala doesn't seem to come with any libraries except
> the absolute minimum, it's important how easy it is to use Java
> libraries. And the biggest obstactle of using a foreign-language library
> has always been the data conversion - usually a trivial but
> time-consuming, boring, and error-prone task.)
That was exactly the motivation why we wanted such a tight integration
with Java. You can use all Java libraries directly in your Scala
programs in the same way you would use them in Java.
== Matthias
Christian Szegedy
>
> The Scala distribution comes with several jar files
> in the lib subdirectory. If you want to package your
> Scala application in a way that doesn't require the
> user to install the full Scala environment, you simply
> have to distribute a copy of the lib/scala.jar file
> together with your application. You can even copy the
> content of the scala.jar file into your own jar file
> if you prefer this.
>
> Currently, Scala is distributed under a BSD-style
> license. Consequently, there are almost no implications
> when redistributing the Scala binaries.
>
> == Matthias
Thanks, this is so cool, I can hardly believe it's true :)
Joachim Durchholz
>> How easy is it to convert Java data structures to Scala, and vice
>> versa?
>
> You do not have to convert Java data structures at all for using them
> in Scala. You can use them "as is". For instance, Scala classes can
> subclass Java classes, you can instantiate Java classes in Scala, you
> can access methods, fields (even if they are static), etc.
Cool.
I'll have to check how well it works in GCJ (GNU Java->native code
compiler; JVMs are just too slow for my taste).
Christoph Breitkopf
> I'll have to check how well it works in GCJ (GNU Java->native code
> compiler; JVMs are just too slow for my taste).
In my experience they are often as fast or faster than the
native code produced by gcj, for an example see:
http://www.coyotegulch.com/reviews/almabench.html
Regards,
Chris
Christian Szegedy
> In my experience they are often as fast or faster than the
> native code produced by gcj, for an example see:
> http://www.coyotegulch.com/reviews/almabench.html
The homepage you cites supports Joachims assumptions:
gcj is faster. altough the difference is within the 2x
factor.
Fergus Henderson
The benchmarking on that page is potentially fundamentally flawed:
| How do I know that the programs are producing the correct output? Each
| program includes code to display results; I run the programs with I/O
| to ensure that all calculations are being performed, then I comment out
| any header inclusions, imports, and print statements for actual testing.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Ketil Malde
> The benchmarking on that page is potentially fundamentally flawed:
>| How do I know that the programs are producing the correct output? Each
>| program includes code to display results; I run the programs with I/O
>| to ensure that all calculations are being performed, then I comment out
>| any header inclusions, imports, and print statements for actual testing.
I guess Haskell would do really, really well in such a test :-)
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Christoph Breitkopf
> > I'll have to check how well it works in GCJ (GNU Java->native code
> > compiler; JVMs are just too slow for my taste).
>
> In my experience they are often as fast or faster than the
> native code produced by gcj, for an example see:
> http://www.coyotegulch.com/reviews/almabench.html
Seems that was a bad example, here are some more links:
http://www-106.ibm.com/developerworks/java/library/j-native.html?loc=j
http://www.shudo.net/jit/perf/
It may be that things have gotten better with recent gcj
releases, but it seems that at least the IBM JVM can easily
hold its own against gcj. Perhaps other native compilers
like Tower J generate better code, though.
Without profile feedback for the static compiler, the
JITs will always have the advantage of better information
on the local level.
Regards,
Chris
Joachim Durchholz
Hmm...
Curiouser and curiouser, as Alice would say...
I'm wondering what these compilers and VMs are really doing, behind the
scenes: running machine code should really be faster than interpreting
bytecodes.
Maybe IBM's VM is doing a compile-to-native-code at load time? It's easy
to do that unnoticed if you don't do any fancy global analysis. The
problem with the Hotspot approach advocated by Sun is that you
effectively run the code with code profiling turned on, always. If
you're not ultra-careful, this will slow the whole thing down. (And
having to be ultra-careful cuts down on design alternatives in other
areas, which may mean that efficient solutions for other issues have
become unavailable. Restricting the design space usually means you have
pay a price in an area that seems to be totally unrelated at first sight.)
Well, just guessing...
Joachim Durchholz
> Seems that was a bad example, here are some more links:
>
> http://www-106.ibm.com/developerworks/java/library/j-native.html?loc=j
> http://www.shudo.net/jit/perf/
These pages are from Jan and Feb 2002, which is quite ancient.
The Coyote Gulch page is newer (Jan 2003), and reports a substantial
general slowdown when going from JDK 1.3 to 1.4, without relevant
changes to the relative speeds of interpreted and compiled Java.
That's bad news - it suggests that Java tends to be slow more due to
language design decisions rather than because it's compiled. In a sense,
this confirms Sun's hype that compiled code can be as fast as
interpreted code, but probably not in a way that Sun likes...
Since all that information is already a bit outdated, some more recent
benchmarks would be really interesting :-)
Marshall Spight
>
> I'm wondering what these compilers and VMs are really doing, behind the
> scenes: running machine code should really be faster than interpreting
> bytecodes.
Um, you know that no Java release since 1.0.2 has relied on interpreting
bytecodes as its only form of execution, right?
> Maybe IBM's VM is doing a compile-to-native-code at load time? It's easy
> to do that unnoticed if you don't do any fancy global analysis. The
> problem with the Hotspot approach advocated by Sun is that you
> effectively run the code with code profiling turned on, always.
Funny, I would have said that the *advantage* of the Hotspot approach
is that you are always able to profile.
Marshall
Marshall Spight
I've done various benchmarks of jdk1.3 vs gcj, and gcj
always lost. Sometimes badly. I've seen various pages
on the net showing the same thing.
If I read that page correctly, it was only testing floating
point performance; not Java's strong point. He also
makes sweeping generalizations about entire JVMs
after only testing double precision floating point
performance.
Marshall
Marshall Spight
> Christoph Breitkopf wrote:
>
> > Seems that was a bad example, here are some more links:
> >
> > http://www-106.ibm.com/developerworks/java/library/j-native.html?loc=j
> > http://www.shudo.net/jit/perf/
>
> These pages are from Jan and Feb 2002, which is quite ancient.
> The Coyote Gulch page is newer (Jan 2003), and reports a substantial
> general slowdown when going from JDK 1.3 to 1.4, without relevant
> changes to the relative speeds of interpreted and compiled Java.
The above paragraph would be correct if you removed the word "general."
In fact, jdk 1.3 and 1.4 have substantially different performance characteristics.
Some programs will go faster; some will go slower. If you measure
across a broad selection of different kinds of programs, you'll
notice a substantial general speedup when going from JDK 1.3 to 1.4.
> That's bad news - it suggests that Java tends to be slow more due to
> language design decisions rather than because it's compiled.
Oh, please.
Marshall
Christian Szegedy
> - Abstract types and mixin composition unify ideas from object and
> module systems.
I am playing around with the type system of Scala and hove some
questions.
I tried to define some abstract algebraic structured. After reading
the turorials, I have found the following construction which I
don't understand generally, but found extremely useful:
trait Abel[a <: Abel[a]] : a {
def + (that : a) : a;
}
I don't understand formally what does ": a" mean in the type
declaration. However it seems to work out perfectly and seems
to be a very good replecement for Haskell type classes.
Then I went on and tried the following:
trait Ring[r <: Ring[r]] : r extends Abel[r] {
def * (that : r) : r;
}
trait LMod[r <: Ring[r],m <: LMod[r,m]] : m extends Abel[m] {
def * (that : r) : m;
}
This is also very nice, but how about right module. I don't see
any possibility to define multiplications from the right by
some other class. It seemsto be a minor syntactic problem, but
then I considered the following question:
How can I specify the following relation for two classes:
class a must have member function f : b and class b must have a
member function g : a.
Can I define a trait in Scala to declare this relationship for
two type parameters?
Joachim Durchholz
> "Joachim Durchholz" <joachim....@web.de> wrote:
>>Maybe IBM's VM is doing a compile-to-native-code at load time? It's easy
>>to do that unnoticed if you don't do any fancy global analysis. The
>>problem with the Hotspot approach advocated by Sun is that you
>>effectively run the code with code profiling turned on, always.
>
> Funny, I would have said that the *advantage* of the Hotspot approach
> is that you are always able to profile.
Only while you're tuning the program.
Once you're done with optimization, there's no point in further
statistics gathering, all it does is burn CPU cycles.
(This assumes that Hotspot continues to gather statistics after it has
optimized a piece of code, as your statement seems to imply.)
Matthias Zenger
> trait Abel[a <: Abel[a]] : a {
> def + (that : a) : a;
> }
>
> I don't understand formally what does ": a" mean in the type
> declaration. However it seems to work out perfectly and seems
The ": a" in your class declaration means that the self reference
"this" has type a. In other words, you are defining the signature
of a binary method + whose left and right argument have the same
type a. Furthermore, the compiler will check that the self-type
of every extension of Abel[a] is a subtype of a (which is the
self-type of Abel[a]). The following example illustrates what
this means in practice:
class G1 extends Abel[G1] {
def +(that: G1) = that;
}
class G2 extends Abel[G1] {
def +(that: G1) = that;
}
The first class compiles because the self-type G1 of class G1
is a subtype of the self-type of Abel[G1]. The second class
doesn't compile because G2 is not a subtype of G1. The compiler
yields the following error message:
T.scala:10: illegal inheritance;
self-type G2 does not conform to Abel[G1]'s selftype G1
class G2 extends Abel[G1] {
^
BTW, you can close the bound for class G2 with type G1 if you
mix class G1 into class G2. This turns G2 into a subtype of G1
and the self-types of the sub- and the superclass conform
again. So the following program will actually compile:
class G2 extends Abel[G1] with G1 {
override def +(that: G1) = that;
}
> trait Ring[r <: Ring[r]] : r extends Abel[r] {
> def * (that : r) : r;
> }
>
> trait LMod[r <: Ring[r],m <: LMod[r,m]] : m extends Abel[m] {
> def * (that : r) : m;
> }
>
> This is also very nice, but how about right module. I don't see
> any possibility to define multiplications from the right by
> some other class. It seemsto be a minor syntactic problem, but
I am not sure if I understand your question. If you want to
define a right-associative operator, you have to prepend a colon.
All operators whose name ends with a colon are right-associative
by definition. Here's an example:
class MyInt(x: Int) {
def *:(y: Int) = x * y;
}
val x = new MyInt(7);
If you now write "1 *: x", this will be interpreted as
"val temp = 1; x.*:(temp)".
> then I considered the following question:
>
> How can I specify the following relation for two classes:
>
> class a must have member function f : b and class b must have a
> member function g : a.
>
> Can I define a trait in Scala to declare this relationship for
> two type parameters?
You really ask the hard questions... :-)
I guess you refer to the famous Subject/Observer problem. I am
not sure if you can do that with F-bounds in Scala, but you
can do it definitely with abstract types. Here's the code:
import scala.collection.mutable._; // just for accessing the Set type
trait SubjectObserver {
type Observer <: BaseObserver;
trait BaseObserver {
def notify(s: Subject, e: Event): Unit;
}
type Subject <: BaseSubject;
class BaseSubject: Subject {
var obs: Set[Observer] = new HashSet;
def add(o: Observer): Unit = obs += o;
def notify(e: Event): Unit = obs foreach { o => o.notify(this, e) }
}
type Event;
}
The SubjectObserver trait abstracts over the types Observer, Subject,
and Event. I defined "default" implementations for Observer and Subject,
but left the Event type completely undefined. Note that you have to
set the self-type of class BaseSubject to Subject, otherwise the call
o.notify(this, e) will fail. This is because "this" would have the
wrong type in this case!
Now you can go on and specify a concrete SubjectObserver extension
or refine the whole abstraction covariantly. For completeness, I
just show what you have to do to make it concrete:
object SimpleSubjectObserver extends SubjectObserver {
type Observer = SimpleObserver;
class SimpleObserver extends BaseObserver {
def notify(s: Subject, e: Event) =
Console.println("message "+e+" was sent to "+this+" from "+s);
}
type Subject = BaseSubject;
type Event = Any;
}
I hope that helps!
== Matthias
Vincenzo aka Nick Name
> Maybe IBM's VM is doing a compile-to-native-code at load time? It's easy
> to do that unnoticed if you don't do any fancy global analysis
But IBM would tell you :)
V.
Christian Szegedy
> The ": a" in your class declaration means that the self reference
> "this" has type a. In other words, you are defining the signature
> of a binary method + whose left and right argument have the same
> type a.
Thanks, it was my intuitive expectation also, but I was unsure
whether it is a very special notion or the special case of a
more general picture.
> I am not sure if I understand your question. If you want to
> define a right-associative operator, you have to prepend a colon.
Thanks. Altough it is not so general as in Haskell, (Hereby, I mean
the possibility to define operators in multiparameter type classes,
*not* the fixity declaration for operators - that'a different story)
but seems to be good enough for most applications.
> object SimpleSubjectObserver extends SubjectObserver {
> type Observer = SimpleObserver;
> class SimpleObserver extends BaseObserver {
> def notify(s: Subject, e: Event) =
> Console.println("message "+e+" was sent to "+this+" from "+s);
> }
> type Subject = BaseSubject;
> type Event = Any;
> }
>
> I hope that helps!
I see. It was exactly answering my question. Thanks!
Now I am convinced that Scala's class/typing system is really
more powerful than the module system of ML/OCaml.
Joachim Durchholz
> We'd like to announce availability of the first implementation of the
> Scala programming language.
There's one thing that I do *not* like about Scala: that notion of "self
type".
Self types are a vehicle to introduce type constraints that depend on
the type of "self" (or "this" or "Current", depending on the OO language
du jour). However, there's no reason to assume that all constraints
should be relative to that type; a routine in class Foo might well have
two parameters which should have the same type, or a requirement that
one parameter is a subtype of the other parameter's type (and both
constrained to some common part of the type hierarchy).
IOW I think self types are artificially constrained; a language that has
subtyping should have a notion of constraints between arbitrary types in
a signature.
What's worse is that the concept of a "self type" looks quite special.
Programmers will get into all sorts of mental loops trying to understand
the implications of a self type in any concrete situation.
I think the more general concept is actually easier to understand (it's
really no big deal to explain type constraints, and the special rules
that apply for the type of "self" come as a natural specialization of
the concept, not as a complicated issue that must be learned by heart
before one can confidently program with it).
Disclaimer: I haven't read anything substantial on Scala. It may well be
that self types are just syntactical sugar, or that some other factor
holds that renders my above critique irrelevant. I simply didn't have
the time to really read up on Scala (and there's also that SML stuff
sitting on the bookshelf and waiting for me... oh dear).
Ketil Malde
>> Funny, I would have said that the *advantage* of the Hotspot approach
>> is that you are always able to profile.
> Only while you're tuning the program. Once you're done with
> optimization, there's no point in further statistics gathering, all
> it does is burn CPU cycles.
Well, I'm no expert in either field, but it seems to be the situation
is pretty analogous to CPU architectures (which is, of course, just
the lower level of VM).
The "traditional" approach is out-of-order execution, which means the
CPU is dynamically reordering the instruction stream to keep the
execution units busy. So if one instruction stalls (because it needs
to wait for a memory request to complete), other instructions further
ahead can be executed. Transmeta are, perhaps, going even further
with an integrated JIT compiler for x86 instructions on top of a VLIW
architecture. Or at least, that's what the ads seem to say.
Some (i.e. Intel and HP) have based their strategy (i.e. IA64) on
static compiler scheduling to keep the execution units busy instead.
(In theory, this would give you a simpler CPU, but in practice, I
think the Itaniums have ended up as complex as they come)
Currently, OoO seem to do pretty well, and with less resources thrown
at it (e.g. when the P4 got more cache, but still less, I think, than
high-end Itanium, they beat it on SpecCPU), but we'll see how it pans
out in the end. It is at least clear that getting similar performance
from static analysis is very hard, so it's certainly not *obvious*
that static optimization is superior.
Christian Szegedy
> Self types are a vehicle to introduce type constraints that depend on
> the type of "self" (or "this" or "Current", depending on the OO language
> du jour). However, there's no reason to assume that all constraints
> should be relative to that type; a routine in class Foo might well have
> two parameters which should have the same type, or a requirement that
> one parameter is a subtype of the other parameter's type (and both
> constrained to some common part of the type hierarchy).
> IOW I think self types are artificially constrained; a language that has
> subtyping should have a notion of constraints between arbitrary types in
> a signature.
>
I don't understand the Scala concept completely: Self types are
not clear to me at all, but in Scala you can have arbitrary constraint
between any types, so I don't really see the point.
For example:
class Foo
{
def f[a <: b, b <: MyTrait[a]] (x:Array[a],y:Function[a,b]) : Array[b]
}
is legal Scala code.
Christian Szegedy
>
> BTW, you can close the bound for class G2 with type G1 if you
> mix class G1 into class G2. This turns G2 into a subtype of G1
> and the self-types of the sub- and the superclass conform
> again. So the following program will actually compile:
>
> class G2 extends Abel[G1] with G1 {
> override def +(that: G1) = that;
> }
>
Wow! Yestarday I went on experimenting and defined free groups
modules etc. I really had problems and came up
with some working, but somewhat clumsy solution.
Today, I read your post again and noticed that I overlooked this
important remark of you. Now the free Abelian groups became:
---------------------------------------
trait Abel[a <: Abel[a]] : a {
def + (that : a) : a;
def - (that : a) : a;
def zero : a;
}
class Expr extends Abel[Expr] {
def +(that: Expr) : Expr = Plus(this,that);
def -(that: Expr) : Expr = Minus(this,that);
def zero = Zero()
}
case class Plus(e1 : Expr,e2 : Expr)
extends Abel[Expr] with Expr;
case class Minus(e1 : Expr,e2 : Expr)
extends Abel[Expr] with Expr;
case class Zero() extends Abel[Expr] with Expr {
override def +(that : Expr) = that;
}
---------------------------------------
A solution, I am much more content with. :)
Scala is in tune!
My only problem is only the zero function. I would like
to have is a zero function (or better value) on per class base,
I can use even if I don't have any element of the abel group
at hand. I think of something like static function or variable
in C++.
Is there a way in Scala to solve this elegantly?
chain...@hotmail.com
> These pages are from Jan and Feb 2002, which is quite ancient.
> The Coyote Gulch page is newer (Jan 2003), and reports a substantial
> general slowdown when going from JDK 1.3 to 1.4, without relevant
> changes to the relative speeds of interpreted and compiled Java.
> That's bad news - it suggests that Java tends to be slow more due to
> language design decisions rather than because it's compiled. In a sense,
> this confirms Sun's hype that compiled code can be as fast as
> interpreted code, but probably not in a way that Sun likes...
As a side note: Bigloo automatically produces Java back-ends from
Scheme code.
Steer the comp.lang.scheme google repository and look for my thread of
the Coyote Gulch benchmark based on Bigloo code.
I only mention that because, as otherwise believed, Bigloo has a lot
to offer and is just not like a simple R5RS Scheme implementation. I
think a lot of people are unaware of that.
Fensterbrett
Matthias Zenger
> I don't understand the Scala concept completely: Self types are
> not clear to me at all, but in Scala you can have arbitrary constraint
Scala does not really have self types (in the sense Kim Bruce uses
them for example). Scala offers "explicitly typed self references".
This is different. I guess Scala is the first language that offers
a feature like this, but it's really simple: You have the possibility
to give "this" a different (better) type and the Scala type system
makes sure that the type of "this" in a subclass is a subtype of the
type of "this" of the superclasses. Furthermore, it is not possible
to instantiate classes whose "this" type is *not* a supertype of the
class type itself. That's all!
Anyway, 99% of all programmers will probably never have to
understand the concept. It's required only when extensible
software has to be written (e.g. also for solving the binary
methods problem, as you mentioned) and "this" doesn't have
the "right" type.
== Matthias
Matthias Zenger
>> object SimpleSubjectObserver extends SubjectObserver {
>> type Observer = SimpleObserver;
>> class SimpleObserver extends BaseObserver {
>> def notify(s: Subject, e: Event) =
>> Console.println("message "+e+" was sent to "+this+" from "+s);
>> }
>> type Subject = BaseSubject;
>> type Event = Any;
>> }
>>
>> I hope that helps!
>
>
> I see. It was exactly answering my question. Thanks!
> Now I am convinced that Scala's class/typing system is really
> more powerful than the module system of ML/OCaml.
Strictly speaking, this is not fully true. In Scala you cannot
model OCaml's applicative functors. Furthermore, Scala has a
nominal type system; it's not possible to express structural
types.
Anyway, I am not sure if something like applicative functors
make sense for a language like Scala. But I am sure that
a nominal type system is an advantage.
== Matthias
Christian Szegedy
> You have the possibility
> to give "this" a different (better) type and the Scala type system
> makes sure that the type of "this" in a subclass is a subtype of the
> type of "this" of the superclasses. Furthermore, it is not possible
> to instantiate classes whose "this" type is *not* a supertype of the
> class type itself. That's all!
OK, thanks. Now, it's completely clear to me.
Anyway, I don't think it is for only 1% of the programmers.
Even, if they don't use (what I doubt), they still have to
understand if they see it. OTOH, it seems to be very
important and useful in general.
BTW, I really start to appreciate the seamless melting of
object oriented and functional programming methods in Scala.
The language is extremely streamlined and even the hardest
concepts are easy to use.
Melting the concept of algebraic datatypes into the object
hierarchy is very nice and pragmatic. The only drawback
I see is that the compiler can't generate warnings if a pattern
matching is not exhaustive. Is there some solution for this?
Matthias Zenger
> case class Plus(e1 : Expr,e2 : Expr)
> extends Abel[Expr] with Expr;
Why didn't you just subclass Expr? You could have written:
case class Plus(e1: Expr, e2: Expr) extends Expr;
> case class Zero() extends Abel[Expr] with Expr {
> override def +(that : Expr) = that;
> }
> My only problem is only the zero function. I would like
> to have is a zero function (or better value) on per class base,
> I can use even if I don't have any element of the abel group
> at hand. I think of something like static function or variable
> in C++.
>
> Is there a way in Scala to solve this elegantly?
Statical definitions are usually defined within top-level
singleton objects. Since Zero is just a static value of
a specific type, you can represent it directly as a top-level
singleton case object. Here's the code:
case object Zero extends Abel[Expr] with Expr {
override def +(that : Expr) = that;
}
I just replaced the keyword "class" with "object". Now you
can write simply "Zero" to access your zero element. Of course
you can also pattern-match against it.
Christian Szegedy
> I just replaced the keyword "class" with "object". Now you
> can write simply "Zero" to access your zero element. Of course
> you can also pattern-match against it.
>
> I hope that helps!
Thanks. It was new to me. What I miss is the possibility
to declare the existance of a zero object (or whatever)
in the trait Abel.
One possibility, I see is to declare it as a type
inside the trait Abel. However looks to counterintuitive to me,
besides it leaves more than necessary freedom to the
implementation.
Andreas Rossberg
>
> But I am sure that
> a nominal type system is an advantage.
Can you elaborate on that? I always felt the opposite, except that you
might run into more problems with type inference.
- Andreas
--
Andreas Rossberg, ross...@ps.uni-sb.de
"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.
Matthias Zenger
>> But I am sure that a nominal type system is an advantage.
>
> Can you elaborate on that? I always felt the opposite, except that you
> might run into more problems with type inference.
With a structural type system you cannot distinguish
two objects that have the same type but incompatible
semantics. Consequently, the type system cannot detect
situations where an object with a matching type is used
in a place where an object with a completely different
semantics is expected.
Nominal type systems allow programmers to define many
object types that all have the same structure, but
different names. Here you can distinguish incompatible
objects that have coincidentally the same structural type
because the programmer has to explicitly specify their
nominal type (and relations between the nominal types).
A disadvantage is that nominal types hinder reusability,
because a programmer has to anticipate all the types of
an object. So, in the end, it's a trade-off between
reusability and safety.
Scala offers a very restricted form of structural subtyping
through its parametric types (+ variance annotations) and
its type refinements.
== Matthias
Matthias Zenger
> One possibility, I see is to declare it as a type
> inside the trait Abel. However looks to counterintuitive to me,
I don't think you want that because of Scala's dependent
type system. You would get for every object of type Abel
a new Zero type!
> besides it leaves more than necessary freedom to the
> implementation.
You could do the following:
object Abel {
object Zero extends ...
}
Then you can access Zero like a static field in Java by
writing: Abel.Zero.
== Matthias
Matthias Zenger
> Melting the concept of algebraic datatypes into the object
> hierarchy is very nice and pragmatic. The only drawback
> I see is that the compiler can't generate warnings if a pattern
> matching is not exhaustive. Is there some solution for this?
In general, there is no solution, unless you accept to write
default cases all the time. The problem is that we have an
open world in Scala/Java/ etc. You actually don't know all
the case classes that subclass a given class. Consequently,
it's impossible to say that a pattern matching expression without
a default case is exhaustive.
The language specification mentions that it's possible to
define closed types by tagging a class definition final and
by subclassing it within the same compilation unit (that's
possible). But so far, the pattern matcher doesn't do anything
special for such types.
== Matthias
Christian Szegedy
> You could do the following:
>
> object Abel {
> object Zero extends ...
> }
>
> Then you can access Zero like a static field in Java by
> writing: Abel.Zero.
>
> == Matthias
>
I don't see what you mean.
This is my original trait:
trait Abel[a <: Abel[a]] : a
{
def + (that : a) : a;
def - (that : a) : a;
}
I would like to declare the existence of an object zero
which depends on template paremater a.
What do I write?
Christian Szegedy
> The language specification mentions that it's possible to
> define closed types by tagging a class definition final and
> by subclassing it within the same compilation unit (that's
> possible). But so far, the pattern matcher doesn't do anything
> special for such types.
It would be nice to get a warning at least then.
When I program in OCaml, I typically get this
warning several times, and 9 cases out of 10 are
real programming errors.
Christian Szegedy
----------------------------------------------
trait Abel
{
type Element;
trait Trait : Element
{ def +(that : Element) : Element; }
def zero : Trait;
}
class MyAbel extends Abel
{
case class MyElement() extends Trait
{ def +(that : Element) = MyElement() }
type Element = MyElement;
def zero = MyElement();
}
----------------------------------------------
Of course, it's a bit more heavyweight, but works.
(The second part is just an example of usage.)
Matthias Zenger
> I don't see what you mean.
>
> This is my original trait:
>
> trait Abel[a <: Abel[a]] : a
> {
> def + (that : a) : a;
> def - (that : a) : a;
> }
>
> I would like to declare the existence of an object zero
> which depends on template paremater a.
>
> What do I write?
Sorry, I misunderstood you. In this case I propose to
use a container with an abstract type (that's simpler than
using F-bounded polymorphism anyway):
trait Algebra {
trait Abel: a {
def +(that: a): a;
def -(that: a): a;
}
type a <: Abel;
val Zero: a;
}
Now you can create a concrete instance:
object MyAlgebra extends Algebra {
trait Expr extends Abel {
def +(that: Expr): Expr = Plus(this, that);
def -(that: Expr): Expr = Minus(this, that);
}
type a = Expr;
case class Plus(e1: Expr, e2: Expr) extends Expr;
case class Minus(e1: Expr, e2: Expr) extends Expr;
case object Zero extends Expr {
override def +(that : Expr) = that;
}
}
== Matthias
Christian Szegedy
> trait Algebra {
> trait Abel: a {
> def +(that: a): a;
> def -(that: a): a;
> }
> type a <: Abel;
> val Zero: a;
> }
>
I've already tried that. It does not work that way, since
type a <: Abel
is a definition (not a declaration), so the subclass can't
override it.
Andreas Rossberg
>
> With a structural type system you cannot distinguish
> two objects that have the same type but incompatible
> semantics. Consequently, the type system cannot detect
> situations where an object with a matching type is used
> in a place where an object with a completely different
> semantics is expected.
Right, that's why you want a type abstraction facility. As you say,
there is a trade-off between abstraction and reusability. Hence
subtyping and type abstraction should be separate but freely composable
features, giving you a choice. Nominal typing as the default (or even
sole) approach does not seem superior to me.
> Scala offers a very restricted form of structural subtyping
> through its parametric types (+ variance annotations) and
> its type refinements.
That was one of the things that was not quite clear to me at first.
Originally I thought at least traits and compound types would be fully
structural, while classes aren't - the nominal nature of Java interfaces
always made them pretty useless in my eyes (they are just a restricted
form of abstract classes), so I expected something along the lines of ML
signatures.
Another thing that puzzled me is that Scala does not seem to support
higher-order abstract types. Would they cause problems?
Anyway, I'm still quite impressed by what Scala offers.
Morris Carré
> We'd like to announce availability of the first implementation of the
> Scala programming language.
Looks beautiful. What's the best Scala equivalent of Python's
filter(lambda W : W not in "ILLITERATE","BULLSHIT") ?
[The shortest Turing-test passing program I know]
Christian Szegedy
>
> I've already tried that. It does not work that way, since
> type a <: Abel
> is a definition (not a declaration), so the subclass can't
> override it.
>
Sorry, I must have made a mistake while trying out. It works
as you stated. Thanks!
Martin Odersky
> There's one thing that I do *not* like about Scala: that notion of "self
> type".
> Self types are a vehicle to introduce type constraints that depend on
> the type of "self" (or "this" or "Current", depending on the OO language
> du jour). However, there's no reason to assume that all constraints
> should be relative to that type; a routine in class Foo might well have
> two parameters which should have the same type, or a requirement that
> one parameter is a subtype of the other parameter's type (and both
> constrained to some common part of the type hierarchy).
Absolutely. As Matthias Zenger wrote, you can express type constraints
by attaching lower and upper bounds of type variables. The `self
types' in Scala
take some getting used to. Their motivation is that in object-oriented
programming, `this' can be seen as an implicit parameter for a
function.
Now, traditional statically typed OO languages allow you to attach an
arbitrary
type to every function parameter *except* to the implicit self
reference `this'. The latter's type is always the same as the
enclosing class.
It turns out that this restriction severely hampers efforts to write
extensible class hierarchies in object-oriented languages. One way to
get around this is the "mytype" concept of Kim Bruce. Mytype is a
special type
which changes along with the inheritance hierarchy. Scala's self types
are different, and much more direct; they simply allow you to attach
an explicit type to `this'; the same way you can do it for other
parameters.
(If you leave out the self type, you get the type of the enclosing
class, of course).
It might seem strange that you can attach an arbitrary type to `this'
and still have a sound type system. The trick is that you can do this
only for abstract classes or traits. Scala's type system enforces that
the self type
is ``reasonable'' at the point where you instantiate a class. (More
precisely, the selftype must be a supertype of the type of the object
being instantiated).
Btw we discovered self types more than inventing them when we worked
on
NuObj [see papers in FOOL 10, ECOOP 2003], which can be seen a
type-theoretic foundation of Scala. There, the technical treatment was
simplified by making explicit the type of `this'. Afterwards, we
discovered that this was not just a technical trick, but that it was
very useful for expressing extensible class hierarchies.
Cheers
-- Martin
Joachim Durchholz
> Joachim Durchholz <joachim....@web.de> wrote:
>
>>There's one thing that I do *not* like about Scala: that notion of "self
>>type".
>>Self types are a vehicle to introduce type constraints that depend on
>>the type of "self" (or "this" or "Current", depending on the OO language
>>du jour). However, there's no reason to assume that all constraints
>>should be relative to that type; a routine in class Foo might well have
>>two parameters which should have the same type, or a requirement that
>>one parameter is a subtype of the other parameter's type (and both
>>constrained to some common part of the type hierarchy).
>
> Absolutely. As Matthias Zenger wrote, you can express type constraints
> by attaching lower and upper bounds of type variables.
Right - that's why I was a bit surprised to see the notion of "self
type" in the first place.
> Now, traditional statically typed OO languages allow you to attach an
> arbitrary
> type to every function parameter *except* to the implicit self
> reference `this'. The latter's type is always the same as the
> enclosing class.
> It turns out that this restriction severely hampers efforts to write
> extensible class hierarchies in object-oriented languages.
Yup.
> One way to
> get around this is the "mytype" concept of Kim Bruce. Mytype is a
> special type
> which changes along with the inheritance hierarchy.
That's what I found to be too special. It solves the binary operator
problem, but not the parallel type hierarchy problem (of which the
binary operator problem is a special though extremely common case).
Speaking of parallel type hierarchies: is this possible?
Let me first explain the situation, so that the most general case (as
far as I know it) is covered:
Assume you have a pool of vehicles, and a pool of drivers.
Drivers and vehicles must match: if there is a Driver and a Vehicle
class, and (say) a Captain and a Ship class on one hand and a
TruckDriver and a Truck class on the other hand, you want to make sure
that it's impossible to let a Captain drive() a Truck. (Well, actually
we want to prevent a Captain from doing that unless he also happens to
be a TruckDriver - some people have more than one kind of license *g*.)
Ideally, a type system should be able to express this kind of constraint
statically.
Even more ideally, there's also a way to have run-time checking; for
example, there might be a large polymorphic list that takes all the
available Drivers, and if a Driver is needed for a Vehicle, static type
checking is impossible by design, so there must be some run-time type
checking involved here. The last line of defense would then be a
run-time type check made by the system and a thrown exception if the
types don't match.
Now let me raise the bar a little: the type hierarchies aren't entirely
parallel. For example, implementation details might have made it
necessary to create two kinds of TruckDriver which both should be able
to drive Trucks. These TruckDrivers also have additional subclasses that
drive not only Trucks but SpecialTrucks as well.
I.e. the type hierarchy would look like this:
Driver Vehicle
-----------|-----------------------|------------
TruckDriver |
/ \ Truck
TruckDriverA TruckDriverB |
------|----------------------------|------------
HeavyTruckDriver HeavyTruck
The dashed lines separate groups of classes that can cooperate for a
drive() call.
(In practice, I'd probably model vehicles and drivers differently, with
much less subtyping; this is just a contrived example for structures
that I have seen the need for in other OO languages, and were simply
unable to express properly.)
> Scala's self types
> are different, and much more direct; they simply allow you to attach
> an explicit type to `this'; the same way you can do it for other
> parameters.
Then I'll have to look at the details.
Seems like I got misled from a keyword that was used in a different way
in a different context. ("mytype" is really different from the self type
construct... no "magic rewriting" here.)
[Snipped part of post mentally archived for later use.]
damien.guichardwanadoo.fr
Functionnal and OO paradigms are highly compatible and great benefits come
when their are merged.
Two remarks:
1. On the contrary it seems to me that pattern matching and OO are
incompatible, Scala pattern matching is restricted to constructors so it
does not violate data-hiding. However then pattern-matching can't be used
for implementation, which is a severe limitation compared to patterns at
full power.
2. It's surprising Scala does not support Design-By-Contract. Without
Design-by-Contract much of the benefit of a well-designed strong type system
is wasted. What is the motivation for not including DbC?
Regards,
Damien
Morris Carré
>
> scala.epfl.ch
>
Scala has the beauty of a frozen cameleon. A tongue ready to strike.
I read XML processing being given as an important justification to the language.
My wishlist therefore would include a rich class of XSLT programs with an
automatic mapping to and fro equivalent Scala code. A Scala style that would
compile to XSLT programs that it mimicks, is that thinkable ?
Also, do you believe it feasible to use SVG elegantly, as a graphical
front-end to Scala, using its XML approach ? SVG clients typically allow
scripting in Ecmascript and Java, can Scala insert itself through the JVM ?
Best, MC
Christian Szegedy
Scala. I think, I detected a class of commonly occuring
situations that causes me real headaches when programming
in Scala.
We have a collection of some function and data-types
together and some constraints between the datatypes
and the function. (Typically somathing you would put
into a Haskell type class, an ML module or a C++ class).
For simplicity, we assume that our abstract interface has
one type C, some member m mapping to C, and some static
data value d used by the class.
Now in Scala you would write:
---------------------------------------------
object M
{
trait C[t <: C[t]] : t { def m:t }
}
trait M
{
type C <: M.C[C];
val d:C;
}
--------------------------------------------
To implement this interface, you could write:
object Dummy entends M
{
class t extends M.C[t]
{ def m = this; }
type C=t;
object dummy extends t;
val d = dummy;
}
-------------------------------------------
Now, I would like to define a trivial tranformation F,
wrapping the M.C in another class. Now, things get
tricky, but it is doable.
For simplicity, I will implement the transformation as
a member of object M:
object M
{
trait C[t <: C[t]] : t { def m:t }
def F(x:M):M =
{
object result extends M
{
case class t[p <: M.C[p]](v:p) extends M.C[t[p]]
{ def m = t[p](v.m); }
type C = t[x.C];
val d:t[x.C] = t[x.C](x.d);
};
result
}
}
It looks well planned, but has several flaws:
It would cease to work, if method m must return (or use)
the static data d, which is generally thinkable,
The gravest problem is that outside we can only we are never
able to create elements of F(m).C by wrapping elements
of m.C. To establish this, the return type of F must
encode the conversion function x.C -> F(x).C.
This seems to be inherently inpossible, since the
return is not nown in advance, since it is constructed
inside F.
One idea is to move class t outside F, and introduce a
template for type x.C in F. This gives:
------------------------------------------------------
object M
{
trait C[t <: C[t]] : t { def m:t }
case class t[p <: C[p]](v:p) extends C[t[p]]
{ def m = t[p](v.m); }
trait MT[a,b] extends M
{
def c(v:a):b;
}
def F[a<:C[a]](x:M):MT[a,t[a]]=
{
object result extends MT[a,t[a]]
{
type C = t[x.C];
def c(v:a) = t[a](v);
// val d:t[x.C] = t[x.C](x.d);
};
result
}
}
trait M
{
type C <: M.C[C];
/ val d : C;
}
-----------------------------------------------------
I commented out the data value d, since the scala
compiler crashed while compiling if it was there.
Uo to the compiler crash, the solution seems to work fine.
However the following drawbacks remain:
1) Template parameter for x.C must be explicitely specified
when calling F. This is unelegant and error-prone.
If interface M would be more complicated, it is
thinkable that even more template paramaters are needed to
be explicitely specified specified at each call.
2) If class t[p] must use static data members of x.C or
the result object, then everything gets even more involved
and unelegant. There is seemingly only one solution: a
pointer to the object must be stored in each element of C.
Since each object already holds a pointer type information,
this means redundant bookkeeping and a waste of memory and
cache performance.
Therefore I would be interested, whether there is another
better solution, which avoids these problems. Note that in
OCaml or C++, the solution to such problems is fairly
straightforward. Of course, one must admit, that in C++
the template system is much more unsafe, and a lot of
problems are detected only while using the templates.
Basically, my first impression is that disallowing static data,
attached to classes together with the lack of a
ML like modul system severly hurts the usability of Scala.
Michel Schinz
[...]
> 1. On the contrary it seems to me that pattern matching and OO are
> incompatible, Scala pattern matching is restricted to constructors
> so it does not violate data-hiding. However then pattern-matching
> can't be used for implementation, which is a severe limitation
> compared to patterns at full power.
I'm afraid I don't really get what you mean here.
> 2. It's surprising Scala does not support Design-By-Contract.
> Without Design-by-Contract much of the benefit of a well-designed
> strong type system is wasted. What is the motivation for not
> including DbC?
We didn't decide that we would never include DbC. It happens not to be
in the current version of the language, and I don't know of plans to
include it, but this can change.
Michel.
Matthias Zenger
> Assume you have a pool of vehicles, and a pool of drivers.
> Drivers and vehicles must match: if there is a Driver and a Vehicle
> class, and (say) a Captain and a Ship class on one hand and a
> TruckDriver and a Truck class on the other hand, you want to make sure
> that it's impossible to let a Captain drive() a Truck. (Well, actually
> we want to prevent a Captain from doing that unless he also happens to
> be a TruckDriver - some people have more than one kind of license *g*.)
I explained a solution to that problem already in one of my
other posts using the Subject/Observer design pattern. It's
exactly the same thing!
> Ideally, a type system should be able to express this kind of constraint
> statically.
Having a dependent type system, Scala is perfectly suitable for that!
> Now let me raise the bar a little: the type hierarchies aren't entirely
> parallel. For example, implementation details might have made it
> necessary to create two kinds of TruckDriver which both should be able
> to drive Trucks. These TruckDrivers also have additional subclasses that
> drive not only Trucks but SpecialTrucks as well.
> I.e. the type hierarchy would look like this:
Since abstract types can freely depend on each other (i.e. they
can be used as bounds of other abstract types), it should be
possible to model that in Scala in a type-safe way.
== Matthias
Matthias Zenger
> Right, that's why you want a type abstraction facility. As you say,
> there is a trade-off between abstraction and reusability. Hence
> subtyping and type abstraction should be separate but freely composable
> features, giving you a choice. Nominal typing as the default (or even
> sole) approach does not seem superior to me.
It favors safety over reusability. So it's a matter of priorities.
>> Scala offers a very restricted form of structural subtyping
>> through its parametric types (+ variance annotations) and
>> its type refinements.
I forgot to mention compound types. These types are intersections
of object types and there's also a structural subtyping rule
relating such types.
> That was one of the things that was not quite clear to me at first.
> Originally I thought at least traits and compound types would be fully
> structural, while classes aren't - the nominal nature of Java interfaces
> always made them pretty useless in my eyes (they are just a restricted
> form of abstract classes), so I expected something along the lines of ML
> signatures.
No, apart from the exceptions mentioned before, Scala has a
purely nominal type system. Even if you wanted to have structural
conformance rules, it would be difficult to implement that on
top of the Java platform.
> Another thing that puzzled me is that Scala does not seem to support
> higher-order abstract types. Would they cause problems?
We talked about it, because sometimes they can become quite handy.
But since the type system and the implementation of the type checker
is already complicated, we decided not to add anything new in
the next time.
== Matthias
Joachim Durchholz
> Joachim Durchholz wrote:
>
>> Assume you have a pool of vehicles, and a pool of drivers. Drivers
>> and vehicles must match: if there is a Driver and a Vehicle class,
>> and (say) a Captain and a Ship class on one hand and a TruckDriver
>> and a Truck class on the other hand, you want to make sure that
>> it's impossible to let a Captain drive() a Truck. (Well, actually
>> we want to prevent a Captain from doing that unless he also happens
>> to be a TruckDriver - some people have more than one kind of
>> license *g*.)
>
> I explained a solution to that problem already in one of my other
> posts using the Subject/Observer design pattern. It's exactly the
> same thing!
OK.
>> Now let me raise the bar a little: the type hierarchies aren't
>> entirely parallel. For example, implementation details might have
>> made it necessary to create two kinds of TruckDriver which both
>> should be able to drive Trucks. These TruckDrivers also have
>> additional subclasses that drive not only Trucks but SpecialTrucks
>> as well. I.e. the type hierarchy would look like this:
>
> Since abstract types can freely depend on each other (i.e. they can
> be used as bounds of other abstract types), it should be possible to
> model that in Scala in a type-safe way.
Thanks.
Another language on the list of things to learn... don't know whether I
should be happy or unhappy about that ;-)
(It would be nice if Scala were the Language that Ends all Languages...
but that would probably be over-optimistic.)
Burak Emir
Morris Carré wrote:
> Scala has the beauty of a frozen cameleon. A tongue ready to strike.
What a beautiful poetic remark. However I believe Scala is better not
placed in the vicinity of the "animal languages" (CAML,Python) so rather
than a cameleon, rather it should be considered as a consumable product
(Java[=coffee]) that increases productivity.
> I read XML processing being given as an important justification to the
> language.
>
That's right.
> My wishlist therefore would include a rich class of XSLT programs with
> an automatic mapping to and fro equivalent Scala code. A Scala style
> that would compile to XSLT programs that it mimicks, is that thinkable ?
>
Sure. Templates in XSLT are basically a match-expression and a body for
which constructs something out of the matched nodes of the tree. However
the processing model of XSLT is quite restricted.
Instead in Scala you would write functions
// this deals with a sequence of nodes
def transformSeq( xs:scala.xml.Node* ) = { // note the vararg list
for (val x <- xs.elements) {
transform(x)
}
}
// this transforms one node... templates go here
def transform( x:scala.xml.Node ) = x match {
case 'Book( xs @ _ * ) => {
/*process book*/ ...;
transformSeq( xs:_* ); // XXXX
}
case 'Author( firstname, lastname ) => {
/*process author*/ ...;
}
}
transform( scala.xml.nobinding.XML.load("myBibliography.xml") );
/* pretty cool, in'it ? */
where you use match-expressions as patterns and the bodies as bodies.
Moreover, you gain full control over *how* you descend down a tree, or
whether results should be processes again.
There are some tricks though: The line marked XXX calls the upper
transformSeq function. However, that function would be normally called
transformSeq( node1, node2, ... nodek ). To call it by passing a
sequence, you have to "escape" the sequence. that happens by writing
xs:_* (where the xs came out of the pattern match).
Also note that 'Book(...) expands to Symbol("Book", ...). We use the XML
parser included in JDK 1.4 to create functional (immutable) Scala xml
objects (scala.Symbol is a subclass of scala.xml.Node), on which you can
conveniently pattern match.
We are working on convenient and efficient all-match primitives, which
return nodesets similar to XPath expressions, but for most task you get
quite far with what is there already.
> Also, do you believe it feasible to use SVG elegantly, as a graphical
> front-end to Scala, using its XML approach ? SVG clients typically allow
> scripting in Ecmascript and Java, can Scala insert itself through the JVM ?
SVG is *the* prime example where you want a full programming language to
generate results and no twisted XSLT gibberish. However my experience in
the scripting part is limited. If you tell me a client that does this
in an open, standard way (such that I can read documentation), I will
look into and give it a try.
cheers,
Burak
Garry Hodgson
> Morris Carr wrote:
> > Scala has the beauty of a frozen cameleon. A tongue ready to strike.
>
> What a beautiful poetic remark. However I believe Scala is better not
> placed in the vicinity of the "animal languages" (CAML,Python) so rather
> than a cameleon, rather it should be considered as a consumable product
> (Java[=coffee]) that increases productivity.
i see both java and coffee as a way to waste time instead of
getting work done.
----
Garry Hodgson, Technology Consultant, AT&T Labs
Be happy for this moment.
This moment is your life.
Steve Harris
> i see both java and coffee as a way to waste time instead of
> getting work done.
Quite the opposite here where I work. The fun projects are those far
out requests that involve interesting computation alone and can best
be done with a functional language. The more mundane stuff, guis and
web services and database access, is always Java - it's just swimming
upstream to use anything else for us when the tools and libraries are
so developed for it, not to mention the pool of developers are
familiar with it and it doesn't need justifying to any managers.
Nice thing about Scala (and Nice before it) is that since it can call
Java libraries we'll be able to have a mixture of the two worlds now,
I think it's a great strength.
Morris Carré
Hi Burak,
Burak Emir wrote:
> Ciao Morris,
>
> Morris Carré wrote:
>
>> Scala has the beauty of a frozen cameleon. A tongue ready to strike.
>
>
> What a beautiful poetic remark. However I believe Scala is better not
> placed in the vicinity of the "animal languages" (CAML,Python) so rather
> than a cameleon, rather it should be considered as a consumable product
> (Java[=coffee]) that increases productivity.
This is the one thing I can react to, without preparatory work. Problem is I
don't quite see why exactly you say this, whether to invoke the fact that
genuine reticulated Python (of which a 15-m specimen was recently announced)
inhabit Java, ask you what's wrong with animals of stone, etc.
> SVG is *the* prime example where you want a full programming language to
> generate results and no twisted XSLT gibberish.
Currently I use Python to produce pdf, and am looking into SVG (that overall I
find much nicer), but compelling only in the perspective of producing
interactive documents. XSLT... looks like it has got some impetus, would be
just as well if some other language could steal away its user base by
incorporating an isomorphic sublanguage.
> However my experience in
> the scripting part is limited. If you tell me a client that does this
> in an open, standard way (such that I can read documentation), I will
> look into and give it a try.
I'll open my eye for it, and I anticipate I'll end up trying to first find
somebody who has done it with Jython. I promise, well, I promise what I
promise, but in any case I would be just as satisfied to find somebody who'd
have done it in Scala, which is telling I was seduced by the nice docs.
Part of it is that I have used lots of languages, but never used languages
using type-inference to a significant extent. It's the first time I see the
beauty of it, and in my wildest dreams would have that beauty turned
two-dimensional into an elegant graphical environment and language - Escher's
paradise - to produce documents of extended preprint flexibility (another way
to say "limited interactivity"). While Scala has enough to offer as it is, I
believe Logo had one thing right : the idea that "the language to end all
languages" will have to seduce youth to programming with a particular style of
graphics, like mankind seduced itself whole to programming and a whole lot
other things, with euclidean geometry.
But I don't mean turtle graphics at all, yep we agree in the end against
animals ;)
Cheers, MC
--
"If Euclidean Geometry is a Gnu, MS Visual Basic and MS Excel are Hyenas"
Morris Carré
>
> Hi Burak,
>
> Burak Emir wrote:
>
>> Ciao Morris,
>>
>> Morris Carré wrote:
>>
>>> Scala has the beauty of a frozen cameleon. A tongue ready to strike.
>>
>>
>>
>> What a beautiful poetic remark. However I believe Scala is better not
>> placed in the vicinity of the "animal languages" (CAML,Python) so
>> rather than a cameleon, rather it should be considered as a consumable
>> product (Java[=coffee]) that increases productivity.
>
>
> This is the one thing I can react to, without preparatory work. Problem
> is I don't quite see why exactly you say this
Is it by any chance that "animal languages" you mean are like teenage pets ?
IOW that Scala means to be to C++ what Gates meant C++ (and now C#) to be to
Visual Basic ?
So, okay, let's say they should be *two* "languages to end all languages", one
to first seduce the teens with graphics to programming, and the other for the
serious stuff of real workers dealing with business.
So the serious stuff is Money. Would perhaps one of the
not-overly-interested-in-money creators of Scala show us Scala steal *money*
to all other programming languages by incorporating a type hierarchy,
modelling money well enough to serve in practice, but with curious insights
allowing it to achieve at once with the same abstract classes the core of an
Elisa/Parry-sort piece of software modelling "plouto-christian" convictions
well enough to sell as stockmarket anticipation technology module ?
I could believe in the existence of an engineer who has always thought of
money as overly uninteresting engineering, convincing himself that money *can*
in fact be the most interesting of engineering stuff in the form of what's
simpler to model accurately as the core class structure of a computer system
that sells stock-market forecast with an AI listening to talk-shows on TV (and
perhaps radio) to nurture its forecasting contributions.
This would displace at once the profession of traders, like it happened to
other professions, would it not ? :)
Cheers, MC
--
"Jesus with the Cesar Coin, divides Christians"
Joachim Durchholz
> I could believe in the existence of an engineer who has always thought
> of money as overly uninteresting engineering, convincing himself that
> money *can* in fact be the most interesting of engineering stuff [...]
IIRC Simon Peyton-Jones once did a Haskell library for evaluating
financial contracts. That's quite interesting if these contracts are
futures and other stuff the value of which depends on probabilities, or
if the contracts depend on each other.
Again, IIRC, the library was applied against the financial
infrastructure of a company, and they found it's self-referential. It
was one of the companies that went bankrupt recently (Enron I think -
not sure anyway).
Anyway. The library exists, its interface is described in
http://citeseer.nj.nec.com/jones00composing.html , so it should be
possible to write something similar in Scala. And make it available to
all those Java programmers...
There are other interesting applications.
I once was involved in a project for a bank; they wanted a new
accounting engine (for keeping track of credit payment, but the engine
would have served for any accounting task).
An accounting engine (please excuse inadequate financial vocabulary):
* must be able to accept new transactions
* must be unable to erase existing transactions
* must be able to keep sub-accounts (usually not shown but visible on
request)
* must be able to manage arbitrarily complex, per-subaccount rules for
calculating interest rates and for moving amounts between subaccounts
(e.g. for a credit, once per month, an amount equal to the monthly
payment is moved from the "current credit amount" subaccount (nominal
interest rate) to the "overdue amounts" subaccount (punitive interest
rate), on the assumption that the customer is obliged to transfer that
amount to the account)
* must be able to manage rules for splitting up transaction with the
entire account into subtransactions for the subaccounts (pay legal fees
before paying overdue amounts before reducing the remaining debt, for
example)
* must be able to create "correction transactions"; you're not allowed
to undo transactions, but you can make a new transaction that undoes the
effects of a previous one; the art here is that the correction
transaction must adjust the subaccounts so that they get the same values
as when the original transaction was never executed, which will usually
mean that any transactions that happened after the
transaction-to-be-undone must be recalculated, and correction
transaction for these must be done as well
* must be able to manage changes in the rule sets, without interfering
with the correction transaction facility (i.e. if the rules changed a
month ago, and a transaction done a year ago must be undone, the engine
has to apply the old rules for all transactions before flag day and the
new rules for all transactions after flag day)
* subtransactions must be inspectable, and users must be able to
determine why each subtransaction was done
This is quite complex, took several man-months to impelement and test,
and was a general pain in the ass - but it's the kind of things thats
live at the heart of real-world applications.
If you're feeling this isn't complicated, add the requirement that each
subaccount must be able to manage amounts in different currencies, with
exchange rates that vary over time, and have rules for converting
currencies as needed (oh, and have a spread between exchange rates) -
and, again, make sure that correction transactions (a) work and (b) can
be explained to the user.
Umm... throw in legal requirements. There are several ways of
calculating interest, for example; different countries have different
legislation on the issue. (Make this part of the ruleset framework,
you'll get mad otherwise...)
Joachim Durchholz
> Again, IIRC, the library was applied against the financial
> infrastructure of a company, and they found it's self-referential. It
> was one of the companies that went bankrupt recently (Enron I think
> - not sure anyway).
Silly me - I didn't notice the April 1st date... and the URL... oh dear,
oh dear. (Thanks to John Atwood for pointing it out to me.)
Anyway, here's the link: http://www.haskell.org/humor/enron.html
Ketil Malde
Joachim Durchholz <joachim....@web.de> writes:
> Anyway, here's the link: http://www.haskell.org/humor/enron.html
"I'm flattered that my research has finally been of use to someone"
-- Simon P J
LOL!
-kzm
(using GHC all the time, but wondering whether his own work is ever
going to be useful...)
--
If I haven't seen further, it is by standing in the footprints of giants
Christian Szegedy
> Would perhaps one of the
> not-overly-interested-in-money creators of Scala show us Scala steal
> *money* to all other programming languages by incorporating a type
> hierarchy, modelling money well enough to serve in practice, but with
> curious insights allowing it to achieve at once with the same abstract
> classes the core of an Elisa/Parry-sort piece of software modelling
> "plouto-christian" convictions well enough to sell as stockmarket
> anticipation technology module ?
Smoking grass is legal in Swissland, isn't it?
Morris Carré
It isn't particularly legal to propagate the habit, and it is a dwindling
business to advertise for the super-habit of smoking. But you are right, the
contorted phrases of legal language are similar to the contorted phrases of
cannabinic stuport, at least in "Swissland" afaik. There the debate rages on
whether internet-wide public expression of expert opinion about somebody
else's language, should count as legal malice.
Isaac Gouy
-snip-
> Nice thing about Scala (and Nice before it) is that since it can call
> Java libraries we'll be able to have a mixture of the two worlds now,
> I think it's a great strength.
Just in case anyone was confused, Nice is still under active
development:
http://nice.sourceforge.net/index.html
(Maybe the biggest difference between these languages is that Nice
uses multimethods.)
best wishes, Isaac
Christian Szegedy
> (Maybe the biggest difference between these languages is that Nice
> uses multimethods.)
Does nice features partial type inference, type lower and upper bounds,
variance annotations and pattern matching?
Vincenzo aka Nick Name
>
> i see both java and coffee as a way to waste time instead of
> getting work done.
ROTFL :)
V.
Isaac Gouy
type inference - more partial than Scala (at present only method variables)
type lower & upper bounds - yes
variance annotations - not sure that they've been completed
pattern matching - value dispatch with multi methods
Nice is at 0.9.5 working towards a 1.0 release ;-)
Garry Hodgson
> Nice thing about Scala (and Nice before it) is that since it can call
> Java libraries we'll be able to have a mixture of the two worlds now,
> I think it's a great strength.
indeed. the value of java lies in the wealth of libraries available.
having access to that within a reasonable language, is a great
thing. i've had great success using jython this way.
Tim Haynes
> Nice thing about Scala (and Nice before it) is that since it can call
> Java libraries we'll be able to have a mixture of the two worlds now, I
> think it's a great strength.
(just poking my nose in...)
Yup. Great happiness was had when I discovered I could still do
`Class.forName()' - I made a JDBC connection to postgresql the other night,
and used the funky XML syntax to display some metadata. Very pleasant
experience indeed :8)
~Tim
--
Move a mountain / Fill the ground |pig...@stirfried.vegetable.org.uk
Take death on wheels / Re-create the land |http://spodzone.org.uk/