mar | 27 Nov 22:06 2014
Picon

Question about member modifiers in the 2.11-spec

It seems as if the section on qualified member modifiers (http://www.scala-lang.org/files/archive/spec/2.11/05-classes-and-objects.html#modifiers) has been copied between the private and the protected subsection. Notably, the spec says

An different form of qualification is private[this]. A member M marked with this modifier is called object-protected; it can be accessed only from within the object in which it is defined. That is, a selection p.M is only legal if the prefix is this or O.this, for some class O enclosing the reference. In addition, the restrictions for unqualified private apply.

… and just in the section below

A different form of qualification is protected[this]. A member M marked with this modifier is called object-protected; it can be accessed only from within the object in which it is defined. That is, a selection p.M is only legal if the prefix is this or O.this, for some class O enclosing the reference. In addition, the restrictions for unqualified protected apply.

The reason I looked at these sections was to figure out the difference between private[sassafras] and protected[sassafras]. Hopefully someone can clear that up for me too :)

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
MikeD | 24 Nov 08:31 2014
Picon

Recent announcements by Microsoft and Scala .Net

Hello,

I'm coming mainly from .Net background but quite interested in Scala as a language. From the (relatively) recent additions to mainstream and close to mainstream languages I see it as the one having the closest resemblance to C-inspired languages, while providing great benefits both in OOP and FP spaces.

However, as somebody who develops enterprise software with fat clients for Windows machines, I cannot use the language in my everyday job, which I would like very much. Of course, there is F#, which is a great language by itself, but it looks and feels so different compared to the mainstream C# that it will be very hard to convince anybody using it, and it lacks many OO features Scala has.

I know that the .Net effort has been abandoned sometime in 2012, as I understand, because of no interest from Typesafe and difficulties to marry the Scala and the CLR generics. But there are two factors that surfaced recently which make me think about viability of the .Net backend for Scala:
a. Recent announcement by Microsoft about open-sourcing the .Net platform
b. Project Valhalla which talks, among other things, about possible inclusion of reified generics in JVM

As I see it, the former may increase community's interest/involvement in the .Net platform as a whole. And the later, if I understand correctly, will require from Scala to evolve in a way which will end in some kind of support for platform-based, and not only compiler ones, reified generics.

So, how long is the way from current (abandoned) state to support .Net backend and is there any hope to bridge the technological differences between the platforms (in a layman terms)?

Thanks in advance for any enlightenment regarding the matter.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Qr Wang | 17 Nov 07:28 2014
Picon

scala type system(scala IO)

sealed trait IO[A] {
    def flatMap[B](f: A => IO[B]): IO[B] =
      FlatMap(this, f)
    def map[B](f: A => B): IO[B] =
      flatMap(f andThen (Return(_)))
  }
  case class Return[A](a: A) extends IO[A]
  case class Suspend[A](resume: () => A) extends IO[A]
  case class FlatMap[A,B](sub: IO[A], k: A => IO[B]) extends IO[B]

 def printLine(s: String) :IO[Unit]=
    Suspend(() => Return(println(s)))

these codes are from the book functional programming in scala .
look the printLine function,why it return a type of IO[Unit]? should not is return type IO[IO[Unit]]?
Anybody can help me?

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
andrebolle | 16 Nov 14:53 2014
Picon

Typo on page 163 (Bindings) of the 2.9 Language Spec. There is no closing "}"

Subject line says it all (I hope)

Sorry if this is not the correct forum for this. If it isn't perhaps someone could enlighten me.

Cheers
Andre 

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Vytautas Astrauskas | 14 Nov 15:04 2014
Picon

Scala Traits and JVM: Question about checkcast operation

Hello,
during a lecture the professor discussed how Scala inheritance works and
showed this example:

  trait T1 {}
  trait T2
{}
 
def foo(x : T1 with T2) = ???

I become curious: how this is implemented under the hood?

I tried to compile the following scala class:

  package traitsubtyping2

 
class C {
   
def foo(t: T1 with T2 with T3) = {
      t
.m1
      t
.m2
      t
.m3
      println
("C")
   
}
 
}



and then decompile it with javap -c C:

  Warning: Binary file C contains traitsubtyping2.C
 
Compiled from "C.scala"
 
