Nabble - Scala - Debate

Re: override method parameter default value specification must not be allowed

2009-11-08T10:13:41Z

On Sun, 2009-11-08 at 20:25 +0300, Stepan Koltsov wrote:
...

> >>
> >> Figuratively speaking, ideal language has 100 pages specification and
> >> all the best features that can be specified in that 100 pages.
> >
> > Ideally I would replace dedicated XML treatment with a library DSL and
> > objects with java style statics (since static scope is the only thing I
> > use them for). Would take many pages out of specification. But someone
> > found those usefull.
>
> I don't like XML in Scala language too (although I use it).
>
> I don't understand what are you proposing. AFAIU, Scala language
> cannot be used as a good DSL for XML:
>
> ===
> elem("html") {
> elem("body", "background" -> "red") {
> text("hello")
> }
> }
> ===
>
> You meant this? It is too verbose.

I was trying to say, that everyone has different ideas on what should go
into language, and what should stay out. Nevermind, not a very important
topic.

>
> >> Second, current specification restricts method overloading capabilities:
> >>
> >> ===
> >> object A {
> >> def f(x: Int = 1) = 1
> >> def f(x: String, z: Int = 2) = 1
> >> }
> >> ===
> >>
> >> This is not possible because of JVM bytecode generation scheme (name
> >> of default parameter value generator method).
> >>
> >
> >
> > Using the "object A" above as a source why not simply explode everything
> > into overloaded methods when compiling?
> >
> > def f(x : Int) = ...
> > def f() = { f(1); }
> > def f(x : String, z : Int) = ..
> > def f(x : String) = { f(x, 2); }
> >
> > This allows overloading and default value overriding at the same time.
>
> Avoiding X is always a workaround of any problem of X (X = parameter
> default value)

I meant, that compiler should do the explosion. You write code with
parameter default values and compiler explodes it into a set of
overloaded methods. Anyway, bad idea.. This would work badly with named
arguments. For number X of default arguments, number of methods after
explosion would be X! .

Looking at your previous email another approach may work:

===
def connect(String, int) = ...
def connect$params(String, int, parametersMask: Int) =
{ setup parameters; connect(p1, p2); }

obj.connect$params(null, 0, 0);
===

"setup parameters" could take default values from a set of generated
methods where each would provide a default value for one parameter. This
would keep a number of generated methods low, allow named arguments,
overloading and overriding (override generated method for overriden
parameter).

> S.

Linas.

Re: override method parameter default value specification must not be allowed

2009-11-08T09:25:28Z

On Sun, Nov 8, 2009 at 20:07, Linas <vejobrolis@...> wrote:

> On Sun, 2009-11-08 at 19:21 +0300, Stepan Koltsov wrote:
>> On Sun, Nov 8, 2009 at 18:18, Linas <vejobrolis@...> wrote:
>> > IMHO it's always better to have a capability and not need it than to
>> > need a capability and not have it.
>>
>>
>> First, possibility to override default values makes specification larger.
>>
>> Language must be as small as possible. It cannot (and must not)
>> contain all possible features invented in 50 years of programming.
>>
>> Figuratively speaking, ideal language has 100 pages specification and
>> all the best features that can be specified in that 100 pages.
>
> Ideally I would replace dedicated XML treatment with a library DSL and
> objects with java style statics (since static scope is the only thing I
> use them for). Would take many pages out of specification. But someone
> found those usefull.

I don't like XML in Scala language too (although I use it).

I don't understand what are you proposing. AFAIU, Scala language
cannot be used as a good DSL for XML:

===
elem("html") {
elem("body", "background" -> "red") {
text("hello")
}
}
===

You meant this? It is too verbose.

>> Second, current specification restricts method overloading capabilities:
>>
>> ===
>> object A {
>> def f(x: Int = 1) = 1
>> def f(x: String, z: Int = 2) = 1
>> }
>> ===
>>
>> This is not possible because of JVM bytecode generation scheme (name
>> of default parameter value generator method).
>>
>
>
> Using the "object A" above as a source why not simply explode everything
> into overloaded methods when compiling?
>
> def f(x : Int) = ...
> def f() = { f(1); }
> def f(x : String, z : Int) = ..
> def f(x : String) = { f(x, 2); }
>
> This allows overloading and default value overriding at the same time.

Avoiding X is always a workaround of any problem of X (X = parameter
default value)

S.

Re: override method parameter default value specification must not be allowed

2009-11-08T09:07:50Z

On Sun, 2009-11-08 at 19:21 +0300, Stepan Koltsov wrote:

> On Sun, Nov 8, 2009 at 18:18, Linas <vejobrolis@...> wrote:
> > IMHO it's always better to have a capability and not need it than to
> > need a capability and not have it.
>
>
> First, possibility to override default values makes specification larger.
>
> Language must be as small as possible. It cannot (and must not)
> contain all possible features invented in 50 years of programming.
>
> Figuratively speaking, ideal language has 100 pages specification and
> all the best features that can be specified in that 100 pages.

Ideally I would replace dedicated XML treatment with a library DSL and
objects with java style statics (since static scope is the only thing I
use them for). Would take many pages out of specification. But someone
found those usefull.

> Second, current specification restricts method overloading capabilities:
>
> ===
> object A {
> def f(x: Int = 1) = 1
> def f(x: String, z: Int = 2) = 1
> }
> ===
>
> This is not possible because of JVM bytecode generation scheme (name
> of default parameter value generator method).
>
> Third (I said this earlier), current spec makes larger and slower bytecode.
>
> ===
> def connect(host = "localhost", port = 1234) = ...
>
> connect()
> ===
>
> compiled to:
>
> ===
> def connect(Strng, Int) = ...
> def connect$default$1 = "localhost"
> def connect$default$2(String) = 1234
>
> obj.connect(obj.connect$default$1,
> obj.connect$default$2(obj.connect$default$1)).
> ===
>
> Size of both classes (caller and callee) increased by size of two
> string constants"connect$default$1" and "connect$default$2"), caller
> has two extra method call, calee has extra method, JVM consumes more
> memory, inlines fewer and so on.
>
>
> Alternative compilation scheme (that was in the first version of
> specification) compiles "connect" method as:
>
> ===
> def connect(String, int) = ...
> def connect$params(String, int, parametersMask: Int) =
> { setup parameters; connect(p1, p2); }
>
> obj.connect$params(null, 0, 0);
> ===

