gmane.comp.lang.scala

Interview: Scala creator Martin Odersky - The H Half Hour

Simon Ochsenreither — 2012-05-25T12:24:30

Nice interview: 
http://www.h-online.com/open/features/Scala-creator-Martin-Odersky-The-H-Half-Hour-1582445.html

Scope of Scala's implicit class conversion

ron — 2012-05-23T22:35:08

Hello List,

Please help me clarify the following (carbon copied from Stackoverflow
http://stackoverflow.com/questions/10727508/scope-of-scalas-implicit-class-conversion#comment13936013_10727508):

Scala seems to apply the implicit class conversion on the largest
possible expression, as in the following example:

----repl----
scala> class B { def b = { println("bb"); true } }
scala> class A { def a = { println("aa"); new B } }
scala> (new A).a.b
aa
bb
res16: Boolean = true

scala> class XXX(b: => Boolean) { def xxx = 42 }
scala> implicit def toXXX(b: => Boolean) = new XXX(b)
scala> (new A).a.b.xxx
res18: Int = 42
----repl----

Which part of the specification addresses this behavior? What prevents
the compiler from converting into val x = (new A).a.b; toXXX(x).xxx ?

Thank you,
Robin

What Differentiates Gosu From Other Languages?

Simon Ochsenreither — 2012-05-23T10:02:29

Interesting read, also references Scala: 
http://guidewiredevelopment.wordpress.com/2012/02/27/what-differentiates-gosu-from-other-languages/

package objects and package declarations

Paul Phillips — 2012-05-22T18:07:09

This is an obvious consequence of the rules for implicits, but I hadn't
thought of or noticed it until now when I had to debug why someone else's
project didn't compile.  Maybe this is old news.

// file 1
package foo

class Bippy

package object bar {
  implicit def bippy(x: Int) = new Bippy
}

// file 2: Does not compile.
package foo.bar.baz

class A {
  val x: foo.Bippy = 5
  // error: type mismatch;
  //  found   : Int(5)
  //  required: foo.Bippy
  //   val x: foo.Bippy = 5
  //                      ^
  // one error found
}

// file 3: does compile.
package foo.bar
package baz

class B {
  val x: foo.Bippy = 5
}

Mailing list reminder: Scala-language

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

Welcome to the "Scala-language" 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-language" mailing list:

This list is the main forum for discussions and news about the
Scala language. Questions about programming in Scala, especially
by beginners, should preferably go to the "scala-user" list
instead: please post there if you would like to discuss your
code snippets or need assistance. Questions about Scala tools
should go to "scala-tools".

Questions about the Scala IDE for Eclipse should go to 
http://groups.google.com/group/scala-ide-user.

Threads that become too long, and are unlikely to be of general
interest, should eventually be moved to "scala-debate".

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

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-language/subscribe
or send an email to scala-language+unsubscribe< at >googlegroups.com

Thank you!
The Scala Team

Should a self-referential val/var declaration really compile?

Jon Steelman — 2012-05-20T14:11:07

(Sending to scala-language per Naftoli)

Should the below really compile?

Welcome to Scala version 2.9.2 (Java HotSpot(TM) 64-Bit Server VM, Java
1.6.0_31).
Type in expressions to have them evaluated.
Type :help for more information.

scala> var s: String = s
s: String = null


Same behavior in 2.9.2 and 2.10.0-M3

Thanks,
Jon


Mark Grand added:

I think you have found a hole in the language spec.  The language
reference talks about scope, but does not define precise lexical rules
for where scopes begin.  So it appears that the scope begins somewhere
to the left of the equals sign.  Here are some other things that
compile:

scala> var j : Int = j
j: Int = 0

scala> var b: Boolean = b
b: Boolean = false

scala> var v:Int = v+1
v: Int = 1

scala> val x:Int = x
x: Int = 0

scala> lazy val d:Int = d+1
d: Int = <lazy>

scala> d
java.lang.StackOverflowError

Tuples as arguments to operators

Paul Butcher — 2012-05-19T12:55:05

I just got bitten by this: 





I guess that on reflection it's clear that this happens because operators are really methods, but it surprised me when it happened. Would it not be possible for the compiler to work out what's going on here for itself though?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul< at >paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

Defining type parameters for nested wrappers

Ka Ter — 2012-05-17T21:07:18

Hi,

I have a problem in defining the right type parameters due to recursive
type definitions? I want to define a trait for a wrapper that holds a
value and contains several methods that again return a wrapper - here
there is only a map() method. Now I want to define nesting wrappers like
NestingWrapper and AnotherNestingWrapper that nest another wrapper. At
the base of this nested wrapper stack there is a BaseWrapper that nests
no other wrapper.
My problem is now, how can I define the type parameters of trait wrapper
such that I can better define each nested wrapper more exactly. For
example in the main method I want to access the test() method of the
nested wrapper but this is not possible since it is only a Wrapper and
not a NestingWrapper.
If I add an additional type parameter to the trait Wrapper then I get
errors since there is always an unbound parameter or some kind of
recursive definition.
I simply want to define: AnotherNestingWrapper[A, NestingWrapper[A,
BaseWrapper[A, BaseWrapper]]] and the BaseWrapper denotes its own type
as nested one. And if I call the map() method then the result has to be
a: AnotherNestingWrapper[B, NestingWrapper[B, BaseWrapper[B, BaseWrapper]]]
Any ideas?

object Main
{
    def main(args: Array[String]): Unit =
    {
        val test = new AnotherNestingWrapper(new NestingWrapper(new
BaseWrapper(6)))
       
        test.nested.test    // Error since nested is only a Wrapper and
not a NestingWrapper
    }
}

trait Wrapper[A]
{   
    def map[B](f: A => B): Wrapper[A]
}

// Does not work due to recursive definition?
//trait Wrapper[A, W[X,Y] <: Wrapper[A, Y]]
//{   
//    def map[B](f: A => B): W[B, Y]
//}

class BaseWrapper[A](val value: A) extends Wrapper[A]
{
    def map[B](f: A => B) = new BaseWrapper(f(value))
   
    def base = 0
}

class NestingWrapper[A](val nested: Wrapper[A]) extends Wrapper[A]
{
    def map[B](f: A => B): Wrapper[B] = nested.map(f)
   
    def test = 5
}

class AnotherNestingWrapper[A](nested: Wrapper[A]) extends
NestingWrapper(nested)
{
    def foo = 8
}

Scala is rising 11% according to a Report published yesterday.

Bogomil Shopov — 2012-05-16T13:03:59

Scala has established itself as the Java alternative on the JVM and is
especially gaining ground with those who need a highly distributed
environment or great messaging, but don’t want to use Erlang.

Composing monad transformers

Ka Ter — 2012-05-14T15:51:57

Hi,

I'm trying to implement some variation of monads (I call it monadics)
without type classes. I come to the point that the Scala compiler cannot
infere the necessary type and I'm wondering if there is any hint to
achieve this.

In the following example (reduced to functor map method) I try to wrap
an IdentityT by an IdentityT but there is a compiler error in the main
method. But when I provide the necessary type lambda per hand then it
works. Why can the compiler not see that an IdentityT is a Monadic, too?

Any ideas how I get this example to work?

PS: I tried something also using the scalaz library without success. Now
i reduced the type class overhead in order to see where the problem is

trait Monadic[A, M[_]]
{
    def map[B](f: A => B): M[B] with Monadic[B, M]
}

case class Identity[A](val value: A) extends Monadic[A, Identity]
{
    def map[B](f: A => B): Identity[B] = new Identity(f(value))
}

case class IdentityT[A, M[_]](val pool: Monadic[A, M]) extends
Monadic[A, ({type T[X] = IdentityT[X, M]})#T]
{
    def map[B](f: A => B): IdentityT[B, M] = new IdentityT(pool.map(f))
}

object Main
{
    def main(args: Array[String]): Unit =
    {       
        val a = Identity(5)
        val at = new IdentityT(a)
//        val att = new IdentityT(at)    // **** Compiler error       
        val att = new IdentityT[Int, ({type T[X] = IdentityT[X,
Identity]})#T](at)    // This works
       
        println(att)
    }
}

how check if jobs executed by ResizableThreadPoolScheduler has ended

rt — 2012-05-13T09:30:36

Hi,
i use ResizableThreadPoolScheduler. I invoke some execute methods on
it. I wont execute some action after all jobs (invokes from
ResizableThreadPoolScheduler) was ended. How i can do?

deprecation candidate: scala.parsing.ast

Jason Zaugg — 2012-05-12T20:31:58

This package is disclaimed as "HIGHLY EXPERIMENTAL", hasn't been
touched for years, contains a number of TODOs. It doesn't seem to be
used in the wild. [1]

It probably wouldn't be admitted to the standard library today. I'd
vote to deprecate it for 2.10.

-jason

[1] http://stackoverflow.com/questions/5751150/how-is-scala-util-parsing-ast-binders-supposed-to-be-used

[scala-language] Giving a Scala introduction — suggestions for existing editable slides/content to reuse?

Simon Ochsenreither — 2012-05-12T16:46:24

Hi everyone!

I'll be giving a Scala presentation to non-Scala-developers in a few days.

Can someone suggest decent slides usable as a starting point (and to make 
sure I haven't forgot any important topic)?

I would be very happy about any pointers to material I could use for that.

Thanks!

Simon

SynchronizedXxx: an open invitation for bit rot?

Jason Zaugg — 2012-05-12T12:53:21

See my comments on SI-4916 [1].

This pattern is now being used in the reflection implementation. [2] I
can comment out any of the synchronized wrappers, and silently
introduce a potential race condition. Equivalently, and less
nefariously, someone else can add a new method to the super class and
forget to add the wrapper.

Seems like we ought to leverage the machines here, either by
reflecting on the written code to check all methods are overriden, or,
better, by generating this code during with a build script or a macro.

-jason

[1] https://issues.scala-lang.org/browse/SI-4916?focusedCommentId=57557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-57557

[2] https://github.com/scala/scala/blob/3511e596/src/compiler/scala/reflect/runtime/SynchronizedSymbols.scala#L25

Access to the return type of one of a type parameter's method

Ka Ter — 2012-05-11T09:06:00

Hi,

I already posted this question on scala-user but perhaps that was the wrong group. I'm dealing with type parameters again. I have the following test class

class Test[V <: Vertex](val value: V)
{
    def test = value.test
}

Now the return type of method test() is the one of test() in the Vertex
type (an Edge).

class Vertex
{
    def test: Edge = ....
}

But what I really need is a specialized type if the Vertex is specialized:

class SpecialVertex extends Vertex
{
    def test: SpecialEdge = ....
}

with
class SpecialEdge extends Edge

val test = (new Test(new SpecialVertex)).test()    // Result is Edge and
not SpecialEdge

Is there any possibility to tell the class Test that the return type of
method test depends on the given type parameter V and not on the type
parameter's upper bound?
Can I denote somehow that test() results in "V.test().type"? The
compiler could determine the type at compile time since there is a type
parameter given.
Any ideas?

Possible compiler bug: x.apply() does not compile when x() does.

Aleksey Nikiforov — 2012-05-07T18:03:20

I am very puzzled by why "immutable.HashSet[String]()" works, but
"immutable.HashSet[String].apply()" does not.

Welcome to Scala version 2.9.2 (OpenJDK 64-Bit Server VM, Java
1.7.0_03-icedtea).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import scala.collection._
import scala.collection._

scala> immutable.HashSet[String]()
res0: scala.collection.immutable.HashSet[String] = Set()

scala> immutable.HashSet[String].apply()
<console>:11: error: missing arguments for method apply in class
GenericCompanion;
follow this method with `_' if you want to treat it as a partially applied
function
              immutable.HashSet[String].apply()
                               ^

Idea: End-of-Line Comma Inference?

Haoyi Li — 2012-05-05T18:34:34

I've been looking at coffeescript, where for multi-line lists, you can omit
the commas at the end of a line:

array1 = [1, 2, 3]

array2 = [
  1
  2
  3
]

This also works for spreading out parameter lists over multiple lines when
calling functions:

b =
  add(

    1
    2
    3

  )

alert(b) //prints 6

What do people think of this? It feels like a very nice symmetry: just as
semicolons separate statements and can be omitted for statements on
separate lines, commas separate expressions and can be omitted for
expressions on separate lines.

While I suppose this doesn't matter when programming in a procedural style
, with lots of statements and very small expressions that generally fit on
one line, it would be nice to have when programming in a more functional
style with a smaller number of big expressions, which have to be spread out
over multiple lines. I'm seeing lot of parts of my code like:

html =
    body(
        div(
            h1(...),
            p(...),
            p(...),
            p(...)
        ),
        div(...),
        div(...)
    )

with lots of big multi-line expressions where it would be pretty nice to be
able to drop the commas in between. This is a contrived example, the actual
expressions (HTML pages) are far bigger! I know this has been brought up
before:

http://www.scala-lang.org/node/8701
http://www.scala-lang.org/node/8700

and there are potential problems with inconsistency/ambiguity/etc., and
it's not a huge deal, nor a huge amount of visual noise. However, it seems
the same arguments could be made against end-of-line semicolon inference
(and they are, in javascript circles!), but we seem pretty happy without
our end-of-line semicolons.

I suppose my questions would be:

   - If it works for Coffeescript, why wouldn't it work for Scala
   - If it works for end-of-line semicolons, why wouldn't it work for
   end-of-line commas?

These aren't rhetorical; CS and Scala are pretty different, and so are
statements and expressions, and it may very well be impossible/unfeasible.
I don't grok enough of the details of the parser to see why, and it would
be nice if someone could enlighten me =)

-Haoyi

dynamic semantics

Paul Phillips — 2012-05-03T23:40:03

Is it expected that you can't do anything with Dynamic unless the
methods have been implemented? Seems to defeat some of the purpose.
It "worked" in 2.9.2 at least for the definition of worked that
involves crashing.  But you could see it was trying to work.

% scala292 -Xexperimental
Welcome to Scala version 2.9.2 (Java HotSpot(TM) 64-Bit Server VM,
Java 1.6.0_31).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def f(x: Dynamic) = x.bippy
dynatype: x.applyDynamic("bippy")()
dynatype: x.applyDynamic("applyDynamic")
dynatype: x.applyDynamic("applyDynamic")
dynatype: x.applyDynamic("applyDynamic")
dynatype: x.applyDynamic("applyDynamic")
dynatype: x.applyDynamic("applyDynamic")
dynatype: x.applyDynamic("applyDynamic")

% m3scala
Welcome to Scala version 2.10.0-M3 (Java HotSpot(TM) 64-Bit Server VM,
Java 1.6.0_31).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import language.dynamics
import language.dynamics

scala> def f(x: Dynamic) = x.bippy
<console>:8: error: value selectDynamic is not a member of Dynamic
       def f(x: Dynamic) = x.bippy
                           ^

scala> class Bippy extends Dynamic { def selectDynamic(name: String) =
println("I'm bippy!") }
defined class Bippy

scala> def f(x: Bippy) = x.bippy
f: (x: Bippy)Unit

scala> f(new Bippy)
I'm bippy!

look ma, I'm generic

Paul Phillips — 2012-05-02T18:04:28

Maybe this is just a day at the beach for some of you fancy type programmers.

One invert function:

 - works on sequential collections, parallel collections, Iterators,
Arrays, Strings, etc.
 - preserves Stream laziness (something not presently accomplished by
e.g. zipped)
 - is installed with an implicit conversion which takes only three
type parameters (for Tuple3) and no implicit parameters
   (this being important in Predef for implicit search performance reasons)

The one change I had to make to the collections (and it should be
immaterial unless you need it) to achieve this lovely sameness of
implementation is to add this interface:

  trait Container[+A, +CC[X] <: GenTraversableOnce[X]] extends Any
with GenTraversableOnce[A]

Because there is so far as I can tell no common parent to Iterator and
Traversable which preserves the shape of the container.

I just called it "Container".  It doesn't have to be that, but please
for god's sake don't suggest I should call it
"GenTraversableOnceLike".  Let's have something sanely named at the
very top of the hierarchy to which we can program when we're not
overly concerned with the distinctions among the many different ways
of bunching stuff.

Feedback solicited. (Silence is endorsement.) The total patch is quite
small, see for yourself.

  https://github.com/paulp/scala/compare/master...topic%2Finvert


scala> (Iterator(1), Iterator("a"), Iterator(Array(1))).invert
res0: Iterator[(Int, String, Array[Int])] = non-empty iterator

scala> (Array(1), Array("a"), Array(Array(1))).invert
res1: Array[(Int, String, Array[Int])] = Array((1,a,Array(1)))

scala> (List(1), List("a"), List(Array(1))).invert
res2: List[(Int, String, Array[Int])] = List((1,a,Array(1)))

scala> (Seq(1), List("a"), Vector(Array(1))).invert
res3: Seq[(Int, String, Array[Int])] = List((1,a,Array(1)))

scala> (Vector(1), List("a"), Seq(Array(1))).invert
res4: scala.collection.immutable.Vector[(Int, String, Array[Int])] =
Vector((1,a,Array(1)))

scala> (Stream from 1, Stream from 2, Stream from 3).invert
res5: scala.collection.immutable.Stream[(Int, Int, Int)] = Stream((1,2,3), ?)

scala> ("abc", "def", "ghi").invert
res6: scala.collection.immutable.IndexedSeq[(Char, Char, Char)] =
Vector((a,d,g), (b,e,h), (c,f,i))

scala> (1 to 10 par, 1 to 10 par, 1 to 10 par).invert
warning: there were 3 feature warnings; re-run with -feature for details
res7: scala.collection.parallel.immutable.ParSeq[(Int, Int, Int)] =
ParVector((1,1,1), (2,2,2), (3,3,3), (4,4,4), (5,5,5), (6,6,6),
(7,7,7), (8,8,8), (9,9,9), (10,10,10))

traps for the unwary: today's java/arrays/variance/inference/overload issue

Paul Phillips — 2012-05-02T15:06:43

This was sufficiently non-obvious I thought it was of general
interest.  You can run into this different ways, and without involving
Arrays or java, such as:

  scala> def f(x: Mutable) = 1 ; def f(x:
collection.mutable.Set[AnyRef]) = 2 ; f(collection.mutable.Set("abc"))
  f: (x: Mutable)Int <and> (x: scala.collection.mutable.Set[AnyRef])Int
  f: (x: Mutable)Int <and> (x: scala.collection.mutable.Set[AnyRef])Int
  res0: Int = 1

Choosing the "most specific type" while resolving the overload can
lead to choosing the "least specific type" from the argument types
among the overload choices, because (as in the above) choosing
mutable.Set[String] excludes the second choice, so it never gets to
the point where it could infer mutable.Set[AnyRef].

Also of note here is that java and scala -- calling the same
overloaded method with the same typed arguments -- make different
choices, because Array[String] matches Array[Object] in java but not
in scala.  Unfortunately people write java classes, even in the jdk
itself (e.g. javax.swing.tree.TreePath, see below) generally thinking
only of java overloading semantics, so they do crazy things like
overloading Object and Object[] and expecting good things to come of
it.

::: Resolution from https://issues.scala-lang.org/browse/SI-5719

This is damage inflicted by a combination of lossy java interop and
the insanity of constructors which take "Object", which isn't so hot
in any language.

Notice that TreePath has two public constructors:

  TreePath(Object lastPathComponent)
  TreePath(Object[] path)

So what happens if you say

  new TreePath(Array("abc"))

Overloading resolution has to choose a constructor. An Array[String]
is not an Array[Object] (arrays are not covariant, not in this
language) so it chooses the Object constructor, which of course an
Array is.

Were there no Object constructor, the expression would not typecheck
as Array[String] and the inferencer would choose Array[Object]. But as
it is, it's just following orders.

You can work around this by specifying the type.

  new TreePath(Array[Object]("abc"))

or whatever the equivalent is in your code.

scala> val x1 = new TreePath(Array("abc"))
x1: javax.swing.tree.TreePath = [[Ljava.lang.String;< at >77c16c5f]

scala> val x2 = new TreePath(Array[Object]("abc"))
x2: javax.swing.tree.TreePath = [abc]

[scala-language] ScalaDays 2012 – Odersky's Keynote: Where Scala is Going

Simon Ochsenreither — 2012-05-01T03:52:38

Hi,

as some of you might have already seen, the video from Martins Keynote is 
now available on Skillsmatter, 
http://www.reddit.com/r/programming/comments/t0lyl/scaladays_2012_oderskys_keynote_where_scala_is/.

I have written down notes for those unable or too lazy to watch, you can 
get them at Reddit 
(http://www.reddit.com/r/programming/comments/t0lyl/scaladays_2012_oderskys_keynote_where_scala_is/) 
or at HN (http://news.ycombinator.com/item?id=3912885).

Have fun!