public class traitsubtyping2.C {
   
public void foo(traitsubtyping2.T1);
     
Code:
         
0: aload_1
         
1: invokeinterface #16,  1 // InterfaceMethod traitsubtyping2/T1.m1:()V
         
6: aload_1
         
7: checkcast     #18       // class traitsubtyping2/T2
       
10: invokeinterface #21,  1 // InterfaceMethod traitsubtyping2/T2.m2:()V
       
15: aload_1
       
16: checkcast     #23       // class traitsubtyping2/T3
       
19: invokeinterface #26,  1 // InterfaceMethod traitsubtyping2/T3.m3:()V
       
24: getstatic     #32       // Field scala/Predef$.MODULE$:Lscala/Predef$;
       
27: ldc           #34       // String C
       
29: invokevirtual #38       // Method scala/Predef$.println:(Ljava/lang/Object;)V
       
32: return

   
public traitsubtyping2.C();
     
Code:
         
0: aload_0
         
1: invokespecial #45       // Method java/lang/Object."<init>":()V
         
4: return
 
}



An interesting discovery for me was that after compiling only the T1 is
used as the type of the method parameter. However, arguments for this
design decision seem to be clear: it does not require any new types to
be generated, and it is safe, because method arguments are already
checked by Scala compiler.

Nevertheless, one thing I could not understand: why checkcast is needed
before invokeinterface? If I understood it correctly, the
invokeinterface operation checks if method that is being called exists
and it does not mind what static type of that object is known to the JVM
(am I missing something?). Therefore, it should work in the same way without
checkcast?

I tried to delete checkcasts by using Java Bytecode Editor, and the printed
result was the same (method mX prints TX). Also, I tried to pass object,
which has a dynamic type T1 with T3 (I dropped T2), and with original
class C code, I got an exception:

  java.lang.ClassCastException: traitsubtyping2.TT cannot be cast to traitsubtyping2.T2

and with modified C code, I got an exception:

  java.lang.IncompatibleClassChangeError: Class traitsubtyping2.TT does not implement the requested interface traitsubtyping2.T2

Both error messages seem to be good enough, therefore, I do not think that
checkcast was needed to have a better error message.

So, the question that bugs me is: why checkcast is needed?

I uploaded all my experiments to github:
https://github.com/vakaras/scala-investigations.

For compiling I am using:
Scala IDE build of Eclipse SDK
3.0.4-2.11-20140723-2253-Typesafe
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Kind regards,
Vytautas Astrauskas

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Simon Schäfer | 14 Nov 01:08 2014
Picon

List() is optimized to Nil

Some days ago, there was this question:
http://stackoverflow.com/questions/26732506/in-scala-is-there-any-performance-difference-between-list-and-nil

The interesting thing is that List() is basically the same as Nil in 
bytecode, whereas Seq() is still Seq() even though at runtime it also 
evaluates to Nil.

Is List() == Nil hardcoded in scalac or is it a "normal" inlining 
optimization that can be applied to List() but not to Seq()?

--

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Slinn | 12 Nov 07:35 2014
Picon

scala.concurrent.Blocking

I believe the following to be true. Corrections and clarifications are welcome:

I/O bound tasks can tie up threads and idle them for extended periods of time. The global threadpool has special provision for detecting and handling specially marked code within futures that block. Code contained within a blocking {} block within a future that is backed by a ForkJoin threadpool will be monitored for idleness, and extra threads will be allocated as necessary. Enclosing code within blocking {} that is not executed by a future which is backed by a suitably configured ForkJoin threadpool has no effect. The blocking method has the following signature:

def blocking[T](body: ⇒ T): T


blocking invocations seem to be designed to be aware of each other and are co-operative, via one or more BlockContext references which are generally of no concern to the average Scala programmer.

Questions

  1. It would seem that f0 (below) would behave identically with f1 and f2 when the global ExecutionContext was not backing these futures. Alternatively, given this code which shows global is in scope, f1 and f2 might behave differently because f1 might spin more threads when rpc1 and rpc2 block since those expressions are wrapped within blocking expressions.

    import scala.concurrent._ import scala.concurrent.ExecutionContext.Implicits.global val f0 = Future { val w = nonBlockingComputation1() val x = rpc1(param1, param2, etc) val y = nonBlockingComputation2() val z = rpc2(param3, param4, etc) doSomethingWith(w, x, y, z) } val f1 = Future { val w = nonBlockingComputation1() val x = blocking { rpc1(param1, param2, etc) } val y = nonBlockingComputation2() val z = blocking { rpc2(param3, param4, etc) } doSomethingWith(w, x, y, z) } val f2 = Future { blocking { val w = nonBlockingComputation1() val x = rpc1(param1, param2, etc) val y = nonBlockingComputation2() val z = rpc2(param3, param4, etc) doSomethingWith(w, x, y, z) } }
    1. Does Scala 2.11.4 in fact handle the execution of f1 and f2 differently?
    2. Is this behavior expected to change in future Scala releases?
  2. How can an custom ForkJoin threadpool, for example this one one provided by Akka's configuration, be enhanced so it also supports blocking? import scala.concurrent._ import scala.concurrent.ExecutionContext.Implicits.global val config = """ |akka { | my-dispatcher { | type = Dispatcher | executor = "fork-join-executor" | fork-join-executor { | parallelism-min = 2 | parallelism-factor = 2.0 | parallelism-max = 10 | } | throughput = 100 | } |} |""".stripMargin implicit val executionContext = system.dispatchers.lookup("my-dispatcher")
  3. Aleksandar Prokopec told me that the easiest way to make a custom ExecutionContext that responds to the blocking hint is to wrap ForkJoinPool and implement the execute method so that it sets your own BlockContext object, or that the worker threads are BlockContext objects. See: github.com/scala/scala/blob/v2.11.4/src/library/scala/concurrent/BlockContext.scala. Unfortunately that did not tell me much. Can anyone show me a concrete example?

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
mar | 7 Nov 14:13 2014
Picon

