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.
Scala Mailing Lists | 21 Oct 15:32 2014
Picon
Picon

Mailing list reminder: Scala-language

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

--

-- 
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.

[ANN] product-collections 1.0-RC1

Product-collections[1] is a specialized scala collection that holds homogeneous tuples.  It also has a fairly neat, strongly typed, CSV i/o component and some basic statistical functionality included weighted statistics.

Product collections is good for doing quick data analysis on 2D data.  It has practically zero learning curve and is very lightweight.  It's not very good at handling malformed (csv) data.

I've been using it internally for over a year.

Changes for v 1.0: 

 - Performance improvement for column retrieval.
 - Published on bintray
 - Removed kludgy Tuple23 class

I hope that some of you find it useful.

--
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.
Hadil Sabbagh | 10 Oct 19:00 2014
Picon

Generating ScalaSignatures

I am working on a project that may require the generation of ScalaSignature annotations.
  1. Are these required at runtime?
  2. Where is the specification so I can generate them using classes I build dynamically at runtime using ASM?

Thanks,
Hadil G. Sabbagh, Ph.D.

--
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.
Roland Kuhn | 1 Oct 12:25 2014

pattern matching with generic extractors

Hi folks,

while working on typed ActorRefs (and everything that entails) it becomes clear that we will see lots of generic case classes that people will want to match against. One example is the following:

case class RunTest[T](props: Props[T], trigger: T, replyTo: ActorRef[Status], timeout: FiniteDuration)

The actor that interprets this message does not know or care about what T is instantiated to, it only wants to do the following:

msg match {
  case RunTest(props, trigger, replyTo, timeout) =>
    val test = ctx.spawn(props)
    test ! trigger
    ... // register timeouts etc.
}

This currently works (I suspect accidentally) because the inferred type for T will be Any, but it is not nice because I could just as well do “test ! 42” and the compiler would not complain. I have no formal proof, but it seems that it should be sound to allow the introduction of a fresh type name within the scope of the case statement that would solve this:

msg match {
  case RunTest[new T](props, trigger, replyTo, timeout) =>
    val test = ctx.spawn(props) // this now is ActorRef[T]
    test ! trigger              // trigger is a T
    ... // register timeouts etc.
}

This would fix the type-safety issue present in the current pattern matching logic. Is this something that we should maybe pursue?

Regards,


Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter:  <at> rolandkuhn


--
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.

Stefano Di Martino | 30 Sep 16:17 2014
Picon

PartialFunction expected, but I get function - Bug in Scala?!

I define a partial function

val squareRoot = new PartialFunction[Double, Double] {
    def isDefinedAt(x: Double) = x >= 0
    def apply(x: Double) = scala.math.sqrt(x)
}

And then I define

val f1= squareRoot andThen sqr
> f1: PartialFunction[Double,Double] = <function1>
 
Seems logic, that f1 is a PartialFunction, because f1(-2) is not defined.

And then I define

val f3= sqr compose squareRoot
> f3: (Double) => Double = <function1>

f3 is a normal function, but f3(-2) is not defined! Why is f1 a PartialFunction and f3 not?!

Is this a bug in scala?!

Best regards,
Stefano

--
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.
Steven Obua | 29 Sep 22:44 2014
Picon

Inference of type parameters to Any instead of Nothing

Hi, 

let's say I have a trait 

class ParseTree {
               ... 
  val result : Any
  def value[T] : T = result.asInstanceOf[T]

and the snippet

def nice(w : Int) = println("result: " + w)
def notnice(w : Any) = nice(w.asInstanceOf[Int])
val parsetree : ParseTree = ... // this particular parsetree has  an Int value
nice(parsetree.value)
notnice(parsetree.value)

Then the above will run the nice call as expected, but crash when notnice gets called because it tries to cast the value to Nothing. To avoid that, I could write

notnice(parsetree.value[Any])

in the above code, but I have hundreds of such callsites, so it is quite cumbersome to do so, and, to be honest, really ugly. Is there a way to tell Scala to do the expected thing here?

Thanks for any suggestions,

Steven

--
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 | 29 Sep 11:48 2014
Picon

Implementing the observer pattern in scala

I am new in scala, I want implement observer pattern

Is there any example or tutorial on the observer pattern in scala?

One another question is:

The Observer patterns Vs Scala react?

which is best? and why?

Give some 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.
Benjamin Drasin | 29 Sep 07:17 2014
Picon

Nested functions and return - incorrect behavior from scalac?

Hello,

I've been doing some experimentation with nested functions, for example:

object NestedFunction{
def outerFn() : String = {
return innerFn + " world"

def innerFn() : String = {
return "hello"
}
}
}

This does not compile:

$ scalac NestedFunction.scala
NestedFunction.scala:8: error: type mismatch;
 found   : Unit
 required: String
        }
        ^

The problem is not that innerFn is used before it is declared; this is allowed (and good!); the problem is that scalac can't see that outerFn will always in fact return the correct type.  If the code is changed to add another line at the end this makes the compiler happy:

object NestedFunction{
def outerFn() : String = {
return innerFn

def innerFn() : String = {
return "hello"
}
return "this code is dead"
}
}

This seems incorrect; the compiler should be able to recognize that the function will return the correct type without the last line (and in fact the final return statement is dead code and can never be reached).  Or am I missing something?

-Ben

--
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.
Rich Oliver | 25 Sep 15:17 2014
Picon

Fold not foldleft or foldright should be used on all commutative operations

Have I understood things correctly?

1 Fold always uses the most efficient method of folding.

2 If an operation can be folded left or folded right in practice it is always commutative. I can't think of any operations that can be performed in sequence order or reverse sequence order that can not be performed in any order.

3 Hence for commutative operations we should always simply use fold. We don't need to know which is the most efficient fold method for the particular collection that we are using because simple fold just provides it. If we have an operation that is assocaitve but not commuttive, then we need to use the logically approriate fold: foldleft or fold right. Again we don't need to know which is the most efficient fold method for the particular collection that we are using because we are logically constrained to use the particular fold method regardless of its efficiency.

--
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.
dk14 | 25 Sep 13:41 2014
Picon

adding const to the scala.Predef

I've seen that identity function is already in Predef - so maybe const also should be there. 
It seems to be a good idea to represent fundamental functions like a part of a language to user.

https://github.com/scala/scala/pull/4003

--
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