gmane.comp.lang.scala.debate

Better Tuple Syntactic Sugar

wookietreiber — 2012-05-26T10:38:34

Hi there,

I'd like Scala to better support tuple syntax, consider the following
example:


Instead of being able to that, currently I have to go the long way:


It is already possible with for expressions:


So why not with e.g. functions like in the example above?

Default-Value Type Parameter and Named Type Arguments

Chris Hodapp — 2012-05-26T04:11:06

There is demand, it would seem, from myself and from others for supporting 
named type arguments and default values for type parameters. I was asked by 
Chris Vogt (my GSOC mentor) whether I would be willing to look at 
implementing these features, and I said I would.

I plan to write a SIP that specifies how these should work, should an 
agreement on the issue be reached here.

My current idea for basic naming support is something like this for naming 
would look something like:
"""
class A[T, U]

val a1 = new A[Int, String]         // Call normally
val a2 = new A[T = Int, U = String] // Provide names to make meaning clear
val a3 = new A[U = String, T = Int] // Reverse names, still works
val a4 = new A[Int, U = String]     // Provide as many position-resolved 
arguments as desired before providing name-resolved arguments
"""

My current idea for basic default support would look like:
"""
class B[T = String]

val b1 = new A[String] // Explicitly provide the default type
val b2 = new A[Int]    // Provide a different type
val b3 = new A         // Infers B[String] instead of B[Nothing]
"""

Of course, they should be able to interact, since they have synergistic 
benefits:
"""
class C[T = String, U = Int]

val c1 = new String[U = Char, T = Char]  // Can use the names
val c4 = new String[String, U = Int]     // Still uses positional 
resolution until named arguments start
val c5 = new String[U = Char]            // Default: T = String
val c6 = new String[Char]                // Default: U = Int
"""

It should also be possible to use default parameter values with type 
bounds, variance annotations, etc.:
"""
class D[T = List[_] <: Traversable[_]]

val d1 = new D[Seq[_]] // Works because Seq[_] <: Traversable[_]
val d2 = new D         // T defaults to List[_]
val d3 = new D[Int]    // Error


class E[+T = Traversable[_]]

val e1 = new T                       // T defaults to Traversable[_]
val e2: E[Traversable] = new E[List] // Variance
val e3: E[Any] = new E               // Right side T defaults to 
Traversable[_], but it doesn't matter, since it's cast to Any
"""

Note that even though all the examples so far have been with classes, 
methods should also work.

What I would most appreciate is help in identifying important nonobvious 
cases and deciding what to do in them.

One that I know about:
"""
def mimic[T = Any](x: T): T = x

mimic("abc") // What's mimic's return type?
"""

It is not entirely clear what we should do here. Normally (without a 
specified default value), we would infer that T is String in this case. 
However, it is not clear whether this should take precedence over the 
default value. I currently think that the default values should have the 
lowest-possible precedence, as this seems to be the idea that has been used 
with default parameter values for regular method parameters. In short, I 
think we should go ahead and infer String in this case. However, I'm not 
particularly attached to the idea of it working in this way if there is 
some good reason that it would be less surprising to have more complicated 
precedence rules.

Parentheses instead of curly-braces around case-lambdas?

Luke Vilnis — 2012-05-25T12:25:56

Apologies if this has been asked before - I did a brief search and couldn't
find anything.

Would it be possible to allow case-lambdas within parentheses (instead of
braces) in a future version of Scala?

The idea is just to allow "(case pat (if cond)? => expr)" to mean the same
as "{ case pat (if cond)? => expr }", at least when inside an argument list
(but hopefully anywhere inside parentheses). So we could write things like:

Map("asd" -> 123).map(case (k, v) => (k, v + 1))

or even lose the parentheses when in a multi-argument list:

multiArgumentMethod(case (x, hd::tl) => x::tl, case (x, Nil) => x::Nil)