Creating a completed future without an ExecutionContext

Hiya,

I remember seeing someone requesting this feature earlier. Couldn’t find anything so I wrapped my own.

Since it is somewhat costly to enqueue a future with an already available value I’m hoping in the future (no pun intended) something like this will be made available in the official Scala API.

implicit class CompletedFuture(private val f: Future.type) extends AnyVal { def completed[A](completedValue: A): Future[A] = this.completed(Success(completedValue)) def completed[A](completedTry: Try[A]): Future[A] = new Future[A] { def isCompleted: Boolean = true def onComplete[U](f: Try[A] => U)(implicit ec: ExecutionContext): Unit = f(completedTry) def value: Option[Try[A]] = Some(completedTry) def ready(atMost: Duration)(implicit permit: CanAwait): this.type = this def result(atMost: Duration)(implicit permit: CanAwait): A = completedTry.get } }

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dinesh Maske | 7 Nov 07:26 2014
Picon

mongodb database with scala play 2.0 tutorial

I am new in play framework 2. I have play 2 with scala and MongoDb requirement. I searched lots on Play 2 and MongoDb connection, but didn't find any useful documentation.

There is lots of plugins available eg. Casbah, Reactive Mongo, Salat. So which is best for use, and which have better future?

If i want to implement my own connection to Mongo without using third party plugin, is it possible?

Please give examples and document on Play 2 and MongoDB connection.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Didier Dupont | 6 Nov 01:41 2014
Picon

case classes default parameters may have different meaning in constructor and companion object apply method

Following a question on stack overflow : http://stackoverflow.com/q/26767525/754787, and my answer http://stackoverflow.com/a/26769056/754787

When there are default arguments in a case class, say

case class A(x: X = expr)

then it causes, according to SLS 5.3.2, a factory method def apply(x: X): A = expr to be generated in the
companion object of A. 

It is possible that the companion object of A contains some definitions that will cause expr to have a
different meaning inside and outside the object.  It may compile only on one side, fail to compile on both
sides for different reasons, or compile on both side, but with different meanings. 

For instance : 

	case class A(b:B = bb)

	case class B(i: Int, j: Int)

	object bb extends B(3, 4)

	object A {

  		val bb = new B(7, 2)
	}

 	println(A())
 	println(new A())

This code will print

	A(B(7,2))
	A(B(3,4))

I also checked that if it fails to compile inside and outside for different reasons, the compiler gives two
error message, and if it fails to compile either inside or outside, the code does not compile. 

I believe the present behavior is in line with the specification. Still, it was not discussed in the SID for
default arguments :
http://docs.scala-lang.org/sips/completed/named-and-default-arguments.html, and maybe that
was an oversight 

Maybe it could be reconsidered (not sure which side I would favour then), or maybe it could make it into the
scala puzzlers :)

Thanks

Didier Dupont

--

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

tupled and ProductN

Can someone confirm if this behaviour is correct?

     Welcome to Scala version 2.11.2 (OpenJDK Server VM, Java 1.7.0_65).
     Type in expressions to have them evaluated.
     Type :help for more information.
     
     scala> import scala.language.postfixOps
     import scala.language.postfixOps
     
     scala> case class Foo(a:Int,b:Int)
     defined class Foo
     
     scala> (Foo.apply _ tupled) (1,2)
     res0: Foo = Foo(1,2)
     
     scala> val prod:Product2[Int,Int]= (1,2)
     prod: Product2[Int,Int] = (1,2)
     
     scala> (Foo.apply _ tupled) prod
     <console>:17: error: value prod is not a member of ((Int, Int)) => Foo
                   (Foo.apply _ tupled) prod
                                   ^
I would have expected tupled to work on a ProductN

-mark

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gmane