Custom Search
|
Date: December 31, 2005
From: Lex Spoon <lex@xxxxxxxxxxxxx>
Scala Bazaars, sbaz for short, is an experimental system to allow
Scala enthusiasts to share code with each other. It works a lot like
apt or yum, for people familiar with those systems, except that it is
customized for Scala, and that currently all uploads are allowed, just
like on a wiki.
Most package systems attempt to build packages that will work on
arbitrary systems. The Scala Bazaar, to contrast, follows the
strategy of explicitly defining limited "universes" of packages that
are meant to work together; a package outside of its universe is not
useful. This design choice leads to a number of advantages. Google
for "package universes" to read more about it.
To try it yourself, everything you need is on the following page:
http://lamp.epfl.ch/~spoon/sbaz
Basically, you start by downloading a bootstrap tarball. Extracting
it gives you a skeletal directory tree that includes an "sbaz" command
(sbaz.bat for Windows). The sbaz command can be used to download more
packages and to share code with other Scala folks.
This is intended to be a community space, so comments and suggestions
are welcome!
Lex Spoon
Date: December 30, 2005
From: "Vijay Saraswat" <vijay@xxxxxxxxxxxxxxxxx>
A proof would be very welcome!
========================================
It is not possible to write higher-order functors in Scala.
-Moez
Vijay Saraswat wrote:
> I wonder how one would define in Scala the abstract notion of Monad, in a way
> similar to what Liang, Hudak and Jones [POPL95,P.7] claims can be done in
> Gofer:
>
> class Monad m where
> unit:: a -> m a
> bind:: m a -> (a -> m b) -> m b
> map:: (a -> b) -> m a -> m b
> join:: m(m a) -> m a
> map f m = m 'bind' \a -> unit(f a)
> join z = z 'bind' id
>
> (Note that the code in the examples directory of the Scala distribution does
> not define the generic notion of monads, just specific monads.)
>
> One could try:
> trait M[A] {
> def bind[B](k:A => M[B]):M[B];
> def map[B](f:A=>B):M[B]=bind(a=>unit(f(a)));
> }
>
> The probem is unit. It cannot be a method in M[A] because of its type -- it
> actually takes an A as arg and produces an M[A].
> Can one specify such an "abtract" constructor in Scala? (Cant do it in Java.)
>
________________________________________________________________
Sent via the WebMail system at mail.saraswat.org
Date: December 29, 2005
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
I spent some time implementing Paterson and Hinze's Finger Trees in Scala, and I'd welcome any comments the group has. Don't be too harsh; this is the first significant code I've written in Scala :) You can download the source at http://www.soletta.com/index.html. That page also contains links to Paterson's page (http://www.soi.city.ac.uk/~ross/papers/FingerTree.html) with the original Haskell source. Doing the conversion was fairly clean, overall. I decided to stay relatively "functional" for most of it and did the initial implementation inside of an "object" declaration, making case classes where needed. I then split some of the pattern matching out into polymorphic method calls, which should execute very quickly on the Java VM, and moved the case classes out of the object declaration (eliminating the outer class reference). A few notes: - I am still a little hazy on exactly how I can cleanly define "case object" versions of my singleton objects (like Empty) -- the contra/co-variance seems to have defeated me on this point. - Haskell pattern matches on multiple function arguments at once. Achieving the same effect in Scala would require construction of an enclosing object (like Pair or Tuple) that would then be passed to match. I generally reshaped these into outer/inner match statements. - Pay careful attention to the "with" vs. "extends" issue. Using extends when possible prevents bulky duplication in .class files. - I used Streams to "remember" iteration positions as I walk down the tree, so the elements call actually uses a stream underneath. - I avoided using the "Elem" wrapper in the original implementation, as a quick sizeOf function could accomplish the same thing, without requiring the wrapper object. It's also the name of the XML element class :) - No standard trait for immutable sequences exists, yet. One should be defined. I have implemented methods that correspond to Scala's immutable Queue, so using one or the other should not be too onerous. - Writing out One/Two/Three/Four/Node2/Node3 as distinct classes follows the original implementation. It should be benchmarked against an alternate implementation that uses a single class for all of those (possibly with an array underneath). Significant savings in the .class file sizes are possible. - The key to understanding this structure is the Deep class. Deep contains a "nested type" in the Bird/Meertens style, which _enforces_ the balancing characteristics of the structure through the type system. Scala's type system handles this perfectly, and its anonymous function syntax is perfectly suited to creating the reduction functions necessary to bridge the nested type tiers. - JSwat is _exceptionally_ useful for debugging Scala applications at this time. The latest release (3.4, at http://www.bluemarsh.com/java/jswat/) works wonders on Scala code compiled with -g. You can even edit your source right in JSwat, although it can't compile it for you. Ross Judson
Date: December 29, 2005
From: "Moez A. Abdel-Gawad" <moez@xxxxxxxxxxx>
In-reply-to:
<200512290652.AA899481698@xxxxxxxxxxxxxxxxx>
References:
<200512290652.AA899481698@xxxxxxxxxxxxxxxxx>
It is not possible to write higher-order functors in Scala. Vijay Saraswat wrote:
I wonder how one would define in Scala the abstract notion of Monad, in a way similar to what Liang, Hudak and Jones [POPL95,P.7] claims can be done in Gofer: class Monad m where unit:: a -> m a bind:: m a -> (a -> m b) -> m b map:: (a -> b) -> m a -> m b join:: m(m a) -> m a map f m = m 'bind' \a -> unit(f a) join z = z 'bind' id (Note that the code in the examples directory of the Scala distribution does not define the generic notion of monads, just specific monads.) One could try: trait M[A] { def bind[B](k:A => M[B]):M[B]; def map[B](f:A=>B):M[B]=bind(a=>unit(f(a))); }The probem is unit. It cannot be a method in M[A] because of its type -- it actually takes an A as arg and produces an M[A].Can one specify such an "abtract" constructor in Scala? (Cant do it in Java.)
-Moez ====================================================== "The greatest enemy of knowledge is not ignorance. It is the illusion of knowledge" -Anonymous
Date: December 29, 2005
From: "Vijay Saraswat" <vijay@xxxxxxxxxxxxxxxxx>
I wonder how one would define in Scala the abstract notion of Monad, in a way
similar to what Liang, Hudak and Jones [POPL95,P.7] claims can be done in Gofer:
class Monad m where
unit:: a -> m a
bind:: m a -> (a -> m b) -> m b
map:: (a -> b) -> m a -> m b
join:: m(m a) -> m a
map f m = m 'bind' \a -> unit(f a)
join z = z 'bind' id
(Note that the code in the examples directory of the Scala distribution does
not define the generic notion of monads, just specific monads.)
One could try:
trait M[A] {
def bind[B](k:A => M[B]):M[B];
def map[B](f:A=>B):M[B]=bind(a=>unit(f(a)));
}
The probem is unit. It cannot be a method in M[A] because of its type -- it
actually takes an A as arg and produces an M[A].
Can one specify such an "abtract" constructor in Scala? (Cant do it in Java.)
---
...but no-one can stop me from playing cricket. Playing cricket is the ultimate
thing in my life.
Sachin Ramesh Tendulkar
October 1, 2004
On December 10, 2005 Sachin scored his 35th Test century, a world record. My
eye-witness account is at http://www.saraswat.org/iwasthere.html.
________________________________________________________________
Sent via the WebMail system at mail.saraswat.org
Date: December 22, 2005
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
That is pretty cool! The other day I was playing with the Scala
syntax...you can use operator definitions and case classes to make
constructs that look like CLIPS rules:
case class Sibling...
case class Spouse...
case class Brother...
case class Parent...
case class Brother...
case class Sister...
case class Male...
case class Female...
case class Let...
case class Rule {
def ->(block: (ctx: Context) => unit) = ...
}
Rule(Brother('x, 'y))
->
(ctx =>
tell(Male(ctx('y)))
);
Rule(
Spouse('a, 'b),
Brother(null, 'b))
-> (ctx =>
match tell(Female(ctx('a))) {
case Some(fact) => Console.println("Asserted fact " + fact)
case None => Console.println("Fact already present");
});
The idea is to take these rule definitions then walk through them to
build "real" rule objects on the inside, using the symbols to coordinate
variables. I'm curious about how you're going to attack the type
problem.
Scala's syntax is open-ended and frustrating at the same time -- you can
do certain things pretty easily, but convincing the compiler to accept
wilder ideas can be a real chore ;)
RJ
-----Original Message-----
From: Vijay Saraswat [mailto:vijay@xxxxxxxxxxxxxxxxx]
Sent: Thursday, December 22, 2005 6:23 AM
To: scala@xxxxxxxxxxxxxx
Cc: gopalan@xxxxxxxxxx; rjagadeesan@xxxxxxxxxxxxx
Subject: Call/cc in Scala?
I am working on a type-clean embedding of Prolog in Scala (think:
strongly typed Prolog, with typing constructs in Prolog absorbed by
typing constructs in Scala).
To support this goal, I wonder if there are any plans afoot to support
call/cc in Scala.
Best,
Vijay
________________________________________________________________
Sent via the WebMail system at mail.saraswat.org
Date: December 22, 2005
From: "Vijay Saraswat" <vijay@xxxxxxxxxxxxxxxxx>
I see examples/monads in the Scala distribution.
If there is more material available, do let me know...
________________________________________________________________
Sent via the WebMail system at mail.saraswat.org
Date: December 22, 2005
From: "Vijay Saraswat" <vijay@xxxxxxxxxxxxxxxxx>
I am working on a type-clean embedding of Prolog in Scala (think: strongly
typed Prolog, with typing constructs in Prolog absorbed by typing constructs in
Scala).
To support this goal, I wonder if there are any plans afoot to support call/cc
in Scala.
Best,
Vijay
________________________________________________________________
Sent via the WebMail system at mail.saraswat.org
Date: December 19, 2005
From: Sean McDirmid <sean.mcdirmid@xxxxxxx>
In-reply-to:
<43A66BCF.3030505@xxxxxxx>
References:
<17e618080512181312xe52505ao1b90e413eeb858e3@xxxxxxxxxxxxxx> <43A66BCF.3030505@xxxxxxx>
Hi everyone interested in a Scala Eclipse pluginShort answer: we are devoting serious resources to building a good/stable/feature rich Scala plugin and we will have a beta out in January.
Long answer: we are currently in the middle of a complete rewrite of the Scala plugin. The current plugin is a good effort but has too many issues with it to be patched up. Additionally, we are currently in the middle of a migration to a new compiler, so we've started over with the plugin and integrated with our new compiler. Our goal is to provide feature-parity with Java, although this won't happen until sometime after our first release. The plugin is almost ready for a beta of the first release which will occur sometime in January after the holidays. Features confirmed for the first release will include:
* Standard Java editor features such as auto-indent and keyword highlighting.
* True incremental building with conservative dependency management. * Semantic-based syntax highlighting. * Hyperlink navigation (ctrl-click on a symbol, go to its definition).* Type information via text hover (nice feature in a language with type inference).
* Launch support.Some features that will not make it into the first release, but are planned for inclusion in a future release:
* Integrated debugging. * Refactoring.* Continuous semantic highlighting and type checking (in the first release, when editing a scala file, semantic highlighting must be invoked via an explicit action).
* Content assist (related to the previous point).We will try to do a concurrent release of the plugin's source code. If somebody really wants access to the source code for the old Scala plugin, we can probably arrange that, but they are officially deprecated by the new Scala plugin.
Thanks, Sean Eyer Leander wrote:
Hello Eclipse has a view to show error messages / exceptions of plugins: When you are in the Scala Perspective, select Window->Show View->Other in the main menu. In the dialog that appears, select "Error Log" in the "PDE Runtime" Folder. Now every exception thrown by the Scala plugin will result in an entry in that log. You can double click an entry to see the stack trace. Note that this is only for errors in the plugin, not the source code you are developping. By the way, using this technique you can see that the reason the plugin fails with Eclipse 3.1 and beyond is that it calls some private APIs that changed from 3.0 to 3.1 (some GUI component responsible for selecting colors). It would be a quick fix if one had access to the sources... Regards Leander Eyer Harold Mills wrote:I would also like to use the Eclipse plugin, but I have problems using it with Eclipse versions 3.0 and 3.1 on Windows. For some reason a simple "Hello, world!" Scala project doesn't seem to build. I see no error messages (even if I intentionally introduce syntax errors into the source code) and nothing shows up in the project's bin directory. It I compile manually and copy the resulting class files to the bin directory, I can run them by invoking scala.bat as an external tool from Eclipse.Harold Mills
Date: December 19, 2005
From: Eyer Leander <leander.eyer@xxxxxxx>
In-reply-to:
<17e618080512181312xe52505ao1b90e413eeb858e3@xxxxxxxxxxxxxx>
References:
<17e618080512181312xe52505ao1b90e413eeb858e3@xxxxxxxxxxxxxx>
Hello
Eclipse has a view to show error messages / exceptions of plugins:
When you are in the Scala Perspective, select Window->Show View->Other
in the main menu. In the dialog that appears, select "Error Log" in the
"PDE Runtime" Folder.
Now every exception thrown by the Scala plugin will result in an entry
in that log. You can double click an entry to see the stack trace. Note
that this is only for errors in the plugin, not the source code you are
developping.
By the way, using this technique you can see that the reason the plugin
fails with Eclipse 3.1 and beyond is that it calls some private APIs
that changed from 3.0 to 3.1 (some GUI component responsible for
selecting colors). It would be a quick fix if one had access to the
sources...
Regards
Leander Eyer
Harold Mills wrote:
I would also like to use the Eclipse plugin, but I have problems using
it with Eclipse versions 3.0 and 3.1 on Windows. For some reason a
simple "Hello, world!" Scala project doesn't seem to build. I see no
error messages (even if I intentionally introduce syntax errors into the
source code) and nothing shows up in the project's bin directory. It I
compile manually and copy the resulting class files to the bin
directory, I can run them by invoking scala.bat as an external tool from
Eclipse.
Harold Mills
Date: December 18, 2005
From: Harold Mills <harold.mills@xxxxxxxxx>
Date: December 17, 2005
From: "Brian Zhou" <b88zhou@xxxxxxxxxxx>
See attached patch. Regards, -Brian Zhou
doc-reference-ExamplesPart-typo.patch
Description: Binary data
Date: December 16, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<43A1FD12.6040508@xxxxxxx>
References:
<pan.2005.12.14.22.44.45.914731@xxxxxx> <43A12228.2080901@xxxxxxx> <pan.2005.12.15.22.52.33.888299@xxxxxx> <43A1FD12.6040508@xxxxxxx>
On Fri, Dec 16, 2005 at 12:32:34AM +0100, Burak Emir wrote:
> >Constructors and destructors are certainly essential to C++ resource
> >handling. Having a special kind of method, call it destructor or Dispose
> >or whatever, that is guaranteed to be called when a variable goes out of
> >scope is IMHO a good thing since it leads to safer and more concise code.
> >
> Often, I often wished (when translating Java code to Scala) that the
> scope of the try-block would extend over the finally block.
I sense a monad...
class WhenDone[A](x : A, dispose : A => Unit)
{
def map[B](f : A => B) : WhenDone[B] =
try { new WhenDone[B](f(x), a => ()) } finally { dispose(x) }
def filter(f : A => Unit) : WhenDone[A] =
try { f(x); this } catch { case e => dispose(x); throw e; }
def flatMap[B](f : A => WhenDone[B]) : WhenDone[B] =
try { f(x) } finally { dispose(x) }
def foreach(f : A => Unit) : Unit =
try { f(x) } finally { dispose(x) }
}
def whenDone[A](x : A)(dispose : A => Unit) = new WhenDone(x, dispose);
def just[A](x : A) = new WhenDone[A](x, a => ());
So pretty! Sort of...
for(
val x <- whenDone(foo)(.close());
foo.op();
val y <- just(bar)
) ();
Actually, it becomes a bit more practical if we break it a little:
class WhenDone[A](x : A, dispose : A => Unit)
{
def map[B](f : A => B) : B =
try { f(x) } finally { dispose(x) }
def filter(f : A => Unit) : WhenDone[A] =
try { f(x); this } catch { case e => dispose(x); throw e; }
def flatMap[B](f : A => B) : B = map(f);
def foreach(f : A => Unit) : Unit = map(f);
}
-- Jamie Webb
Date: December 15, 2005
From: Burak Emir <Burak.Emir@xxxxxxx>
In-reply-to:
<pan.2005.12.15.22.52.33.888299@xxxxxx>
References:
<pan.2005.12.14.22.44.45.914731@xxxxxx> <43A12228.2080901@xxxxxxx> <pan.2005.12.15.22.52.33.888299@xxxxxx>
Often, I often wished (when translating Java code to Scala) that the scope of the try-block would extend over the finally block.Constructors and destructors are certainly essential to C++ resource handling. Having a special kind of method, call it destructor or Dispose or whatever, that is guaranteed to be called when a variable goes out of scope is IMHO a good thing since it leads to safer and more concise code.
For instance
try{
val x = foo; // can throw exception, or give an input sream
foo.op(); // can throw exception
val y = bar; // can throw
} catch {
...
} finally {
x.close() // would be nice, but: "error, x not found."
}
The problem here is two-fold -- what do you do if the exception is
thrown before some value is initialized (e.g. op() breaks something, so
y is not there yet), and -- how do you specify such a twisted scope rule
in a clear way with few words.
IMHO, getting rid of all the `var x:T = null' statements that are preceding typical try finally blocks would already give quite a tangible benefit without being tied to specific destructor methods.
cheers, Burak
Date: December 15, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
References:
<pan.2005.12.14.22.44.45.914731@xxxxxx> <1134639637.4520.16.camel@xxxxxxxxxxxxxxxx>
On Thu, 15 Dec 2005 10:40:37 +0100, Iulian Dragos wrote:
> As further argument for Burak's post, I think it's quite easy to write a
> 'using' function in Scala:
>
> def using[a <% Disposeable, b](obj: a)(f: a => b) = try {
> f(obj)
> } finally {
> obj.dispose;
> }
>
Scala's expressive power is certainly capable of handling the using
pattern that C# uses but what I had in mind was something like the C++
version of deterministic cleanup. Anyway, thank you very much for this
example.
Kind regards,
Albert
Date: December 15, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
References:
<pan.2005.12.14.22.44.45.914731@xxxxxx> <43A12228.2080901@xxxxxxx>
On Thu, 15 Dec 2005 08:58:32 +0100, Burak Emir wrote: > Why should we add a *language* construct that is somehow tied to the > Dispose method of objects in particular? Since we do not have the notion > of disposable object, it requires adding something to the language, and > this violates our principle of having a core language as small as > possible (but not smaller). (It is possible to find facets of Scala that > show that we deviate from this principle, but I believe we would like to > get rid of those rather than have more of them) It is always a matter of decision whether something belongs to the set of features that one considers essential for a programming language. Almost everything in modern languages is a shortcut somehow anyway. Constructors and destructors are certainly essential to C++ resource handling. Having a special kind of method, call it destructor or Dispose or whatever, that is guaranteed to be called when a variable goes out of scope is IMHO a good thing since it leads to safer and more concise code. Kind regards, Albert
Date: December 15, 2005
From: Iulian Dragos <iulian.dragos@xxxxxxx>
In-reply-to:
<pan.2005.12.14.22.44.45.914731@xxxxxx>
References:
<pan.2005.12.14.22.44.45.914731@xxxxxx>
Hello,
> // C# (using)
> void Transfer() {
> using (MessageQueue source = new MessageQueue("server\\sourceQueue")) {
> String qname = (String) source.Receive().Body;
> using (MessageQueue dest1 = new MessageQueue("server\\" +
> qname),
> dest2 = new MessageQueue("backup\\" + qname )) {
> Message message = source.Receive(); dest1.Send(message);
> dest2.Send(message);
> }
> }
> }
As further argument for Burak's post, I think it's quite easy to write a
'using' function in Scala:
def using[a <% Disposeable, b](obj: a)(f: a => b) = try {
f(obj)
} finally {
obj.dispose;
}
The first argument is the resource (which is 'viewable' as being an
instance of Disposable). The second argument is simply a function which
uses the object.
Here's a simple use-case:
def main(args: Array[String]): Unit = {
using(new MessageQueue) { q =>
q.doSomething;
error("abort");
q.doSomething;
}
}
The output will be:
Doing something risky
We dispose of MessageQueue@fabe9
Exception in thread "main" java.lang.Error: abort
at scala.Predef$.error(Predef.scala:128)
at Main$$anonfun1.apply(mailinglist.scala:22)
at Main$$anonfun1.apply(mailinglist.scala:20)
at Main$.using(mailinglist.scala:14)
at Main$.main(mailinglist.scala:20)
at Main.main(mailinglist.scala)
Here's the full program:
trait Disposeable {
def dispose: Unit;
}
class MessageQueue extends AnyRef with Disposeable {
def dispose = Console.println("We dispose of " + this);
def doSomething = Console.println("Doing something risky");
}
object Main {
def using[a <% Disposeable, b](obj: a)(f: a => b) = try {
f(obj)
} finally {
obj.dispose;
}
def main(args: Array[String]): Unit = {
using(new MessageQueue) { o =>
o.doSomething;
error("abort");
o.doSomething;
}
}
}
Cheers,
Iulian
Date: December 15, 2005
From: Burak Emir <Burak.Emir@xxxxxxx>
In-reply-to:
<pan.2005.12.14.22.44.45.914731@xxxxxx>
References:
<pan.2005.12.14.22.44.45.914731@xxxxxx>
Hello Albert,
1) We do have "finally" in Scala, with the same semantics as Java.
object foo {
def main(args:Array[String]):Unit = {
try {
val x = 3;
} catch {
case ga:Exception =>
} finally {
Console.println("all is fine.");
}
}
}
2) IMHO: Calling "Dispose" for variables in "using" blocks is just
another example of how C# favors programmer convenience over elegance.
Why should we add a *language* construct that is somehow tied to the
Dispose method of objects in particular? Since we do not have the notion
of disposable object, it requires adding something to the language, and
this violates our principle of having a core language as small as
possible (but not smaller). (It is possible to find facets of Scala that
show that we deviate from this principle, but I believe we would like to
get rid of those rather than have more of them)
The C# designers have a different language design in mind, which consists of adding every possible programming shortcut to the language itself.
cheers, Burak Albert Bachmann wrote:
Hi, coming from a C++ background I always enjoyed the beauty of (exception-safe) deterministic cleanup. Java and C# rely on try/finally or using(){} to achieve something similar, although they don't need to do so in order to reclaim memory. Anyway I believe that deterministic cleanup is nice to have for closing files, handling mutex locks etc. and I would like to know if it would be desirable to have this feature in Scala. To illustrate my point, I copy an example here from Herb Sutter's presentation on C++/CLI (the C++ extensions to target the .NET runtime). (You can find the whole presentation here: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf) // C# (Java style) void Transfer() { MessageQueue source = null, dest1 = null, dest2 = null; try { source = new MessageQueue("server\\sourceQueue"); String qname = (String) source.Receive().Body; dest1 = new MessageQueue("server\\" + qname); dest2 = new MessageQueue("backup\\" + qname); Message message = source.Receive(); dest1.Send( message ); dest2.Send( message ); } finally { if (dest2 != null) { dest2.Dispose(); } if (dest1 != null) { dest1.Dispose(); } if (source != null) { source.Dispose(); } } } // C# (using) void Transfer() { using (MessageQueue source = new MessageQueue("server\\sourceQueue")) {String qname = (String) source.Receive().Body; using (MessageQueue dest1 = new MessageQueue("server\\" + qname),dest2 = new MessageQueue("backup\\" + qname )) { Message message = source.Receive(); dest1.Send(message); dest2.Send(message); } } } // C++/CLI void Transfer() { MessageQueue source("server\\sourceQueue"); String^ qname = (String^) source.Receive().Body; MessageQueue dest1("server\\" + qname), dest2("backup\\" + qname); Message^ message = source.Receive(); dest1.Send(message); dest2.Send(message); } "On exit (return or exception) from Transfer, destructible/disposable objects have Dispose implicitly called in reverse order of construction. Here: dest2, dest1, and source. No finalization." AFAIK internally the using(){} directive as well as the C++/CLI version are mapped to try/finally blocks, so it doesn't seem to be a big deal from an implementation point of view. However it makes for nicer and safer code. So, how about adding deterministic cleanup to Scala? Any thoughts? Kind regards, Albert
-- Burak Emir http://lamp.epfl.ch/~emir
Date: December 14, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
Hi,
coming from a C++ background I always enjoyed the beauty of
(exception-safe) deterministic cleanup. Java and C# rely on try/finally or
using(){} to achieve something similar, although they don't need to do so
in order to reclaim memory. Anyway I believe that deterministic cleanup is
nice to have for closing files, handling mutex locks etc. and I would like
to know if it would be desirable to have this feature in Scala.
To illustrate my point, I copy an example here from Herb Sutter's
presentation on C++/CLI (the C++ extensions to target the .NET runtime).
(You can find the whole presentation here:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf)
// C# (Java style)
void Transfer() {
MessageQueue source = null, dest1 = null, dest2 = null;
try {
source = new MessageQueue("server\\sourceQueue");
String qname = (String) source.Receive().Body;
dest1 = new MessageQueue("server\\" + qname);
dest2 = new MessageQueue("backup\\" + qname);
Message message = source.Receive();
dest1.Send( message );
dest2.Send( message );
} finally {
if (dest2 != null) { dest2.Dispose(); }
if (dest1 != null) { dest1.Dispose(); }
if (source != null) { source.Dispose(); }
}
}
// C# (using)
void Transfer() {
using (MessageQueue source = new MessageQueue("server\\sourceQueue")) {
String qname = (String) source.Receive().Body;
using (MessageQueue dest1 = new MessageQueue("server\\" +
qname),
dest2 = new MessageQueue("backup\\" + qname )) {
Message message = source.Receive(); dest1.Send(message);
dest2.Send(message);
}
}
}
// C++/CLI
void Transfer() {
MessageQueue source("server\\sourceQueue");
String^ qname = (String^) source.Receive().Body;
MessageQueue dest1("server\\" + qname), dest2("backup\\" + qname);
Message^ message = source.Receive();
dest1.Send(message);
dest2.Send(message);
}
"On exit (return or exception) from Transfer, destructible/disposable
objects have Dispose implicitly called in reverse order of construction.
Here: dest2, dest1, and source. No finalization."
AFAIK internally the using(){} directive as well as the C++/CLI version
are mapped to try/finally blocks, so it doesn't seem to be a big deal from
an implementation point of view. However it makes for nicer and safer
code. So, how about adding deterministic cleanup to Scala? Any thoughts?
Kind regards,
Albert
Date: December 14, 2005
From: Stéphane Micheloud <stephane.micheloud@xxxxxxx>
In-reply-to:
<761d797b0512120338l73dc26ber@xxxxxxxxxxxxxx>
References:
<761d797b0512120338l73dc26ber@xxxxxxxxxxxxxx>
Alex Ahern wrote:
Hi, I was wondering if anyone had any experience using Scala for programming distributed applications on top of Java RMI? I couldn't find any messages about it but I'm guessing someone has tried...
Yes, I've tried the following 3 ways with different examples: - extends UnicastRemoteObject The remote interface and implementation are written in Java, the client and server are in Scala. - UnicastRemoteObject.exportObject Same as above. - DynStubs (using dynamic proxies from Java 1.5) All sources are written in Scala; currently you get a warning like "Their throws clauses are incompatible." for some synthetic methods added by the Scala compiler.
Thanks, Alex
Bye --Stephane
Date: December 12, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
Since it seems to be a fairly entrenched Scala idiom to use an object with the same name as a class to hold related functions, it is a little unfortunate that it is not possible to create an object and a case class with the same name. Is this restriction definitely necessary? I notice that even though the language spec implies the existence of a symbol named after the case class representing the factory function, this symbol is never actually emitted. So at runtime there seems to be no issue. At compile time obviously it would be necessary to add an implicit 'apply' method to any object named the same as a case class, but that seems fine provided the object and case class are compiled together. And Scala already requires different classes to be compiled simultaneously in many cases, e.g. in order to support type inference. I know it's a fairly minor issue, but it's forcing me to write somewhat uglier code than I'd like at present. -- Jamie Webb
Date: December 12, 2005
From: Alex Ahern <alex.ahern@xxxxxxxxx>
Hi, I was wondering if anyone had any experience using Scala for programming distributed applications on top of Java RMI? I couldn't find any messages about it but I'm guessing someone has tried... Thanks, Alex
Date: December 10, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
Hi all, Since I am running Eclipse-3.1.1 and there are serious problems with the available Scala plugin, i.e. is doesn't work properly, I tried to find the plugin sources, but without luck. Can anyone tell me what is planned for the Eclipse-plugin in the near future and where to find the sources? Thanks! -- Albert
Date: December 08, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx> <20051207022656.GC4678@xxxxxxxxxxxxxxxx> <pan.2005.12.07.08.07.03.70879@xxxxxx> <1133949718.16815.50.camel@xxxxxxxxxxxxxxx> <pan.2005.12.07.19.47.55.263864@xxxxxx> <1133994220.14797.36.camel@xxxxxxxxxxxxxxxxxxxxx>
On Wed, 07 Dec 2005 23:23:40 +0100, Nikolay Mihaylov wrote: > On Wed, 2005-12-07 at 20:47 +0100, Albert Bachmann wrote: >> I wonder what would happen if you choose a different naming scheme for your >> automatic getters/setters, e.g. get_x/set_x. In this case it would be >> possible to override these methods in subclasses as well as in the class >> containing the variable itself. Wouldn't that be useful? > > I really don't see how renaming can change anything. Every access has to > be through the getter/setter, not by direct manipulation of the field. > So for any variable that you declare they will be there even if you > don't need them, as in the example above. Consequently, you cannot write > your own in the same class, whatever the names of the getter and setter > are. I would rather like to have a compiler that doesn't generate them > for private variables but I don't know if this is possible. Maybe with a > special attribute? Yes, I thought there is a way to access variables directly but as your previous comments explained this is not possible due to the use of interfaces by the compiler. Renaming the getters/setters would have helped only if there would be a way to directly assign and refer to variables. > >> OK, using getters/setters without a variable is possible for constant >> values. > > I don't understand how such restriction arises. I think the example > above testifies to the opposite. You can say that I still have some > variable but it's hidded from the clients of the class. Also, it doesn't > have to be implemented like that. Imagine the value is stored in a > database. Or a hardware register. Declaring by hand a getter and a > setter according to the Scala convention provides the *interface* to a > variable. What the compiler does when you you write a var definition is > simply an optimization for the most common case. You are right and I was wrong. :-) >> Since automatic getters and >> setters seem to be required at least because of your use of interfaces I >> understand that they have to stay in some way. While I don't believe they >> are very useful in their current form, I can live with them. ;-) > > So we agree to disagree :) > Well not really. Given the fact that there is no way to directly refer to variables (which I thought would probably exist) and the use of interfaces by the compiler, I understand that the situation has to be the way it is. I just assumed that *if* there is a way of direct access, one could allow for direct overriding of automatic getters/setters within the same class by avoiding identifier ambiguities. I understand that this is not possible and so I join your line of thought from now on ;-) Thanks again for your valuable comments! Kind regards, Albert
Date: December 08, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx> <20051207022656.GC4678@xxxxxxxxxxxxxxxx> <pan.2005.12.07.08.07.03.70879@xxxxxx> <1133949718.16815.50.camel@xxxxxxxxxxxxxxx> <pan.2005.12.07.19.47.55.263864@xxxxxx> <20051207231342.GA21224@xxxxxxxxxxxxxxxx>
On Wed, 07 Dec 2005 23:13:42 +0000, Jamie Webb wrote:
> But that 'x = v' will cause an infinite recursion. So our options are
> to complicate the language by making x special within set_x (a pain if
> set_x has helpers), or by providing some way to specify that we mean
> 'raw' assignment this time (analogous to the 'super' keyword, I
> suppose).
You are correct. I had something like raw assignment in mind, but
finally I agree to the conclusions of you and Nikolay Mihaylov that
synthetic getters/setters are a better solution for Scala given the use
of interfaces by the comnpiler. Coming from a C++/Java background I
expected to see a way to have variables that one can directly refer to and
for which one can implement a set of accessor functions that allow for
convenient syntactic shortcuts.
>
> The approach one would currently take is to rename x, so the class
> instead becomes:
>
> class MyClass {
> private var _x = 0;
> def x = _x;
> def x_=(v : Int) = {
> Console.println("x set to "+v);
> _x = v;
> }
> }
>
> What's wrong with that? Certainly there's a trivial getter in there
> now, but that seems a pretty minor issue. The external behaviour of
> this class is presumably identical to the previous one. What is lost
> in this approach? AIUI it's exactly what one would do in C# as well.
>
Well I simply expected a way to avoid the duplication of getters/setters
for a given variable. I am used to '=' meaning raw assignment and
properties as syntactic sugar.
> But what harm do these synthetic methods do? Their existence in the
> case of private members is completely transparent, and in the case of
> public/protected members, they add functionality by permitting
> overriding.
Yes that's true. Maybe I just needed this conversation for a better
insight. So thank you for your patience and your comments.
Kind regards,
Albert
Date: December 07, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<pan.2005.12.07.19.47.55.263864@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx> <20051207022656.GC4678@xxxxxxxxxxxxxxxx> <pan.2005.12.07.08.07.03.70879@xxxxxx> <1133949718.16815.50.camel@xxxxxxxxxxxxxxx> <pan.2005.12.07.19.47.55.263864@xxxxxx>
On Wed, Dec 07, 2005 at 08:47:59PM +0100, Albert Bachmann wrote:
> Yes, but the limitation, that I can't override the automatic
> getter/setter methods for a variable *within* a class still stands. I
> wonder what would happen if you choose a different naming scheme for your
> automatic getters/setters, e.g. get_x/set_x. In this case it would be
> possible to override these methods in subclasses as well as in the class
> containing the variable itself. Wouldn't that be useful?
How? Let me see if I understand what you're saying. You want to start
off with a class like this:
class MyClass {
var x = 0;
}
And then perhaps add a custom setter that logs changes:
class MyClass {
var x = 0;
def set_x(v : Int) = {
Console.println("x set to "+v);
x = v;
}
}
But that 'x = v' will cause an infinite recursion. So our options are
to complicate the language by making x special within set_x (a pain if
set_x has helpers), or by providing some way to specify that we mean
'raw' assignment this time (analogous to the 'super' keyword, I
suppose).
The approach one would currently take is to rename x, so the class
instead becomes:
class MyClass {
private var _x = 0;
def x = _x;
def x_=(v : Int) = {
Console.println("x set to "+v);
_x = v;
}
}
What's wrong with that? Certainly there's a trivial getter in there
now, but that seems a pretty minor issue. The external behaviour of
this class is presumably identical to the previous one. What is lost
in this approach? AIUI it's exactly what one would do in C# as well.
So whilst I agree that your version is marginally prettier, I think
that benefit is far outweighed by the additional complexity and
potential for bugs.
> > In fact, you don't even have to have a variable to employ
> > getter/setters. If you define a setter method according to the Scala
> > convention, you can invoke it with an assignment syntax. In effect, this
> > gives you .NET-style properties. Not surprisingly, they are also used
> > with the .NET backend to give access to proprties.
>
> OK, using getters/setters without a variable is possible for constant
> values. But .NET allows you to define custom properties within a class
> that handle different states through a variable without an additional set
> of synthetic accessor methods. Properties without variables present only a
> subset of the possiblities .NET-style properties allow.
But what harm do these synthetic methods do? Their existence in the
case of private members is completely transparent, and in the case of
public/protected members, they add functionality by permitting
overriding.
-- Jamie Webb
Date: December 07, 2005
From: Nikolay Mihaylov <nikolay.mihaylov@xxxxxxx>
In-reply-to:
<pan.2005.12.07.19.47.55.263864@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx> <20051207022656.GC4678@xxxxxxxxxxxxxxxx> <pan.2005.12.07.08.07.03.70879@xxxxxx> <1133949718.16815.50.camel@xxxxxxxxxxxxxxx> <pan.2005.12.07.19.47.55.263864@xxxxxx>
On Wed, 2005-12-07 at 20:47 +0100, Albert Bachmann wrote:
> Yes, but the limitation, that I can't override the automatic
> getter/setter methods for a variable *within* a class still stands.
I see. You can still get what you want but you'll have to do by hand
what the compiler does for variables otherwise:
class Foo {
private var _x: Int = _;
def x = _x;
def x_=(x: Int): Unit = {
assert(x > 0);
_x = x;
}
}
Unfortunately, the access to _x will happen through its synthetic
getter/setter which is unwanted level of indirection but the problem is
that the compiler generates them even for private values.
> I wonder what would happen if you choose a different naming scheme for your
> automatic getters/setters, e.g. get_x/set_x. In this case it would be
> possible to override these methods in subclasses as well as in the class
> containing the variable itself. Wouldn't that be useful?
I really don't see how renaming can change anything. Every access has to
be through the getter/setter, not by direct manipulation of the field.
So for any variable that you declare they will be there even if you
don't need them, as in the example above. Consequently, you cannot write
your own in the same class, whatever the names of the getter and setter
are. I would rather like to have a compiler that doesn't generate them
for private variables but I don't know if this is possible. Maybe with a
special attribute?
> OK, using getters/setters without a variable is possible for constant
> values.
I don't understand how such restriction arises. I think the example
above testifies to the opposite. You can say that I still have some
variable but it's hidded from the clients of the class. Also, it doesn't
have to be implemented like that. Imagine the value is stored in a
database. Or a hardware register. Declaring by hand a getter and a
setter according to the Scala convention provides the *interface* to a
variable. What the compiler does when you you write a var definition is
simply an optimization for the most common case.
> But .NET allows you to define custom properties within a class
> that handle different states through a variable without an additional set
> of synthetic accessor methods.
Well, in C# you always have to write the getter and/or setter by hand
*and* define the (private, I guess) field yourself if you need one.
> Properties without variables present only a
> subset of the possiblities .NET-style properties allow.
Once again, I think they are the same. If you write a parameterless
method you have, in effect, a read-only property. If you have the
Scala-style setter it's a write only property. When you have both is
read/write property. What storage/computation you use to obtain or store
the value is, in my opinion, irrelevant.
Maybe I misunderstood sth in you posting but I'm quite confident in what
I wrote because C# properties (.NET provides for a bit more than C#) map
very neatly to Scala. Even indexed properties aren't a problem although
for them we use different "magic" - the one introduced for handling
arrays is Scala.
> Since automatic getters and
> setters seem to be required at least because of your use of interfaces I
> understand that they have to stay in some way. While I don't believe they
> are very useful in their current form, I can live with them. ;-)
So we agree to disagree :)
Cheers
Nikolay
Date: December 07, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx> <20051207022656.GC4678@xxxxxxxxxxxxxxxx> <pan.2005.12.07.08.07.03.70879@xxxxxx> <1133949718.16815.50.camel@xxxxxxxxxxxxxxx>
On Wed, 07 Dec 2005 11:01:58 +0100, Nikolay Mihaylov wrote:
> I'd like to bring some clarity into the naming issue. Given a Scala
> class like
>
> class Test {
> var x: Int = _;
> private var y: Int = _;
> }
>
> the compiler generates the following output (using the -print:era option
> and hand-edited to omit the definitions not pertinent to the discussed
> issue)
>
> interface Test() extends Any() with ScalaObject() {
> def x(): int;
> def x_=(final x$0: int): void;
> def Test$y(): int;
> def Test$y_=(final x$0: int): void;
> }
>
> class Test$class() extends Any() with Test() {
> final private var x$: int = _;
> def x(): int = Test$class.this.x$;
> def x_=(final x$0: int): void = Test$class.this.x$ = x$0;
> final private var y$: int = _;
> final def Test$y(): int = Test$class.this.y$;
> final def Test$y_=(final x$0: int): void = Test$class.this.y$ = x$0;
> }
>
> Apparently, the backup field for a (class level) variable is always the
> name of the variable with '$' at the end. Second, the name of the class
> is used in the mangled name for the accessors of private variables
>
Thanks for this detailed explanation.
>> > Correct. Though I think in principal the compiler could elide these
>> > definitions and use the variable directly if it were private (it
>> > doesn't do this currently; probably there's not much performance to
>> > gain using an inlining JITC).
>>
>> What I fail to see is the reason for automatic getter/setter
>> functions. They are trivial and can't be re-implemented by custom
>> versions. What purpose do they have?
>
> To start with, you can override the setters/getters in a subclass:
>
> class Foo {
> var x: Int = _;
> }
>
>
> class Bar extends Foo {
> override def x_=(x: Int): Unit = {
> assert(x > 0);
> super.x = x;
> }
> }
>
Yes, but the limitation, that I can't override the automatic
getter/setter methods for a variable *within* a class still stands. I
wonder what would happen if you choose a different naming scheme for your
automatic getters/setters, e.g. get_x/set_x. In this case it would be
possible to override these methods in subclasses as well as in the class
containing the variable itself. Wouldn't that be useful?
>
> In fact, you don't even have to have a variable to employ
> getter/setters. If you define a setter method according to the Scala
> convention, you can invoke it with an assignment syntax. In effect, this
> gives you .NET-style properties. Not surprisingly, they are also used
> with the .NET backend to give access to proprties.
OK, using getters/setters without a variable is possible for constant
values. But .NET allows you to define custom properties within a class
that handle different states through a variable without an additional set
of synthetic accessor methods. Properties without variables present only a
subset of the possiblities .NET-style properties allow.
>
> Also, you can have an abstract variable that you implement in a sublass.
> Here's a snippet from the compiler for a small language that we have in
> the lab for teaching purposes:
>
> abstract class Tree {
> var sym: Symbol; // an abstract variable definition
> }
>
> class NoSymbol {
> def sym = error("this node has no symbol");
> def sym_=(s: Symbol) = error("this node has no symbol");
> }
>
> class HasSymbol {
> var sym: Symbol = _;
> }
>
> case class Ident(name: String) extends Tree with HasSymbol;
>
> case class NullLit extends Tree with NoSymbol;
>
> If I haven't yet convinced you how usefull the getter/setter convention
> is, then you should know that it is, in fact, necessary. I think this is
> mostly due to mixin composition but every (class-level) value has to be
> accessed through an interface method. A field cannot be a member of an
> interface that's why we need a getter method (this applies to both var's
> and val's and it let's you override values, not just methods). In
> addition, for variables the interface exposes the setter too.
>
I understand.
> Unfortunately, the mixin issue is a bit beyond my competence and I
> cannot justify it in a more rigorous manner, but there's a reason behind
> every definition generated by the compile. For instance, IIRC, exposing
> the getter/setter for private variables is necesseary in the presence of
> mixin composition. You might think this is a break of encapsulation, and
> if a Scala class is used from Java this is certainly true. But if you
> stick to Scala, the compiler uses a Scala-specific symbol table residing
> in the classfile to preserve the Scala interface of a class with the
> full richness of its type system. Thus, you cannot break encapsulation
> from Scala.
>
> Greetings
>
> Nikolay
Thanks again for your detailed explanations. Since automatic getters and
setters seem to be required at least because of your use of interfaces I
understand that they have to stay in some way. While I don't believe they
are very useful in their current form, I can live with them. ;-)
Kind regards,
Albert
Date: December 07, 2005
From: Nikolay Mihaylov <nikolay.mihaylov@xxxxxxx>
In-reply-to:
<pan.2005.12.07.08.07.03.70879@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx> <20051207022656.GC4678@xxxxxxxxxxxxxxxx> <pan.2005.12.07.08.07.03.70879@xxxxxx>
Hello Albert,
On Wed, 2005-12-07 at 09:07 +0100, Albert Bachmann wrote:
> On Wed, 07 Dec 2005 02:26:56 +0000, Jamie Webb wrote:
> > On Wed, Dec 07, 2005 at 12:43:29AM +0100, Albert Bachmann wrote:
> >>
> >> def x: int;
> >> def x_= (y: int): unit;
> >>
> >> But how are these functions implemented? They clearly can't refer to a
> >> variable 'x' since that would be ambiguous.
> >
> > As it happens, the variable is called MyClass$x$, but that's an
> > implementation detail. The compiler won't let you refer to it by that
> > name.
>
> Thanks. I assumed something like this.
I'd like to bring some clarity into the naming issue. Given a Scala
class like
class Test {
var x: Int = _;
private var y: Int = _;
}
the compiler generates the following output (using the -print:era option
and hand-edited to omit the definitions not pertinent to the discussed
issue)
interface Test() extends Any() with ScalaObject() {
def x(): int;
def x_=(final x$0: int): void;
def Test$y(): int;
def Test$y_=(final x$0: int): void;
}
class Test$class() extends Any() with Test() {
final private var x$: int = _;
def x(): int = Test$class.this.x$;
def x_=(final x$0: int): void = Test$class.this.x$ = x$0;
final private var y$: int = _;
final def Test$y(): int = Test$class.this.y$;
final def Test$y_=(final x$0: int): void = Test$class.this.y$ = x$0;
}
Apparently, the backup field for a (class level) variable is always the
name of the variable with '$' at the end. Second, the name of the class
is used in the mangled name for the accessors of private variables
> > Correct. Though I think in principal the compiler could elide these
> > definitions and use the variable directly if it were private (it
> > doesn't do this currently; probably there's not much performance to
> > gain using an inlining JITC).
>
> What I fail to see is the reason for automatic getter/setter
> functions. They are trivial and can't be re-implemented by custom
> versions. What purpose do they have?
To start with, you can override the setters/getters in a subclass:
class Foo {
var x: Int = _;
}
class Bar extends Foo {
override def x_=(x: Int): Unit = {
assert(x > 0);
super.x = x;
}
}
In fact, you don't even have to have a variable to employ
getter/setters. If you define a setter method according to the Scala
convention, you can invoke it with an assignment syntax. In effect, this
gives you .NET-style properties. Not surprisingly, they are also used
with the .NET backend to give access to proprties.
Also, you can have an abstract variable that you implement in a sublass.
Here's a snippet from the compiler for a small language that we have in
the lab for teaching purposes:
abstract class Tree {
var sym: Symbol; // an abstract variable definition
}
class NoSymbol {
def sym = error("this node has no symbol");
def sym_=(s: Symbol) = error("this node has no symbol");
}
class HasSymbol {
var sym: Symbol = _;
}
case class Ident(name: String) extends Tree with HasSymbol;
case class NullLit extends Tree with NoSymbol;
If I haven't yet convinced you how usefull the getter/setter convention
is, then you should know that it is, in fact, necessary. I think this is
mostly due to mixin composition but every (class-level) value has to be
accessed through an interface method. A field cannot be a member of an
interface that's why we need a getter method (this applies to both var's
and val's and it let's you override values, not just methods). In
addition, for variables the interface exposes the setter too.
Unfortunately, the mixin issue is a bit beyond my competence and I
cannot justify it in a more rigorous manner, but there's a reason behind
every definition generated by the compile. For instance, IIRC, exposing
the getter/setter for private variables is necesseary in the presence of
mixin composition. You might think this is a break of encapsulation, and
if a Scala class is used from Java this is certainly true. But if you
stick to Scala, the compiler uses a Scala-specific symbol table residing
in the classfile to preserve the Scala interface of a class with the
full richness of its type system. Thus, you cannot break encapsulation
from Scala.
Greetings
Nikolay
Date: December 07, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx> <20051207022656.GC4678@xxxxxxxxxxxxxxxx>
On Wed, 07 Dec 2005 02:26:56 +0000, Jamie Webb wrote: > On Wed, Dec 07, 2005 at 12:43:29AM +0100, Albert Bachmann wrote: >> >> def x: int; >> def x_= (y: int): unit; >> >> But how are these functions implemented? They clearly can't refer to a >> variable 'x' since that would be ambiguous. > > As it happens, the variable is called MyClass$x$, but that's an > implementation detail. The compiler won't let you refer to it by that > name. Thanks. I assumed something like this. > >> Now if I want to write my own getter/setter functions, it would be like >> this: >> >> var _x: int = _; >> >> def x: int = _x; >> def x_= (y: int): unit = _x = y; >> >> >> Now it seems as if I have two pairs of getter/setter functions. I can >> either access '_x' through my custom functions or directly. It looks as if >> there must be another automatically generated set of getter/setter >> functions like this: >> >> def _x: int; >> def _x_= (y: int): unit; > > Correct. Though I think in principal the compiler could elide these > definitions and use the variable directly if it were private (it > doesn't do this currently; probably there's not much performance to > gain using an inlining JITC). What I fail to see is the reason for automatic getter/setter functions. They are trivial and can't be re-implemented by custom versions. What purpose do they have? > >> But again this would be ambiguous, so how does this work? > > Why is it ambiguous? The 'actual' variable is now called MyClass$_x$. > Yes, sure. That's why I wrote "would". >> In this context I wondered in my previous message, why the *synthetic* >> methods didn't use overloading since they seem to be redundant when using >> custom methods (which I would prefix with get/set anyway). Maybe I am just >> confusing you since I am already confused to ;-) > > One wouldn't want 'obj.x(5)' and 'obj.x = 5' to mean the same thing. I thought more (Java-like) along the lines of obj.x()/obj.x(5) but I don't argue here. I also believe that get/set-prefixes are more readable. > To start with, it's ugly. Further, consider what happens if x holds > values of type Int => Unit for example. Is obj.x(5) a set, or a get > followed by an apply? The compiler would currently favour the former, > but that's probably not what was meant. > > OTOH I do wonder if getX and setX wouldn't have been better internal > names than x and x_$eq, even though that creates potential name > conflicts, just for the sake of interoperability with the JavaBeans > conventions. I agree. But at the moment I think it would be better to not generate automatic getter/setters or at least not to mention them in the reference manual since I consider this whole issue an implementation detail. For properties I would prefer a variant of getX/setX and allow the clients to write something like obj.x = 5; > > -- Jamie Webb Thanks again! Kind regards, Albert
Date: December 07, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<pan.2005.12.06.23.43.28.739864@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx> <pan.2005.12.06.23.43.28.739864@xxxxxx>
On Wed, Dec 07, 2005 at 12:43:29AM +0100, Albert Bachmann wrote: > Sorry for being unclear about my question. I know about the benefits of > naming conventions, but I am a little confused by the automatically > generated getter/setter functions in Scala. Consider this variable > definition: > > var x: int = _; > > If I understand the reference manual right, this should be equivalent to: > > def x: int; > def x_= (y: int): unit; > > But how are these functions implemented? They clearly can't refer to a > variable 'x' since that would be ambiguous. As it happens, the variable is called MyClass$x$, but that's an implementation detail. The compiler won't let you refer to it by that name. > Now if I want to write my own getter/setter functions, it would be like > this: > > var _x: int = _; > > def x: int = _x; > def x_= (y: int): unit = _x = y; > > > Now it seems as if I have two pairs of getter/setter functions. I can > either access '_x' through my custom functions or directly. It looks as if > there must be another automatically generated set of getter/setter > functions like this: > > def _x: int; > def _x_= (y: int): unit; Correct. Though I think in principal the compiler could elide these definitions and use the variable directly if it were private (it doesn't do this currently; probably there's not much performance to gain using an inlining JITC). > But again this would be ambiguous, so how does this work? Why is it ambiguous? The 'actual' variable is now called MyClass$_x$. > In this context I wondered in my previous message, why the *synthetic* > methods didn't use overloading since they seem to be redundant when using > custom methods (which I would prefix with get/set anyway). Maybe I am just > confusing you since I am already confused to ;-) One wouldn't want 'obj.x(5)' and 'obj.x = 5' to mean the same thing. To start with, it's ugly. Further, consider what happens if x holds values of type Int => Unit for example. Is obj.x(5) a set, or a get followed by an apply? The compiler would currently favour the former, but that's probably not what was meant. OTOH I do wonder if getX and setX wouldn't have been better internal names than x and x_$eq, even though that creates potential name conflicts, just for the sake of interoperability with the JavaBeans conventions. -- Jamie Webb
Date: December 06, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx> <439188DE.4040807@xxxxxxx>
Sorry for being unclear about my question. I know about the benefits of
naming conventions, but I am a little confused by the automatically
generated getter/setter functions in Scala. Consider this variable
definition:
var x: int = _;
If I understand the reference manual right, this should be equivalent to:
def x: int;
def x_= (y: int): unit;
But how are these functions implemented? They clearly can't refer to a
variable 'x' since that would be ambiguous.
Now if I want to write my own getter/setter functions, it would be like
this:
var _x: int = _;
def x: int = _x;
def x_= (y: int): unit = _x = y;
Now it seems as if I have two pairs of getter/setter functions. I can
either access '_x' through my custom functions or directly. It looks as if
there must be another automatically generated set of getter/setter
functions like this:
def _x: int;
def _x_= (y: int): unit;
But again this would be ambiguous, so how does this work?
In this context I wondered in my previous message, why the *synthetic*
methods didn't use overloading since they seem to be redundant when using
custom methods (which I would prefix with get/set anyway). Maybe I am just
confusing you since I am already confused to ;-)
Kind regards,
Albert
Date: December 06, 2005
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
Without too much tweaking I think the Scala compiler could translate
well-formed XML documents into well-formed Scala programs. The idea
here is to be able to create source files that are proper XML documents,
but also fully readable by the Scala compiler. With a well-defined
translation every XML file is also a Scala source file. Entities and
processing instructions can be used to influence how the Scala
translation takes place without violating the validity of the XML
itself.
Below you can see an idea of how this might operate. I've created an
object ("hello") that defines an "apply" method to construct new
instances of the document, given two parameters to substitute.
RJ
/*
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?scala package="com.soletta.hello" object="hello" extends="BaseClass"
?>
<!DOCTYPE SCALA [
<!ENTITY partidentifier '{ partidentifier }' >
<!ENTITY contentidentifier '{ contentidentifier }' >
]>
<hello>
<part id="&partidentifier;">
This is some other &contentidentifier;.
</part>
def main(args: Array[String]) = {
val a = hello("first");
val b = hello("second");
Console.println(a);
Console.println(b);
}
</hello>
*/
package com.soletta.hello;
object hello extends BaseClass {
def apply(partidentifier: String, contentidentifier:
String):scala.xml.Document = {
<hello>
<part id= { partidentifier } >
This is some other { contentidentifier }.
</part>
</hello> };
def main(args: Array[String]) = {
val a = hello("first", "stuff");
val b = hello("second", "payload");
Console.println(a);
Console.println(b);
}
}
class BaseClass {
}
Date: December 03, 2005
From: Eyer Leander <leander.eyer@xxxxxxx>
In-reply-to:
<pan.2005.12.03.00.13.05.824331@xxxxxx>
References:
<pan.2005.12.03.00.13.05.824331@xxxxxx>
Albert Bachmann wrote:
Why is the setter name x_= used instead of just x? Overloading should just work fine here, right?
I guess it's mostly due to enhanced readability:"x_=(3)" indicates clearly that the method is a setter, just "x(3)" does not.
Just like in Java, when you "encapsulate" a field, you use the methods getX() and setX(int), altough you could call both just x() and x(int).
The primary goal of naming conventions is not to use the shortest name possible, but the most readable, since you will spend a lot more time reading and modifing code then to write it.
Regards Leander Eyer
Date: December 03, 2005
From: Albert Bachmann <albert.bachmann@xxxxxx>
Hi,
first of all--let me thank you for this fantastic language. I believe that
Scala is one of the best programming languages around (and certainly the
best JVM language anyway).
Anyway, I would like to know the reasoning behind the particular
implementation of automatic getter/setter methods for variable
definitions. Section 4.2 of the Scala Reference states:
"A variable declaration var x : T is equivalent to declarations of a
getter function x and a setter function x_=, defined as follows:
def x : T ;
def x_= ( y : T ): unit
[...]"
Why is the setter name x_= used instead of just x? Overloading should just
work fine here, right?
Kind regards,
Albert
Date: December 02, 2005
From: Nikolay Mihaylov <nikolay.mihaylov@xxxxxxx>
In-reply-to:
<dmpbv5$6rs$1@xxxxxxxxxxxxx>
References:
<dmpbv5$6rs$1@xxxxxxxxxxxxx>
Hi On Fri, 2005-12-02 at 12:40 +0100, Gabriel Riba wrote: > Hi! > > imports of names in dll's other than ".Net Framework" System.dll are not > recognized when using -target:msil > > the code > > import System.Windows.Forms ; > > gives an scalac error msg: > > Windows is not a member of System. > > although there is a library "System.Windows.Forms.dll" in the %CLR_HOME% > directory. > > How should we specify the .Net classpath equivalent, to specify the dlls or > maybe the type libraries (.tlb's) for a project ? The -r option takes a list of the assembly files. All types used in your program are looked up against the assemblies listed there. The exceptions are scala.dll and mscorlib.dll which are expected to be found in the current working directory. You can, of course, use -r to point to them if they are somwhere else (for these two you can specify just their directory). Also, make sure that you have the latest scala distribution since it no longer needs the Visual J# libraries (vjscor.dll and vkslib.dll) and can even run on Mono. > I am trying to figure out if I can do with scala some code I have seen in > C#. Scala doesn't support the full plethora of .NET features so your milleage may vary. For instance there's no support for events and delegate support is somewhat limited (and not documented). The best source of information on how to use some other .NET features is this page http://scala.epfl.ch/docu/clr/quirks.html It is a bit outdated (mostly with respect to object cloning and the omission of delegates) but (1) it's a good starting point and (2) I will try to refresh it. So stay tuned. Cheers Nikolay
Date: December 02, 2005
From: "Gabriel Riba" <griba2010@xxxxxx>