or whatever. For ambiguity's sake, we couldn't allow it outside of
parentheses, and maybe not outside of argument lists at all (but I don't
think we'd have to go that far):

val f = case (a, b) => a + b // No!
val f = (case (a, b) => a + b) // Maybe?

As far as I can see, this shouldn't be ambiguous in the grammar, but I
could definitely be missing something.

Thanks,
Luke

P.S. Justification for additional syntax: I find it kind of irritating that
every lambda syntax besides case-lambdas allows both paren- and
brace-surrounded forms. Additionally, you can't use curly braces to
surround multiple-argument-lists. This creates a nasty tension where it
seems like there is no way to have consistent code style when passing
arguments in Scala - sometimes you need curly braces, sometimes you need
parens, which requires (the horror!) _thinking_. Obviously I would prefer
to minimize thinking as much as possible (I'm sort of kidding but I have
found that the extra cognitive load of all the formatting decisions you're
allowed to make in Scala can be distracting, even though I appreciate the
flexibility).

Mailing list reminder: Scala-debate

Scala Mailing Lists — 2012-05-21T13:32:02

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-debate/subscribe
or send an email to scala-debate+unsubscribe< at >googlegroups.com

Thank you!
The Scala Team

Object identity

Paul — 2012-05-20T20:45:20

You can use the `eq` operator for checking for object identity with any 
AnyRef object in Scala.

Wouldn’t it be more elegant to rename this to `is`. This way, you could 
write more readable code

    if (a is b) ...

What do you think?

Regards, Paul

Could the Manifest generation be implemented by a macro?

Andrés Testi — 2012-05-18T19:49:59

Currently the compiler does magic to generate Manifests on demand:

def foo[T](implicit Manifest[T]) = ...

foo[FooClass]<<Compiler generates a Manifest for FooClass in the foo 
invocation point>>

Could this compiler task, be replaced by a macro in a future version of 
Scala?

object Predef{
  
  implicit def manifest[T]: Manifest[T] = macro manifestImpl

  def manifestImpl[T](c: Context): Expr[Manifest[T]] = {
    // generate a Manifest for T
    ...
  }
}

Regards.

- Andrés

right-biasing Either

Jason Zaugg — 2012-05-14T07:08:34

(A follow-up from ticket SI-5793. [1])

Apologies in advance to any left-handers out there.

I propose (not that I'm the first) to right-bias Either. Concretely,
this means we would add map/flatMap etc directly to Either, rather
than going through RightProjection. RightProjection could probably
deprecated.

Is there any previous discussion on this? Any arguments against?

-jason

[1] https://issues.scala-lang.org/browse/SI-5793

[scala-humor] Symbols in Scala (Was: How to represent Symbol? Was: compile scala-compiler: done!

Som Snytt — 2012-05-13T19:56:46

If the Scala team were The Avengers, which superhero would each of them be?

To encourage free creativity, there are no strictures: it's not necessary
that Martin is Nick Fury, or that Heather has to be Black Widow.  Wikipedia
says Black Widow has:

psychological conditioning that suppresses her memory of true events as

I think that applies to anyone who has looked at a bug report.

Certainly, the following would explain how Martin was able to play an
important role in ancient tech like Java as well as future tech like Scala:

Fury takes a special medication called the Infinity Formula that halted his

As a nod to tail recursion, our Nick Fury takes Ouroboros Juice.  Same
formula, different flavor.  (Now with Vitamin Trampoline!)

Apparently, it's also OK to create new superpersonae as warranted:

The rotating roster has become a hallmark of the team, although one theme

Bonus points for identifying the former villains!

I know I'm not alone in saying: Thank-you, Team Scala, wherever you are!

---------- Original message ----------
From: martin odersky <martin.odersky< at >epfl.ch>
Date: Mon, May 7, 2012 at 12:15 PM
Subject: Re: [scala-internals] How to represent Symbol? Was: compile
scala-compiler: done!
To: scala-internals< at >googlegroups.com


On Mon, May 7, 2012 at 8:00 PM, Paul Phillips <paulp< at >improving.org> wrote:

Experiences with SIP-18

Rex Kerr — 2012-05-08T15:12:10

I decided to give 2.10 M3 a try and see how SIP-18 affected my code; I
tried compiling one of my most heavily-used sets of code (library +
applications).

First, I noticed dozens and dozens of implicit conversion methods where
instead of writing def whatever(jlc: JavaLibClass) ... I would enrich
.whatever onto that class.  In 2.10 I'd use implicit classes instead for a
majority of these (probably 80%--actually, I'd use an even lighter weight
extension method syntax if I could), so I just turned on
-language:implicitConversions and forgot about them.

Then I found a dozen or so places where the compiler had unhelpfully
decided to generate structural types instead of using an anonymous class;
there were zero cases where the structural typing was the right thing for
the compiler to do in the first place, but I was grateful that it at least
told me what it had done so I could fix it.  After fixing these, no
warnings remained.

There were another dozen or so postfix op warnings.  One was just a
trailing method name that could have had a dot instead (style would
arguably be better).  The rest were all because I use postfix mathematical
operators for clarity at times:
  n!    // factorial
  i++   // Increment on a mutable incrementer class
  c~    // Conjugate of complex number
SIP-18 is really not helping make the code clear here.  Is there any chance
symbolic method names can be excepted from the rule?  The main drawback
right now for doing this is that one has to be careful because postfix ops
do not obey precedence rules--maybe that could be fixed?  Or is this in the
language spec?  (I.e. a + b* means (a+b)* not a+(b*).)

I also got a half dozen higher kinded types warnings, all in cases where
it's absolutely necessary (as far as I have been able to determine) to
enrich library collections methods.  If anyone can write a guide on how to
work generically with collections (including collections of collections,
for things like groupBy and transpose), preserving type along the way,
_without_ needing higher-kinded types, I would appreciate it.  In any case,
having warnings over code that was tricky to get right the first time as
some sort of safety mechanism for newbies doesn't seem logical to me.

I didn't run into dynamics or existentials or macros in this code base.

Anyway, I was in theory not a fan before, and now in practice I am also not
a fan.  On balance, SIP-18 adds to my programming burden while encouraging
me to write worse code, though I admit that in some cases it does help me
avoid gotchas with the current implementation of the compiler.

  --Rex

P.S. The warnings on classes in package objects should perhaps be in SIP-18
also, or turnable off by some other mechanism.  It's much the same case as
postfix ops--use at your own risk, be aware that it doesn't work as well as
you might wish it did.

< at >transient object.

Aleksey Nikiforov — 2012-05-08T05:14:35

I was expecting a nested "< at >transient object" to work or to generate an
error. Instead the compiler silently accepted the annotation and then
simply ignored it.
I think there is a good use case to allow nested transient objects.
However, if there are objections against it, the compiler should generate
an error or at least a warning.

Test code:

object ExpMain {

  def main(args: Array[String]) {
    import java.io._

    val test = new TransientTest
    test.nested.value = 1
    test.transientNested.value = 1

    val bytes = new ByteArrayOutputStream
    val out = new ObjectOutputStream(bytes)
    out.writeObject(test)
    out.close()
    val in = new ObjectInputStream(new
ByteArrayInputStream(bytes.toByteArray))
    val restored = in.readObject.asInstanceOf[TransientTest]

    println("nested.value equal: " + (test.nested.value ==
restored.nested.value))
    println("transientNested.value equal: " + (test.transientNested.value
== restored.transientNested.value))
  }
}

class TransientTest extends Serializable {
  object nested extends Serializable { var value = 0 }
  < at >transient object transientNested extends Serializable { var value = 0 }
}

Macros vs string interp

Ken Scambler — 2012-05-07T15:09:47

I used to be sceptical of macros in Scala, and pine for string
interpolation.  However, the more I read and experiment with macros, the
more useless string interpolation looks.  Macros are a perfect fit for the
language: simple, elegant, powerful, and orthogonal.  String interpolation
appears to fail on these counts.

SIP-11 goes further than a simple s".." syntax to avoid backwards-compat
problems, and adds a whole new concept to the language: a "string prefix"
concept, which can be extended ad hoc by users.  Originally this had many
good use-cases beyond simple interpolation -- statically checked XML, JSON,
and quasiquoting for macros.

The thing is, the discovery of reify() makes all of these advanced use
cases completely redundant.  In his Scala days keynote, Martin notes that
the scala"..." literal string wasn't very interesting any more, because of
macros -- doesn't the same apply to the other examples?  Why have a feature
that gives you xml"$foo" when you can already do xml("$foo") or "$foo".xml
with macros?  It's a completely unnecessary design choice to foist on a
programmer, especially when orthogonality and minimalism are such important
principles for the language.

If we only take simple interpolation, a small and unnecessary notational
convenience is all of a sudden trying to pay for a whole new concept and
syntax pattern.  It does save keystrokes though...

"Hello "+username"
s"Hello $username"

... sometimes.  And even this can be eliminated with macros (if I'm
understanding them correctly). Consider:

"Hello $username".interp
"<html><body><h1>$title</h1></body></html>".interp.xml

Am I missing something?  String interpolation looks complex,
non-orthogonal, un-Scalalike and doesn't pay it's bills.

A "memoized" modifier for function caching proposal

Nikita Volkov — 2012-05-04T11:45:36


Memoization is an optimization technique when function evaluation results 
get cached by the set of passed parameters. This allows to evaluate the 
function only at the first time it is called with a specific set of 
arguments and return the cached results on all the consecutive calls with 
the same set of arguments.

You can think of it as of a more general lazy that also distinguishes the 
parameters. Thus memoization on functions with no arguments, such as memoized 
def functionWithNoParameters: String will have absolutely the same effect 
as lazy val functionWithNoParameters: String.
Some Use Cases1. Functions with heavy calculations

    memoized def calculateSomething(a: Int, b: Int): String = {
      // some heavy calculations take place here
    }

    calculateSomething(1, 2)    // since it's the first time the function is called with 
                                // parameters `(1, 2)` it will actually evaluate, then
                                // it will store the result in cache and return this result

    calculateSomething(1, 2)    // since the function has already been called with this
                                // set of parameters it will quickly just fetch a result 
                                // from the underlying cache, and no actual evaluation will
                                // take place

    calculateSomething(1, 3)    // will calculate again, since yet there's no record for 
                                // a `(1, 3)` arguments set in cache yet

2. Implicits keeping context or state

    //  the following will always return the same instance of `ListWrapper` per each list
    memoized implicit def listWrapper[T](list: List[T]) = new ListWrapper(list)

    class ListWrapper(source: list) {
      lazy val cachedPermutations = list.permutations
    }

    List(1, 3, 4, 4, 4, 3, 3).cachedPermutations  // will calculate
    List(1, 3, 4, 4, 4, 3, 3).cachedPermutations  // will fetch the result from cache

A sample implementation

memoized def resolveSomething(a: Int, b: Int): String =
  a.toString + b.toString

This would generate a code similar to the following:

private val resolveSomethingCache = collection.mutable.Map[(Int, Int), String]()
def resolveSomething(a: Int, b: Int) =
  try resolveSomethingCache((a, b))
  catch {
    case _ => {
      val result = {
        //  actual implementation relies here:
        a.toString + b.toString
      }
      resolveSomethingCache.update((a, b), result)
      result
    }
  }

Please note that in the implementation above I didn't take multithreading 
into account.

I'm not sure about the correct procedure to make it go into the actual 
proposal. On the SIP documentation I've seen a recommendation to discuss it 
here. Just in case, I've also posted an appropriate issue on the tracker: 
https://issues.scala-lang.org/browse/SI-5741

Example code: A toString method with a formatstring as an argument (pimp-the-library)

Ko Stoel — 2012-05-03T20:09:50

Hi,

I wanted an extra toString method with a formatstring as argument. Below 
the code :

//kos:  tested with Scala IDE for Eclipse 
2.1.0.nightly-2_10-201204300848-ba52ed6
object MyMain extends App {
  // making the toString method somewhat more versatile
  // the  'implicit class' construct for such a pimp-my-library
  // should rather be used, I believe
  implicit def more_toString_methods(x: Any): {
    def toString(formatstr: String): String
  }
  = new {
    def toString(formatstr: String): String = formatstr.format(x)
  }

  // testing it
  val tx=3456
  
  println(123456.toString)
  // output: 123456
  println(123456.toString("Hello  %,d   "))
  // output: Hello  123.456 
  println("Er was eens Scala".toString)
  // output: Er was eens Scala
  println(s"there $tx".toString("Hi %s, ") + "how" + 
"wonderfullyisdit".toString(" %-10.10s"))
  // output: Hi there 3456, how wonderfull
}

kind regards,
ko stoel [NL]

Scala >= 2.9 and mockito

Johannes Rudolph — 2012-05-03T14:48:15

Just wanted to share a recent experience how a subtle change in
compilation strategy can lead to problems.

Starting with Scala 2.9 it seems to be impossible to properly mock
classes extending traits with mockito. That's because mockito won't
mock bridge methods for some reason. After some digging I found out
that the only difference seems to be that starting with Scala 2.9
forwarder methods to trait implementations are marked with
`ACC_BRIDGE`.

http://code.google.com/p/mockito/issues/detail?id=340

Maybe it's mockito's fault. Just wanted to put that on record here as well.

Where does partest put its output?

Geraint — 2012-04-30T11:08:14

Using partest to run a bunch of scala tests retsults in output that looks 
like this...

Testing individual files
testing: [...]/files/run/bugs2087-and-2400.scala                      [  
OK  ]

When tests fail, you get [FAILED] instead of [  OK  ].

How do I find out how a test has failed? There's not much I can do with 
just [FAILED]. Are there any log files?

Using embedded SQL in Scala

Kangmo Kim — 2012-04-29T18:04:01

Hi, 
I am wondering if somebody can give me early feedback on my open source 
project ToySQL.(http://toysql.codeplex.com/).
 
ScalaQuery is great, but learning curve is high. So I decided to implement 
a DSL which looks similar to SQL. 
 
I would like to collect early feedbacks. Is a DSL like below something 
necessary for Scala programmers?
 
object TestSQL extends ToySQL {
def main(args:Array[String]) = {
EXEC (CREATE TABLE 'emp ('eno INTEGER, 'dno INTEGER, 'name CHAR(10)))
EXEC (INSERT INTO 'emp VALUES(1, 1, "kmkim"))
EXEC (INSERT INTO 'emp VALUES(2, 2, "jdlee"))
EXEC (INSERT INTO 'emp VALUES(3, 1, "kumdory"))
EXEC (INSERT INTO 'emp VALUES(4, 1, "wegra"))

EXEC (SELECT ('eno, 'name) FROM 'emp ORDER_BY ('eno ASC)) 
EXEC (SELECT ('eno, 'name) FROM 'emp ORDER_BY ('eno DESC)) 

EXEC (DELETE FROM 'emp WHERE 'eno < 3) 
EXEC (SELECT ('eno, 'name) FROM 'emp) 
EXEC (SELECT ('eno, 'name) FROM 'emp WHERE 'eno === 4)
EXEC (DELETE FROM 'emp)
EXEC (DROP TABLE 'emp)

EXEC (CREATE TABLE 'dept ('dno INTEGER, 'dname CHAR(10)))
EXEC (INSERT INTO 'dept VALUES(100, "RnD"))
EXEC (INSERT INTO 'dept VALUES(300, "Sales"))

EXEC (CREATE TABLE 'emp ('eno INTEGER, 'dno INTEGER, 'name CHAR(10)))
EXEC (INSERT INTO 'emp VALUES(1, 100, "kmkim"))
EXEC (INSERT INTO 'emp VALUES(2, 200, "jdlee"))
EXEC (INSERT INTO 'emp VALUES(3, 100, "kumdory"))
EXEC (INSERT INTO 'emp VALUES(4, 100, "wegra"))

EXEC (SELECT ('name) FROM 'emp WHERE ('dno IN (SELECT ('dno) FROM 'dept)) ) 

EXEC (SELECT ('eno, 'dname, 'name) 
FROM ('emp INNER_JOIN 'dept )
ORDER_BY ('eno ASC))

EXEC (SELECT ('name) FROM 'emp) 

EXEC (SELECT ('eno, 'name) FROM 'emp ORDER_BY ('eno DESC)) 
EXEC (SELECT ('eno, 'name) FROM 'emp) 
EXEC (SELECT ('eno, 'name) FROM 'emp ORDER_BY ('eno DESC)) 

EXEC (DELETE FROM 'emp WHERE 'eno < 3) 
EXEC (SELECT ('eno, 'name) FROM 'emp) 
EXEC (SELECT ('eno, 'name) FROM 'emp WHERE 'eno === 4)

EXEC (DELETE FROM 'emp)
EXEC (DROP TABLE 'emp)
EXEC (DROP TABLE 'dept)
}

Macro vs. Makro

Joa Ebert — 2012-04-29T10:50:51

Hello,

is there any particular reason why the package regarding macro expansion is 
called scala.reflect.makro whereas the keyword is called "macro"? 
Would it make sense to rename scala.reflect.makro to scala.reflect.macro 
before the 2.10 release?


Best,

Joa

Scala Advocacy

cwhii — 2012-04-26T18:51:03

A quick look at a few pages of http://StackOverflow.com shows a
contrast in the level of expertise in Java vs Scala programmers asking
questions. In two samples of questions asked with tags "java" or
"scala" only 8% of the Java questioners have reputations over 1000
whereas for Scala it is 43%.

I suspect that Scala level (beginner to expert, application programmer
to library designer) http://www.scala-lang.org/node/8610 of
questioners on SO is leaning a bit towards the high end. This produces
much more complex discussions for Scala than the ones for Java.

This post is intended to provoke a discussion on how to encourage more
questions that relate to the beginner and application programmer
because I assume this would help in the advocacy of Scala.

REPL constructor completion?

Alex Cruise — 2012-04-23T18:23:59

I searched JIRA for a few minutes but couldn't find any existing
enhancement.

In a dystopian Java world...

With savage constructor overloading...

...it'd be nice to be able to say new Foo(<tab> and see stuff.

If anyone is aware of a preexisting enhancement ticket, or thinks this is a
bad idea, please pipe up. :)

It doesn't need to be a huge priority, because you can always get a badly
formatted list of the overloads by entering an invalid constructor, e.g.:

scala> new Foo(nonsensical)
<console>:11: error: overloaded method constructor Foo with alternatives:
  ...

-0xe1a

Some HBase Ideas (Hosted on Github)

Jacob Groundwater — 2012-04-22T11:11:33

I was dreaming one lazy afternoon and had a few ideas for Scala HBase 
libraries. I put what I came up with here:

https://github.com/jacobgroundwater/Scala-HBase/wiki

I would love any feedback or critiques.

Thanks!

Mailing list reminder: Scala-debate

Scala Mailing Lists — 2012-04-21T13:32:02

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-debate/subscribe
or send an email to scala-debate+unsubscribe< at >googlegroups.com

Thank you!
The Scala Team