Using the "object A" above as a source why not simply explode everything
into overloaded methods when compiling?

def f(x : Int) = ...
def f() = { f(1); }
def f(x : String, z : Int) = ..
def f(x : String) = { f(x, 2); }

This allows overloading and default value overriding at the same time.

> But it does not allow (useless and weird) parameter default value overriding.
>
> S.
>
>
> > On Sun, 2009-11-08 at 16:28 +0300, Stepan Koltsov wrote:
> >> Hi,
> >>
> >> while Scala 2.8 is not yet released, I have an addition to SID 1
> >> (named and default args; simplification): disallow default parameter
> >> value specfication in override method.
> >>
> >> I believe, there are no reasons of specifying default value in
> >> override method. I seems to be cool, but is is useless.
> >>
> >> And also, sometimes it is confusing.
> >>
> >> ===
> >> abstract class A {
> >> def connect(port: Int = 12345)
> >> }
> >>
> >> class B extends A {
> >> override def connect(port: Int = 99999) { println("connecting to "
> >> + port); }
> >> }
> >>
> >> val a: A = new B
> >> a.connect()
> >> ===
> >>
> >> "connects" to 99999. However, I expect port value 12345.
> >>
> >> Code above should fail to be compiled.
> >>
> >> In the specification, sentence
> >>
> >> "The subclass can also override default arguments and add new ones to
> >> parameters which don’t have a default in the superclass."
> >>
> >> should be replaced with
> >>
> >> "The overriding method cannot specify any default method parameters,
> >> default values from the base class method are inherited".
> >>
> >> This change will make specification simpler.
> >>
> >> S.
> >
> >
> >

Re: override method parameter default value specification must not be allowed

2009-11-08T08:49:40Z

> The argument that this kind of overriding is broken trivially
> generalises to "subtyping is broken".

I just wanted to write the same. For the same reason one might argue
``if `a' is declared to be of type `A', then it is not desired to behave
like a `B'." If you agree with that, you probably don't like subtyping
and polymorphism at all ...

I think it is a good thing that default args are overridable. This is
perfectly in line with polymorphism.

> I might agree with that.

As my programming experience grew throught the years, I discovered that
I more and more favor composition over inheritance. Complex class
hierarchies may be impressive to others---in general, they make me
suspicious. :) Nonetheless, I'd be interested to hear the reasons, in a
sentence or two, why you are spectical about subtyping as a whole.

---Ph

Re: override method parameter default value specification must not be allowed

2009-11-08T08:38:42Z

On Sun, Nov 8, 2009 at 18:56, Andrew Gaydenko <a@...> wrote:
>> > And, after all, what is that big difference in comparison with val o def
>> > overriding?
>>
>> Method parameter belongs to method of class, val belongs to class.
>> Vals and method parameter defaults are very different things.
>
> Rephrasing: method parameter belongs to method of class, method belongs to
> class, i.e. method parameter belongs to class in total :-)

... and they both belong to universe. But you've asked what is the
difference, and I explained.

S.

Re: override method parameter default value specification must not be allowed

2009-11-08T08:34:06Z

On Sun, Nov 8, 2009 at 18:56, Andrew Gaydenko <a@...> wrote:

Actually, I doubt someone's really going to override parameter default
value (as it makes program harder to understand).

I have an example, where parameter default value overriding maybe
useful (and later I'll show that it is bad use).

===
trait DbConnector {
def conect(host: String, port: Int = 0) // port is database specific
}

class MysqlConnector {
override def connect(host: String, port: Int = 3306) // default port for MySQL
}

class PostgresqlConnector {
override def connect(host: String, port: Int = 5432) // default port
for PostgreSQL
}
===

This seems to be a good example of parameter default value overriding.
But it is not, because I cannot write a class:

===
class MagicDbConnectorProxy { // that delegates to vendor-specific
override def connect(host: String, port: Int = ???) // what value
should I use?
}
===

When parameter default value depends on class type, special marker
(for example, zero) should be used to indicate the default value, like
this:

===
trait DbConnector {
def conect(host: String, port: Int = 0) // port is database specific
}

class MysqlConnector {
override def connect(host: String, port: Int) {
if (port == 0) port = 3306;
...
}
}
===

This is how code should be written even if parameter default value can
be overriden.

IMHO.

S.

Re: override method parameter default value specification must not be allowed

2009-11-08T08:21:26Z

On Sun, Nov 8, 2009 at 18:18, Linas <vejobrolis@...> wrote:
> IMHO it's always better to have a capability and not need it than to
> need a capability and not have it.

First, possibility to override default values makes specification larger.

Language must be as small as possible. It cannot (and must not)
contain all possible features invented in 50 years of programming.

Figuratively speaking, ideal language has 100 pages specification and
all the best features that can be specified in that 100 pages.

Second, current specification restricts method overloading capabilities:

===
object A {
def f(x: Int = 1) = 1
def f(x: String, z: Int = 2) = 1
}
===

This is not possible because of JVM bytecode generation scheme (name
of default parameter value generator method).

Third (I said this earlier), current spec makes larger and slower bytecode.

===
def connect(host = "localhost", port = 1234) = ...

connect()
===

compiled to:

===
def connect(Strng, Int) = ...
def connect$default$1 = "localhost"
def connect$default$2(String) = 1234

obj.connect(obj.connect$default$1,
obj.connect$default$2(obj.connect$default$1)).
===

Size of both classes (caller and callee) increased by size of two
string constants"connect$default$1" and "connect$default$2"), caller
has two extra method call, calee has extra method, JVM consumes more
memory, inlines fewer and so on.

Alternative compilation scheme (that was in the first version of
specification) compiles "connect" method as:

===
def connect(String, int) = ...
def connect$params(String, int, parametersMask: Int) =
{ setup parameters; connect(p1, p2); }

obj.connect$params(null, 0, 0);
===

But it does not allow (useless and weird) parameter default value overriding.

S.

> On Sun, 2009-11-08 at 16:28 +0300, Stepan Koltsov wrote:
>> Hi,
>>
>> while Scala 2.8 is not yet released, I have an addition to SID 1
>> (named and default args; simplification): disallow default parameter
>> value specfication in override method.
>>
>> I believe, there are no reasons of specifying default value in
>> override method. I seems to be cool, but is is useless.
>>
>> And also, sometimes it is confusing.
>>
>> ===
>> abstract class A {
>> def connect(port: Int = 12345)
>> }
>>
>> class B extends A {
>> override def connect(port: Int = 99999) { println("connecting to "
>> + port); }
>> }
>>
>> val a: A = new B
>> a.connect()
>> ===
>>
>> "connects" to 99999. However, I expect port value 12345.
>>
>> Code above should fail to be compiled.
>>
>> In the specification, sentence
>>
>> "The subclass can also override default arguments and add new ones to
>> parameters which don’t have a default in the superclass."
>>
>> should be replaced with
>>
>> "The overriding method cannot specify any default method parameters,
>> default values from the base class method are inherited".
>>
>> This change will make specification simpler.
>>
>> S.
>
>
>

Re: override method parameter default value specification must not be allowed

2009-11-08T08:18:52Z

The argument that this kind of overriding is broken trivially
generalises to "subtyping is broken". I might agree with that, but
given Scala, a language that supports subtyping, this kind of
overriding is no more harmful than any other.

2009/11/8 Andrew Gaydenko <a@...>:

> On Sunday 08 November 2009 18:39:10 Stepan Koltsov wrote:
>> Yes, I know it is 99999, because I know that I called B instance
>> (although I had to read spec). However, I meant the case where type of
>> "a" variable is not known to be B at the call site.
>>
>> ===
>> val a: A = someFunc()
>> a.connect()
>> ===
>
> I think it's matter of taste. To my mind, "someFunc() knows itself" is more
> expectable.
>
>>
>> > And, after all, what is that big difference in comparison with val o def
>> > overriding?
>>
>> Method parameter belongs to method of class, val belongs to class.
>> Vals and method parameter defaults are very different things.
>>
>> S.
>>
>
> Rephrasing: method parameter belongs to method of class, method belongs to
> class, i.e. method parameter belongs to class in total :-)
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

Re: override method parameter default value specification must not be allowed

2009-11-08T07:56:58Z

On Sunday 08 November 2009 18:39:10 Stepan Koltsov wrote:
> Yes, I know it is 99999, because I know that I called B instance
> (although I had to read spec). However, I meant the case where type of
> "a" variable is not known to be B at the call site.
>
> ===
> val a: A = someFunc()
> a.connect()
> ===

I think it's matter of taste. To my mind, "someFunc() knows itself" is more
expectable.

>
> > And, after all, what is that big difference in comparison with val o def
> > overriding?
>
> Method parameter belongs to method of class, val belongs to class.
> Vals and method parameter defaults are very different things.
>
> S.
>

Rephrasing: method parameter belongs to method of class, method belongs to
class, i.e. method parameter belongs to class in total :-)

Re: override method parameter default value specification must not be allowed

2009-11-08T07:51:54Z

On 08/11/2009 16:39, Stepan Koltsov wrote:
> On Sun, Nov 8, 2009 at 18:16, Andrew Gaydenko<a@...> wrote:
> ===
> val a: A = someFunc()
> a.connect()
> ===

Contrary to what you think, I believe that this is the perfect use case
for default parameter value override.
With or without default parameter override, you can change the port
value, for example:

override def connect(port: Int) {
//ignore the arg and connect to my default port, because it's my
//specifity of being a B
println("connecting to " + myDefaultPort)
}

If you use a B for your A, it means that you want the specialized
behaviour that comes with B, and perhaps it has nothing to do with the
parent behaviour, but that's nothing new.

--
Francois Armand

Re: override method parameter default value specification must not be allowed

2009-11-08T07:39:10Z

On Sun, Nov 8, 2009 at 18:16, Andrew Gaydenko <a@...> wrote:

>> And also, sometimes it is confusing.
>>
>> ===
>> abstract class A {
>> def connect(port: Int = 12345)
>> }
>>
>> class B extends A {
>> override def connect(port: Int = 99999) { println("connecting to "
>> + port); }
>> }
>>
>> val a: A = new B
>> a.connect()
>> ===
>>
>> "connects" to 99999. However, I expect port value 12345.
>>
>> Code above should fail to be compiled.
>
> Hm.. I would expect 99999 as long as new B is creating. Do you say 'new B'
> contract (the way an instance is created) must depend on left side?

Yes, I know it is 99999, because I know that I called B instance
(although I had to read spec). However, I meant the case where type of
"a" variable is not known to be B at the call site.

===
val a: A = someFunc()
a.connect()
===

> And, after all, what is that big difference in comparison with val o def
> overriding?

Method parameter belongs to method of class, val belongs to class.
Vals and method parameter defaults are very different things.

S.

Re: override method parameter default value specification must not be allowed

2009-11-08T07:18:34Z

IMHO it's always better to have a capability and not need it than to
need a capability and not have it.

Linas.

On Sun, 2009-11-08 at 16:28 +0300, Stepan Koltsov wrote:

> Hi,
>
> while Scala 2.8 is not yet released, I have an addition to SID 1
> (named and default args; simplification): disallow default parameter
> value specfication in override method.
>
> I believe, there are no reasons of specifying default value in
> override method. I seems to be cool, but is is useless.
>
> And also, sometimes it is confusing.
>
> ===
> abstract class A {
> def connect(port: Int = 12345)
> }
>
> class B extends A {
> override def connect(port: Int = 99999) { println("connecting to "
> + port); }
> }
>
> val a: A = new B
> a.connect()
> ===
>
> "connects" to 99999. However, I expect port value 12345.
>
> Code above should fail to be compiled.
>
> In the specification, sentence
>
> "The subclass can also override default arguments and add new ones to
> parameters which don’t have a default in the superclass."
>
> should be replaced with
>
> "The overriding method cannot specify any default method parameters,
> default values from the base class method are inherited".
>
> This change will make specification simpler.
>
> S.

Re: override method parameter default value specification must not be allowed

2009-11-08T07:16:06Z

On Sunday 08 November 2009 16:28:27 Stepan Koltsov wrote:

Hm.. I would expect 99999 as long as new B is creating. Do you say 'new B'
contract (the way an instance is created) must depend on left side?

And, after all, what is that big difference in comparison with val o def
overriding?

override method parameter default value specification must not be allowed

2009-11-08T05:28:27Z

Hi,

while Scala 2.8 is not yet released, I have an addition to SID 1
(named and default args; simplification): disallow default parameter
value specfication in override method.

I believe, there are no reasons of specifying default value in
override method. I seems to be cool, but is is useless.

And also, sometimes it is confusing.

===
abstract class A {
def connect(port: Int = 12345)
}

class B extends A {
override def connect(port: Int = 99999) { println("connecting to "
+ port); }
}

val a: A = new B
a.connect()
===

"connects" to 99999. However, I expect port value 12345.

Code above should fail to be compiled.

In the specification, sentence

"The subclass can also override default arguments and add new ones to
parameters which don’t have a default in the superclass."

should be replaced with

"The overriding method cannot specify any default method parameters,
default values from the base class method are inherited".

This change will make specification simpler.

S.

Re: Microsoft and Scala .net

2009-11-05T10:01:35Z

Right, sorry I should be a bit more specific.

Partest compiles and runs tests, and compares the output (either from the compiler
or from the program) with a corresponding ".check" file. It does so in parallel.

There are (mainly) four kinds of tests:
- neg: should not compile (compare compiler output with check file)
- pos: should compile (no output)
- run: compile, run, compare output with check file
- jvm: like run, but expected to work only on jvm

before partest, we used a bash script called "scalatest". This script actually supported
testing the .NET backend. I don't know how well it worked. The script was removed in
revision 17595,
http://lampsvn.epfl.ch/trac/scala/changeset/17595/scala/trunk/test

Thanks: Lukas

On Thu, Nov 5, 2009 at 18:47, Josh Cough <joshcough@...> wrote:

partest runs tests right? lets say we put something together that also runs those same tests. what percentage of them would still be usable? i looked through it briefly a few times and seems like we could probably make use of a good chunk of the tests.

On Thu, Nov 5, 2009 at 11:42 AM, Lukas Rytz <lukas.rytz@...> wrote:

On Thu, Nov 5, 2009 at 16:43, Josh Cough <joshcough@...> wrote:
I'd be very interested in putting together a test suite for Scala.NET. My first question would be, what prevents the existing tests from running? I'd like to hope that many of the test would be salvageable.

First problem is that partest uses actors, and they don't exist in Scala.NET :)

On Thu, Nov 5, 2009 at 8:03 AM, Lukas Rytz <lukas.rytz@...> wrote:
The .NET version is very much work in progress. The .NET backend is mostly
working, so you can compile to MSIL (using a compiler running on the JVM).

We're working on bootstrapping the compiler on .NET.

A central issue we're having right now is that there is no test suite (zero tests)
for Scala.NET, so we don't really know what the quality of the generated code is.

Help from the community would be very much appreciated!

Lukas

On Thu, Nov 5, 2009 at 12:36, Marcus Downing <marcus@...> wrote:

As spotted on Planet Scala, Erik Engbrecht recently tweeted:

".NET version of #scala sponsored by Microsoft probably sometime next year
#scalaliftoff"

and

"EPFL almost has a #scala compiler that runs natively on .net and should
have it by the end of the year #scalaliftoff"

...but I've seen nothing more about it, anywhere. Is this real or just
random electron chatter? Is it supposed to be still under wraps?
--
View this message in context: http://old.nabble.com/Microsoft-and-Scala-.net-tp26211695p26211695.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

Re: Microsoft and Scala .net

2009-11-05T09:42:43Z

On Thu, Nov 5, 2009 at 16:43, Josh Cough <joshcough@...> wrote:

I'd be very interested in putting together a test suite for Scala.NET. My first question would be, what prevents the existing tests from running? I'd like to hope that many of the test would be salvageable.

First problem is that partest uses actors, and they don't exist in Scala.NET :)

On Thu, Nov 5, 2009 at 8:03 AM, Lukas Rytz <lukas.rytz@...> wrote:
The .NET version is very much work in progress. The .NET backend is mostly
working, so you can compile to MSIL (using a compiler running on the JVM).

We're working on bootstrapping the compiler on .NET.

A central issue we're having right now is that there is no test suite (zero tests)
for Scala.NET, so we don't really know what the quality of the generated code is.

Help from the community would be very much appreciated!

Lukas

On Thu, Nov 5, 2009 at 12:36, Marcus Downing <marcus@...> wrote:

As spotted on Planet Scala, Erik Engbrecht recently tweeted:

".NET version of #scala sponsored by Microsoft probably sometime next year
#scalaliftoff"

and

"EPFL almost has a #scala compiler that runs natively on .net and should
have it by the end of the year #scalaliftoff"

...but I've seen nothing more about it, anywhere. Is this real or just
random electron chatter? Is it supposed to be still under wraps?
--
View this message in context: http://old.nabble.com/Microsoft-and-Scala-.net-tp26211695p26211695.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

Re: Microsoft and Scala .net

2009-11-05T06:03:33Z

The .NET version is very much work in progress. The .NET backend is mostly
working, so you can compile to MSIL (using a compiler running on the JVM).

We're working on bootstrapping the compiler on .NET.

A central issue we're having right now is that there is no test suite (zero tests)
for Scala.NET, so we don't really know what the quality of the generated code is.

Help from the community would be very much appreciated!

Lukas

On Thu, Nov 5, 2009 at 12:36, Marcus Downing <marcus@...> wrote:

As spotted on Planet Scala, Erik Engbrecht recently tweeted:

".NET version of #scala sponsored by Microsoft probably sometime next year
#scalaliftoff"

and

"EPFL almost has a #scala compiler that runs natively on .net and should
have it by the end of the year #scalaliftoff"

...but I've seen nothing more about it, anywhere. Is this real or just
random electron chatter? Is it supposed to be still under wraps?
--
View this message in context: http://old.nabble.com/Microsoft-and-Scala-.net-tp26211695p26211695.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

Microsoft and Scala .net

2009-11-05T03:36:50Z

As spotted on Planet Scala, Erik Engbrecht recently tweeted:

".NET version of #scala sponsored by Microsoft probably sometime next year #scalaliftoff"

and

"EPFL almost has a #scala compiler that runs natively on .net and should have it by the end of the year #scalaliftoff"

...but I've seen nothing more about it, anywhere. Is this real or just random electron chatter? Is it supposed to be still under wraps?

Re: Adding Bagwell's Trie to the collection: benchmarks

2009-11-04T22:08:10Z

In the meantime before 2.8 stabilized, I know that Daniel Spiewak reimplemented the Clojure PersistentHashMap in Scala, this might be useful to you for the time being:

http://github.com/djspiewak/scala-collections

Caveat Emptor: I haven't tried it out so I am not sure it works correctly / what the performance is like.

Ben

Ismael Juma wrote:

Michel Alexandre Salim <michael.silvanus <at> gmail.com> writes:
> I suppose we can't use the Clojure code, since it's more strictly
> licensed (EPL rather than BSD) -- and, alas, the internal interfaces
> are different anyway.

As I understand, Tiark is working with Phil on improved versions so that's
another reason too.

Best,
Ismael

Re: Polymorphic extension methods

2009-11-04T05:17:29Z

Hello,

> When I was a "pure OO programmer", I would have considered the
> pattern matching option evil ;) Now, I would try very hard to ensure
> that I only draw shapes (using your example) in one place. I would
> now have one place to maintain changes and one place where all the
> drawing logic exists. Localizing this logic is better for modularity
> than spreading it around in each Shape definition. That's a major
> plus, IMHO.
That's why I think "polymorphic extension method" may convince even
pure OO programmers that a more functional approach doesn't have to be
evil ;). I agree that it's good to draw shapes only in one place, but
nothing stops you from writing methods for drawing different shapes in
one file. I was even writing that the extension methods would be a
good way to group methods with a similar responsibility in one place
(so group methods by what they do, not which class they belong to). If
you write a pattern matching method to draw the shapes, then if the
actual drawing takes more than 3 lines of code, you'll probably
extract two private methods (drawCircle & drawSquare) anyway.
Otherwise, the method will quickly get very long.

--
Adam

Re: Polymorphic extension methods

2009-11-04T05:11:49Z

> That is true; it is up to DataBinding[Transaction] to define implicit
> DataBinding[AuthTransaction] and DataBinding[CaptureTransaction] in
> scope and then have some means that can be used to recover the runtime
> type - either a match on a sealed class or (in the case where your
> entities are persisted by Hibernate and may be proxied) using a
> Visitor.
These two (matching/visitor) are exactly the two solutions that I
described in my post. They work, although if used repeatedly they
produce quite a lot of "noise" (boilerplate code; especially the
visitors).

> If you've discarded static type information along the way somewhere,
> you've got to use a runtime technique to recover it. A polymorphic
> method won't help you. If you have all the static type information you
> need, then the correct implicit will be selected (well, so long as
> DataBinding is invariant in its type parameter.)
Sure. But you could also imagine having some syntactic sugar which
does that for you.

--
Adam

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-04T03:27:50Z

> AFAIK, the whole purpose of his Zero was being able to generalize
> the implementation of certain parameterized classes.

Perhaps something like scala.Monoid could fill the same role? a
generalised zero is a whole lot more useful if there's a generalised
'plus' to use with it... although:

> The limited resources of the core team may be better applied to the
> compiler rather than the contentious task of 'haskell-ification' of
> the standard lib.

Certainly. I wasn't suggesting that the standard library necessarily
needs these things in it. Merely that, where the standard library DOES
choose to implement algebraic abstractions, it takes some care to get
them right, so they can be built upon cleanly by others.

In particular I wasn't suggesting borrowing wholesale from haskell -
haskell gets quite a few things wrong, eg its 'Num' class.

Cheers
-Matt

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-04T03:26:03Z

For the record, I used the term "haskell-ification" in reference to Ben's suggested direction, not in specific reference to the all-to-brief appearance of Zero, of which I was rather fond. :)

-jason

On Wed, Nov 4, 2009 at 11:59 AM, Daniel Sobral <dcsobral@...> wrote:

If you think Paul was in any way pursuing a "haskell-ification" of anything, I have some bottom land you might be interested in...

AFAIK, the whole purpose of his Zero was being able to generalize the implementation of certain parameterized classes.

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-04T02:59:39Z

If you think Paul was in any way pursuing a "haskell-ification" of anything, I have some bottom land you might be interested in...

AFAIK, the whole purpose of his Zero was being able to generalize the implementation of certain parameterized classes.

On Wed, Nov 4, 2009 at 5:11 AM, Jason Zaugg <jzaugg@...> wrote:

The good news is that you can layer these on top of Scala with the Scalaz library. Runar and Tony describe the relationship here, in response to an earlier message from Ben: http://groups.google.com/group/scalaz/browse_thread/thread/b686d161d9e5cd78/35ecff815569a2a1?hl=en&lnk=gst&q=implicit#35ecff815569a2a1

The limited resources of the core team may be better applied to the compiler rather than the contentious task of 'haskell-ification' of the standard lib.

-jason

On Wed, Nov 4, 2009 at 4:04 AM, Ben Hutchison <brhutchison@...> wrote:

I'd like to see the Scala library design ruthlessly mine Haskell for
its ideas and wisdom, especially with respect to algebraic structures.

For an example of Haskell Wisdom, see the Typeclassopedia in:
http://www.haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf

-Ben

--
Daniel C. Sobral

Veni, vidi, veterni.

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-04T01:39:08Z

This is all fine and dandy, but how about Money?

On Wed, Nov 4, 2009 at 8:11 AM, Jason Zaugg <jzaugg@...> wrote:

The good news is that you can layer these on top of Scala with the Scalaz library. Runar and Tony describe the relationship here, in response to an earlier message from Ben: http://groups.google.com/group/scalaz/browse_thread/thread/b686d161d9e5cd78/35ecff815569a2a1?hl=en&lnk=gst&q=implicit#35ecff815569a2a1

The limited resources of the core team may be better applied to the compiler rather than the contentious task of 'haskell-ification' of the standard lib.

-jason

On Wed, Nov 4, 2009 at 4:04 AM, Ben Hutchison <brhutchison@...> wrote:

I'd like to see the Scala library design ruthlessly mine Haskell for
its ideas and wisdom, especially with respect to algebraic structures.

For an example of Haskell Wisdom, see the Typeclassopedia in:
http://www.haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf

-Ben

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-03T23:11:37Z

The good news is that you can layer these on top of Scala with the Scalaz library. Runar and Tony describe the relationship here, in response to an earlier message from Ben: http://groups.google.com/group/scalaz/browse_thread/thread/b686d161d9e5cd78/35ecff815569a2a1?hl=en&lnk=gst&q=implicit#35ecff815569a2a1

The limited resources of the core team may be better applied to the compiler rather than the contentious task of 'haskell-ification' of the standard lib.

-jason

On Wed, Nov 4, 2009 at 4:04 AM, Ben Hutchison <brhutchison@...> wrote:

I'd like to see the Scala library design ruthlessly mine Haskell for
its ideas and wisdom, especially with respect to algebraic structures.

For an example of Haskell Wisdom, see the Typeclassopedia in:
http://www.haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf

-Ben

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-03T21:02:15Z

Scala 2.8 has some other Type relate to algebraic structures in my opinion, e.g. Fractional, Integral, Numeric ,(Addable ?)..

Matthew Willson-3 wrote:

Spotted this in the recent scala additions:

http://lampsvn.epfl.ch/trac/scala/changeset/19291/scala/trunk/src/library/scala/Zero.scala

My thoughts:

- To call something a 'Zero' on a particular type, doesn't make much
sense (and isn't much use) without the context of a (typically
associative) binary operation on that set which it's a zero of
- 'Identity' is a better term than 'zero' in this general context, in
particular it may be a left identity or a right identity or both
- There's a name for sets with an identity and an associative binary
operation - a Monoid
- Monoids would actually be pretty useful to have in the library, and
I think each of these implicit Zero instances should rather be a
Monoid instance, supplying the binary operation as well as its identity

Found an example of a monoid class (and implicit monoids) mentioned
here: http://www.scala-lang.org/node/114

So yeah, just wondering what the rationale here was, and more
generally, what the philosophy is about modelling algebraic structures
in the scala library.

Personally I'd love to see a really well-engineered set of classes for
algebraic structures made available, and it pains me a bit to see odds
and ends of mathematical structure done in the library in a rather ad-
hoc way which could be quite hard to make really consistent / coherent
further down the road once everyone's relying on them. This is what
happened with haskell, which is rather a sad tale. There are a few
alternative Preludes available for haskell now which 'do it right',
but at the cost of replacing the core of the standard library everyone
else is using.

Happy to help out here if anyone feels code would speak louder than
words :)

-Matt

My scala solutions for Project Euler problems: Click here

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-03T19:04:44Z

On Wed, Nov 4, 2009 at 12:58 PM, Matthew Willson
<matthew.willson@...> wrote:
> So yeah, just wondering what the rationale here was, and more generally,
> what the philosophy is about modelling algebraic structures in the scala
> library.
>
> Personally I'd love to see a really well-engineered set of classes for
> algebraic structures made available, and it pains me a bit to see odds and
> ends of mathematical structure done in the library in a rather ad-hoc way
> which could be quite hard to make really consistent / coherent further down
> the road once everyone's relying on them.

I agree with the above.

I'd like to see the Scala library design ruthlessly mine Haskell for
its ideas and wisdom, especially with respect to algebraic structures.

For an example of Haskell Wisdom, see the Typeclassopedia in:
http://www.haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf

-Ben

Re: Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-03T18:58:48Z

On Wed, Nov 04, 2009 at 01:58:05AM +0000, Matthew Willson wrote:
> Spotted this in the recent scala additions:

You'll be happy to know that as is the rule more than the exception with
me lately, I'll be reverting it in the near future.

--
Paul Phillips | These are the climbs that apply men's soles.
Everyman |
Empiricist |
pp: i haul pills |----------* http://www.improving.org/paulp/ *----------

Thoughts on scala.Zero, and algebraic structures in the scala library

2009-11-03T17:58:05Z

Spotted this in the recent scala additions:

http://lampsvn.epfl.ch/trac/scala/changeset/19291/scala/trunk/src/library/scala/Zero.scala

My thoughts:

- To call something a 'Zero' on a particular type, doesn't make much
sense (and isn't much use) without the context of a (typically
associative) binary operation on that set which it's a zero of
- 'Identity' is a better term than 'zero' in this general context, in
particular it may be a left identity or a right identity or both
- There's a name for sets with an identity and an associative binary
operation - a Monoid
- Monoids would actually be pretty useful to have in the library, and
I think each of these implicit Zero instances should rather be a
Monoid instance, supplying the binary operation as well as its identity

Found an example of a monoid class (and implicit monoids) mentioned
here: http://www.scala-lang.org/node/114

So yeah, just wondering what the rationale here was, and more
generally, what the philosophy is about modelling algebraic structures
in the scala library.

Personally I'd love to see a really well-engineered set of classes for
algebraic structures made available, and it pains me a bit to see odds
and ends of mathematical structure done in the library in a rather ad-
hoc way which could be quite hard to make really consistent / coherent
further down the road once everyone's relying on them. This is what
happened with haskell, which is rather a sad tale. There are a few
alternative Preludes available for haskell now which 'do it right',
but at the cost of replacing the core of the standard library everyone
else is using.

Happy to help out here if anyone feels code would speak louder than
words :)

-Matt

Re: Polymorphic extension methods

2009-11-03T09:01:07Z

When I was a "pure OO programmer", I would have considered the pattern matching option evil ;) Now, I would try very hard to ensure that I only draw shapes (using your example) in one place. I would now have one place to maintain changes and one place where all the drawing logic exists. Localizing this logic is better for modularity than spreading it around in each Shape definition. That's a major plus, IMHO.

My point is that you should first try to avoid needing the extension methods, as they add some complexity and increase the testing and maintenance burden. If you can't avoid extension methods, then one of the discussed solutions should be fine.

dean

On Sat, Oct 31, 2009 at 12:25 PM, Adam Warski <adam@...> wrote:

Hello,

I've been wondering recently about if and how to implement, as I call them, "polymorphic" extension methods.
In Scala, extension methods are normally implemented using implicit conversions. However there's a major limitation - implicits don's support polymorphism.

My use case is following: I have some data-only objects, lets say they represent shapes. They may either use inheritance (e.g. Square extends Shape, Circle extends Shape), implement common interfaces (Square implements Shape, Circle implements Shape), or traits. They are manipulated and persisted (for example mapped with Hibernate to a DB) in a backend system.

Now I want to display the shapes on different frontend systems (using Swing, a web app, etc). So for each of the shapes I need an implementation of a draw() method (quite obviously, a square is drawn differently than a circle ;) ). I don't want to store frontend-specific code in the backend (so that rules out simply putting the method in the class), and I want each frontend to have a different implementation (in Swing you draw differently than in a web app).

I think the best way to do this in Scala now is to use pattern matching, so in each of the frontends I would have a draw(Shape) method like this:
def draw(shape: Shape) = shape match {
case s: Square => drawSquare(s)
case c: Circle => drawCircle(c)
case ...
}

def drawSquare(s: Square) = ...
def drawCircle(s: Square) = ...

in some (probably artificially created) wrapper class "Drawer" or sth like this.

Having to write the pattern matching, and to create a wrapper class to hold those draw methods isn't quite as nice as just having the methods in the classes. But why not do that? If we could extend a class with a method (also an abstract method!) than the example above would just be:
extend class Shape with { def draw }
extend class Square with { def draw = ... }
extend class Circle with { def draw = ... }

The extend class ... with { } syntax is completely from the top of my head, and probably a better one can be devised. But I hope that the idea is clear :)

That way, it would be possible to have simple data classes, group different functionalities in the extension methods and still have OO benefits. Also it could be a good compromise between the supporters of anemic models and DDD (rich models). And it would prevent bloating classes with lots of methods for all kinds of uses that an object may have.

How to implement this? To make it simple for the beginning, let's say that we require that only sealed case classes can use extension methods. The compiler (or rather - an appropriate compiler plug-in) would first collect information on which classes define extension methods. Having that information, we can check that if abstract extension methods are used, every subclass provides an implementation (because we require only sealed classes, we know all subclasses). Then, the methods and their usages may be re-written to the wrapper-class+case-matching+methods-per-implementation form as above.

What do you think? Do you see any problems/holes/etc? :) Maybe it has been discussed before (although my search of Scala's mailing lists didn't reveal anything)?

Adam

--
Dean Wampler
coauthor of "Programming Scala" (O'Reilly)
- http://programmingscala.com

twitter: @deanwampler, @chicagoscala
Chicago-Area Scala Enthusiasts (CASE):
- http://groups.google.com/group/chicagoscala
- http://www.meetup.com/chicagoscala/ (Meetings)
http://www.linkedin.com/in/deanwampler
http://www.polyglotprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

Re: Polymorphic extension methods

2009-11-03T08:24:30Z

On Tue, Nov 3, 2009 at 8:45 AM, Adam Warski <adam@...> wrote:

> Hello,
>
>>
>> I use a technique that uses an implicit method (to supply the
>> conversion) with an implicit parameter (which supplies the rendering
>> logic) to achieve what (I think) you're talking about here. I did it
>> in the context of Lift bindings, but I think that the technique is
>> generally applicable.
>
> But if I understand correctly it doesn't support polymorphic definitions of
> bind().
> If you wanted to have for example different implementations for bind() for
> AuthTransaction and CaptureTransaction, then even if you implemented
> DataBinding[AuthTransaction] and DataBinding[CaptureTransaction], still the
> DataBinding[Transaction] would be used (when doing
> order.transactions.flatMap(_.bind(txnTemplate)).toSeq), as statically that's
> what the compiler knows about the type, and so applies the appropriate
> implicits it can find.
>
> Adam
>

That is true; it is up to DataBinding[Transaction] to define implicit
DataBinding[AuthTransaction] and DataBinding[CaptureTransaction] in
scope and then have some means that can be used to recover the runtime
type - either a match on a sealed class or (in the case where your
entities are persisted by Hibernate and may be proxied) using a
Visitor.

If you've discarded static type information along the way somewhere,
you've got to use a runtime technique to recover it. A polymorphic
method won't help you. If you have all the static type information you
need, then the correct implicit will be selected (well, so long as
DataBinding is invariant in its type parameter.)

Kris

Re: Polymorphic extension methods

2009-11-03T07:45:02Z

Hello,

>
> I use a technique that uses an implicit method (to supply the
> conversion) with an implicit parameter (which supplies the rendering
> logic) to achieve what (I think) you're talking about here. I did it
> in the context of Lift bindings, but I think that the technique is
> generally applicable.

But if I understand correctly it doesn't support polymorphic
definitions of bind().
If you wanted to have for example different implementations for bind()
for AuthTransaction and CaptureTransaction, then even if you
implemented DataBinding[AuthTransaction] and DataBinding
[CaptureTransaction], still the DataBinding[Transaction] would be used
(when doing order.transactions.flatMap(_.bind(txnTemplate)).toSeq), as
statically that's what the compiler knows about the type, and so
applies the appropriate implicits it can find.

Adam

Re: Polymorphic extension methods

2009-11-02T17:51:22Z

On Sat, Oct 31, 2009 at 12:25 PM, Adam Warski <adam@...> wrote:

> Hello,
>
> I've been wondering recently about if and how to implement, as I call them,
> "polymorphic" extension methods.
> In Scala, extension methods are normally implemented using implicit
> conversions. However there's a major limitation - implicits don's support
> polymorphism.
>
> My use case is following: I have some data-only objects, lets say they
> represent shapes. They may either use inheritance (e.g. Square extends
> Shape, Circle extends Shape), implement common interfaces (Square implements
> Shape, Circle implements Shape), or traits. They are manipulated and
> persisted (for example mapped with Hibernate to a DB) in a backend system.
>
> Now I want to display the shapes on different frontend systems (using Swing,
> a web app, etc). So for each of the shapes I need an implementation of a
> draw() method (quite obviously, a square is drawn differently than a circle
> ;) ). I don't want to store frontend-specific code in the backend (so that
> rules out simply putting the method in the class), and I want each frontend
> to have a different implementation (in Swing you draw differently than in a
> web app).
>
> I think the best way to do this in Scala now is to use pattern matching, so
> in each of the frontends I would have a draw(Shape) method like this:
> def draw(shape: Shape) = shape match {
> case s: Square => drawSquare(s)
> case c: Circle => drawCircle(c)
> case ...
> }
>
> def drawSquare(s: Square) = ...
> def drawCircle(s: Square) = ...
>
> in some (probably artificially created) wrapper class "Drawer" or sth like
> this.
>
> Having to write the pattern matching, and to create a wrapper class to hold
> those draw methods isn't quite as nice as just having the methods in the
> classes. But why not do that? If we could extend a class with a method (also
> an abstract method!) than the example above would just be:
> extend class Shape with { def draw }
> extend class Square with { def draw = ... }
> extend class Circle with { def draw = ... }
>
> The extend class ... with { } syntax is completely from the top of my head,
> and probably a better one can be devised. But I hope that the idea is clear
> :)
>
> That way, it would be possible to have simple data classes, group different
> functionalities in the extension methods and still have OO benefits. Also it
> could be a good compromise between the supporters of anemic models and DDD
> (rich models). And it would prevent bloating classes with lots of methods
> for all kinds of uses that an object may have.
>
> How to implement this? To make it simple for the beginning, let's say that
> we require that only sealed case classes can use extension methods. The
> compiler (or rather - an appropriate compiler plug-in) would first collect
> information on which classes define extension methods. Having that
> information, we can check that if abstract extension methods are used, every
> subclass provides an implementation (because we require only sealed classes,
> we know all subclasses). Then, the methods and their usages may be
> re-written to the wrapper-class+case-matching+methods-per-implementation
> form as above.
>
> What do you think? Do you see any problems/holes/etc? :) Maybe it has been
> discussed before (although my search of Scala's mailing lists didn't reveal
> anything)?
>
> Adam
>

I use a technique that uses an implicit method (to supply the
conversion) with an implicit parameter (which supplies the rendering
logic) to achieve what (I think) you're talking about here. I did it
in the context of Lift bindings, but I think that the technique is
generally applicable.

Blogged about it here:
http://logji.blogspot.com/2009/09/composable-bindings-in-lift.html

Kris

Re: Re: Polymorphic extension methods

2009-11-02T06:19:55Z

On Saturday October 31 2009, Jesper Nordenberg wrote:
> See:
>
> http://www.scala-lang.org/docu/files/IC_TECH_REPORT_200433.pdf
>
> for a solution to exactly this problem (it's called the expression
> problem).
>
> /Jesper Nordenberg

If you're willing to sacrifice static type safety within for the
relevant portion of your program that, Kiama's [1] Rewriter module is a
very elegant solution to this class of problems. It completely
separates reusable traversal control combinators (which it supplies in
abundance) from the logic of your program specific to the types it
operates upon. The only real restriction is that it is limited to case
classes (more precisely, subclasses of Product).

[1] <http://code.google.com/p/kiama/>

Randall Schulz