gmane.comp.lang.scala

parameter inference

Simon Schäfer — 2013-05-17T23:45:43

I accidentally noticed that on 2.10.2.v20130425-053916-403ba8938f the 
following compiles:

   class A { def a(i: Int) = i }
   class B extends A { override def a(i) = i } // no type parameter on i

While I heard of such a potential change some time ago, I can't find the 
commit where it is finally merged.

Anyone here who can point me to it?

compiler message not clear with FiniteDuration.times

Michel Daviot — 2013-05-15T10:15:00

sbt console
Welcome to Scala version 2.10.1 (Java HotSpot(TM) 64-Bit Server VM, Java 
1.7.0_07).

val fd=scala.concurrent.duration.FiniteDuration(3, "seconds")

fd * 2.5 // works fine
res0: scala.concurrent.duration.Duration = 7500 milliseconds

scala> val res:scala.concurrent.duration.FiniteDuration =fd * 2.5
<console>:14: error: type mismatch;
 found   : Double(2.5)
 required: Long
       val res:scala.concurrent.duration.FiniteDuration =fd * 2.5


I would expect instead of this message to have 
found : Duration
expected : FiniteDuration

Unary type view

Ka Ter — 2013-05-14T12:36:57

Hi,

I have problems understanding Scala's type system. Why does the
following code not compile in the line 'val z = ...'?

trait Unary[U[_], A]
           
case class A[T](t: T)
case class B[I[_], A](i: I[A]) extends Unary[({type O[X] = B[I, X]})#O, A]
               
def unary[MA <: Unary[U, A], U[_], A](ma: MA with Unary[U, A]): U[A] =
ma.asInstanceOf[U[A]]
           
val a = A(5)
val b = B(a)
val z = unary(b)

I get the error message: Multiple markers at this line
    - type mismatch; found : B[A(in method
monadicAndMonadicStackSelection),Int] required: MA with
     Unary[U,A(in method unary)]
    - no type parameters for method unary: (ma: MA with Unary[U,A])U[A]
exist so that it can be applied to
     arguments (B[A,Int]) --- because --- argument expression's type is
not compatible with formal parameter type;
     found : B[A,Int] required: ?MA with Unary[?U,?A]

I don't understand why Scala cannot match the types. B is of type Unary.

I expect the type of z to be ({type O[X] = B[A, X})#O[Int]. I know that
I can achieve that using scalaz's Unapply type class, but I don't
understand why my solution should not work either.

Any thoughts?

Mining for granularity beyond AnyVal

Paul Phillips — 2013-05-11T18:01:01

https://gist.github.com/paulp/5560802


*
*

/* A better way to tag types?
 *
 * 1) object Time: here we are distinguishing between different uses of a Long,
 * yet there is no boxing whatsoever.
 *
 *   main calls start: ()J
 *   main calls timed: (Function0, J)
 *   Function0 gives up the result: ()J
 *   timed calls now: ()J
 *   timed calls elapsed$extension: (JJ)J
 *   main calls _2: ()J
 *
 * 2) object Bounds: Enumerate the acceptable uses.
 * Only Usage subclasses which appear in the lower bound can appear.
 */
import Time._
object Time {
  // Markers - these can have any structure or no structure.
  sealed trait Usage
  sealed trait StartTime extends Usage
  sealed trait CurrentTime extends Usage
  sealed trait CalendarTime extends Usage

  type Current  = Timestamp[CurrentTime]
  type Start    = Timestamp[StartTime]
  type Calendar = Timestamp[CalendarTime]

  // We could make the constructor private if we wanted to tightly
  // control instantiation.
  final class Timestamp[T <: Usage](val nanos: Long) extends AnyVal {
    // Originally I had this return a Nanos value class, but unfortunately
    // specialization doesn't work with value classes and it was boxed
    // in the return value of timed.
    def elapsed(implicit other: Current): Long = math.abs(other.nanos - nanos)
    override def toString = s"Timestamp($nanos)"
  }
  object Timestamp {
    implicit def start: Start                 = new
Timestamp[StartTime](System.nanoTime)
    implicit def now: Current                 = new
Timestamp[CurrentTime](System.nanoTime)
    def apply(date: java.util.Date): Calendar = new
Timestamp[CalendarTime](date.getTime * 1000000L)
  }
  // If there were only one "Timestamp" class, the implicit parameter with the
  // start time stamp would be used as the implicit argument to elapsed rather
  // than the one in the Timestamp companion.
  def timed[< at >specialized T](body: => T)(implicit stamp: Start): (T,
Long) = (body, stamp.elapsed)
  // public scala.Tuple2<java.lang.Object, java.lang.Object>
timed$mDc$sp(scala.Function0<java.lang.Object>, long);
  //        0: new           #81                 // class scala/Tuple2$mcDJ$sp
  //        5: invokeinterface #85,  1           // InterfaceMethod
scala/Function0.apply$mcD$sp:()D
  //       17: invokevirtual #31                 // Method
Time$Timestamp$.now:()J
  //       20: invokevirtual #35                 // Method
Time$Timestamp$.elapsed$extension:(JJ)J

  < at >annotation.tailrec def busywork(x: Double, reps: Long): Double = {
    if (reps <= 0) x
    else busywork((x + util.Random.nextInt) / 3, reps - 1)
  }
  def main(args: Array[String]): Unit = {
    val reps = args(0).toLong
    // 34: invokevirtual #66                 // Method Time$Timestamp$.start:()J
    // 37: invokevirtual #70                 // Method
Time$.timed$mDc$sp:(Lscala/Function0;J)Lscala/Tuple2;
    // 40: invokevirtual #75                 // Method
scala/Tuple2._2$mcJ$sp:()J
    val ms = timed(busywork(0, reps))._2 / 1e6
    println(f"$reps reps of busywork required $ms%.3f")
  }
}
object Bounds {
  def limited[T >: CurrentTime with StartTime <: Usage](implicit
stamp: Timestamp[T]) = println(stamp)

  def f1 = limited(Timestamp.start) // compiles
  def f2 = limited(Timestamp.now)   // compiles
  // def f3 = limited(Timestamp(new java.util.Date)) // fails

  // ./a.scala:65: error: type mismatch;
  //  found   : Time.Calendar
  //     (which expands to)  Time.Timestamp[Time.CalendarTime]
  //  required: Time.Timestamp[Time.Usage]
  // Note: Time.CalendarTime <: Time.Usage, but class Timestamp is
invariant in type T.
  // You may wish to define T as +T instead. (SLS 4.5)
  //   def f3 = limited(Timestamp(new java.util.Date))
  //                             ^
  // one error found
}

[Macros] Passing context instance reference to another class

Alexander Myltsev — 2013-05-11T08:02:04

Hi!

I have code:

object Parser {
  type ParserContext = Context { type PrefixType = Parser }

  def ruleImpl(c: ParserContext)(r: c.Expr[Rule]): c.Expr[Boolean] = {
    val opTreeContext = new OpTreeContext(c)
    val opTree = opTreeContext.parse(r.tree) // Compilation error (see 
below): Parser.scala: type mismatch;
    opTree.render
  }
}

class OpTreeContext(c: Parser.ParserContext) {
  import c.universe._

  def parse(tree: c.Tree): Expression = ???
}

Compiler is not happy with error:
[error] Parser.scala: type mismatch;
[error]  found   : c.universe.Tree
[error]  required: opTreeContext.c.Tree
[error]     (which expands to)  opTreeContext.c.universe.Tree
[error]     val opTree = opTreeContext.parse(r.tree)
[error]                                        ^


Why type of `c` in OpTreeContext differs from type of `r.tree` in 
`ruleImpl`? And how to pass instance reference of Parser.ParserContext to 
another class?

Regards,
  Alexander

Existentials and method types

Ryan Hendrickson — 2013-05-09T18:35:09

I was surprised and delighted by a bug a coworker found today, which hinged on my assuming that surely value types can never contain non-value types. Here's a simplified version:


import scala.reflect.runtime.universe._

class A {
  object B
}
class C {
  val a = new A
  val b = a.B
}

object Test extends App {
  val cType = typeOf[C]
  val bType = cType.member("b": TermName).typeSignatureIn(cType)
  bType match {
    case NullaryMethodType(_) =>
      println("That's what I thought.")
    case ExistentialType(_, NullaryMethodType(_)) =>
      println("Huh???")
  }
}


Is this a bug, or is it reasonable to expect that ExistentialType, a value type, can contain a NullaryMethodType, a non-value type?






(please forgive me my corporate legal disclaimer)

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

This message is intended exclusively for the individual(s) or entity to
which it is addressed. It may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. 
If you are not the named addressee, you are not authorized to read, 
print, retain, copy or disseminate this message or any part of it. 
If you have received this message in error, please notify the sender 
immediately by e-mail and delete all copies of the message.

Workaround for value class type erasure?

Mark Hammons — 2013-05-09T12:52:34

So it appears to me that value classes have their types erased to the type
they take for their single value. This of course causes the standard type
erasure issues to pop up.

Right now I'm having trouble with overloading. I have function a with
signatures Int => UInt and UInt => UInt. It fails to compile because of
double definition. Is there a way to get past this issue?

Strange behaviour of Numeric[Int]/IntIsIntegral?

Andrew Phillips — 2013-05-07T04:26:22

It would be great if someone could shed some light on the following REPL 
sessions (2.10.0) [1]:

They are two attempts to produce a situation with ambiguous implicits. The 
first works as expected:

trait Settings { def title: String }
implicit object DefaultSettings extends Settings { val title = "default" }
scala> println(implicitly[Settings].title)
default

implicit object TestSettings extends Settings { val title = "test" }
scala> println(implicitly[Settings].title)
<console>:11: error: ambiguous implicit values:

The second attempt - to reproduce the result using an existing trait, 
Numeric[Int] - is where it gets interesting:

// using default Numeric[Int]: IntIsIntegral
scala> implicitly[Numeric[Int]].times(3, 4)
res0: Int = 12
implicit object StrangeMath1 extends Numeric[Int] {
   |   def times(x: Int,y: Int): Int = x + y
   |   // ignore the remainder
   |   ...
   | }
scala> implicitly[Numeric[Int]].times(3, 4)
res1: Int = 7

OK, so no ambiguous implicits so far? Guess StrangeMath1 overrides 
IntIsIntegral somehow? To continue:

implicit object StrangeMath2 extends Numeric[Int] {
   |   def times(x: Int,y: Int): Int = x + y
   |   // ignore the remainder
   |   ...
   | }
 
scala> implicitly[Numeric[Int]].times(3, 4)
res2: Int = 12

OK, so now back to IntIsIntegral?!? Indeed:

scala> println(implicitly[Numeric[Int]])
scala.math.Numeric$IntIsIntegral$< at >129f8ab4

But then:

scala> implicitly[Numeric[Int]]
<console>:10: error: ambiguous implicit values:
 both object StrangeMath1 of type StrangeMath1.type
 and object StrangeMath2 of type StrangeMath2.type
 match expected type Numeric[Int]
              implicitly[Numeric[Int]]

A quick search through the issue list and otherwise online didn't turn up 
anything that appears to discuss this directly. Thoughts/pointers as to 
what might be going on here much appreciated!

Regards

ap

[1] https://gist.github.com/demobox/8f465c70764c9a47c89f

match-expression in infix position

Simon Schäfer — 2013-05-04T21:25:53

Is there a special reason why it is not possible to use a 
match-expression in infix position (without surrounding it with 
parentheses)?

scala> 1 match {case x => x} + 1
<console>:1: error: ';' expected but identifier found.
        1 match {case x => x} + 1
                              ^

scala> (1 match {case x => x}) + 1
res23: Int = 2

peano class-cast-exception

Jan Vanek — 2013-05-04T08:10:43

After reading the "ambiguous reference to overloaded definition" thread 
in scala-user I played with Rex's Peano example (in 2010) where he tries 
to achieve what he calls "conditionally abstract". I didn't achieve it 
but I found a bug - the example compiles but crashes with 
ClassCastException. I did a minimal search for "ClassCastException" in 
JIRA but didn't find the exact match. Please have a look.

trait Peano {
   type Nat <: NatApi

   trait NatApi { this: Nat =>
     def succ: Nat

     def count(n: Int): Nat = {
       if (n < 1) this
       else if (n == 1) succ
       else count(n - 1).succ
     }
   }
}

class Peano4A extends Peano {
   class Nat(i: Int) extends NatApi {
     def succ = new Nat(i + 1)
   }
}

class Peano4B extends Peano4A {
   class Nat(val s: String, i: Int) extends super.Nat(i) {
     // "override" def succ = new Nat("s("+s+")", i + 1)
   }
}

def main(args: Array[String]) {
   val p4b = new Peano4B
   val n0 = new p4b.Nat("0", 0)
   val n1 = n0.count(1)
   println(n1.s)
}

With regards,
Jan

[GSoC 2013] Alternate/Social Scala Documentation

Mayur Patil — 2013-05-03T17:09:51

Hello,
   
    On GSoC idea page, there is written[1] 

    We have a small prototype you can use as a starting point.

    So anyone knows that prototype please ??

    Thanks !!

    [1]http://www.scala-lang.org/gsoc2013
*
--
Cheers,
Mayur*

[GSoC 2013]Prototype an extension of for-comprehensions for Scala

Mayur Patil — 2013-05-02T03:03:06

Hello,

   Sorry for late response.

    May I know who is the mentor for this project it will be a great help ??

    Thank you !!

*--
Cheers,
Mayur*

[GSoC 2013] Prototype an extenson of For Comprehension of Scala language

Mayur Patil — 2013-05-02T03:01:09

Hello,

   Sorry for late response.

   May please know who is the mentor for this project it will great help to 
me ??

   Thanks !!
*
--
Cheers,
Mayur*

A very nicely encyclopedic Quora answer about functional programming languages

Alex Cruise — 2013-05-01T17:24:56

http://www.quora.com/Functional-Programming/What-are-some-differences-between-the-many-functional-programming-languages/answer/Jesse-Tov?__ac__=1#comment2059000

The highlighted comment in particular would probably benefit from Eugene
chiming in. :)

-0xe1a

Map with types as keys, respecting type equivalence

Ryan Hendrickson — 2013-04-30T19:05:41

Is it possible to create a map with types as keys that respects type equivalence and doesn't have linear lookup cost?

To get a hash map, I'd need a hash function on types that respects type equivalence. The built-in hashCode on types doesn't:

  typeOf[String].## != typeOf[java.lang.String].##

This isn't terribly surprising; those values do seem like different data structures even if they represent equivalent types. What is kind of driving me up the wall is that I don't see a way to normalize typeOf[String] into typeOf[java.lang.String], even though something in =:= must be doing that or something equivalent to that. I tried the suggestively-named 'normalize', but

  typeOf[String].normalize.## != typeOf[java.lang.String].normalize.##

I tried poking around in the internal API and found dealias, but that also doesn't cut it. Is there any way, public or private, to go from typeOf[String] to typeOf[java.lang.String]? (Besides erasure, which is entirely too liberal.)

(Type equivalence in Scala is undecidable in general, right? I'm not sure what compromises =:= makes in the face of that fact, but I'm sure I'd be fine with similar compromises.)

Or, I could shoot for a tree map, which would require me to give some total ordering to types that also respects type equivalence. I have no idea how I'd begin to do that without solving the above problem, but maybe someone has thought of something clever?






(please forgive me my corporate legal disclaimer)

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

This message is intended exclusively for the individual(s) or entity to
which it is addressed. It may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. 
If you are not the named addressee, you are not authorized to read, 
print, retain, copy or disseminate this message or any part of it. 
If you have received this message in error, please notify the sender 
immediately by e-mail and delete all copies of the message.

[GSoC 2013] Parboiled2: PEG parser via Scala Macros

Alexander Myltsev — 2013-04-27T16:16:20

Good day.

My name is Alexander Myltsev. I am going to apply to GSoC this year with 
Parboiled2 project.

You probably have heard of Parboiled [1] – lightweight library providing 
input text parsing based on PEGs (parsing expression grammars). It is 
written in Java and has nice wrapper in Scala. You can find projects using 
parboiled at [2].

A Parboiled parser is a complex object of objects that lives on heap. It is 
quite easy to compose a parser. But essentially it “interprets” the parser 
rule tree. So, it is rather slow.

On the other hand a parser could be implemented with heavy usage of 
mutations, rather fast arithmetic and logical operations, and avoids object 
constructions and function callings like at [3]. It is faster, but is far 
from functional style and harder to program by hand.

Could good-looking parser program and fast runtime speed be combined? Yes, 
it can be done by some sort of parser “compilation” from rules with help of 
Scala macros. The prototype is at [4]. You can find elegant 
combinator-style parser construction at [5]: 

def combination = rule { ('a' || 'b' || 'c') ~ ('d' || 'e') ~ 'f' }

that is expanded to a class with mutations similar to [3].

There are three major stages from current prototype to first version of 
ready to use library:
1. Transform Scala AST to intermediate rule operation tree (“OpTree”). 
OpTree is easier to operate than complicated constructs like at [6].
2. Apply transformations and optimizations to OpTree. E.g. expand string 
matching to their expanded forms. That means that [7] will be needed no 
more.
3. Transform processed OpTree back to Scala AST with parser classes of 
higher speed at runtime

I would formulate it more carefully in my proposal. Still, idea should be 
clear enough.

What do you think of that? Is it good enough for GSoC? Should it be 
extended somehow? Any ideas are welcome!

Mathias Doenitz [8] -- the original creator of Parboiled -- is kindly 
agreed to mentor this project.

[1] https://github.com/sirthias/parboiled
[2] https://github.com/sirthias/parboiled/wiki/Projects-using-parboiled
[3] 
https://github.com/spray/spray/blob/master/spray-http/src/main/scala/spray/http/parser/UriParser.scala 

[4] https://github.com/alexander-myltsev/parboiled2
[5] 
https://github.com/alexander-myltsev/parboiled2/blob/develop/src/test/scala/org/parboiled/ParserSpec.scala#L27 

[6] 
https://github.com/alexander-myltsev/parboiled2/blob/develop/src/main/scala/org/parboiled/Parser.scala#L73 

[7] 
https://github.com/alexander-myltsev/parboiled2/blob/develop/src/main/scala/org/parboiled/Parser.scala#L54 

[8] https://github.com/sirthias

Regards,
  Alexander

foldLeft and /: strange behaviour

Faisal Faizan — 2013-04-27T03:17:09

Hi,

I was going through "Chapter 16 of Programming in Scala, First Edition" and
looking at the use of fold left operation (/:) to efficiently reverse a
list. I got a surprising behavior difference between foldLeft and it's
short form (/:). Though the scala API and the book says that both functions
are one and the same they both give different results. I tried it in both
scala worksheet and REPL.

Below is the code from my scala worksheet -

val xs  = List(1,2,3,4,5)                 //> xs  : List[Int] = List(1, 2,
3, 4, 5)
  def reverseLeft[T](xs: List[T]) =
    (List[T]() /: xs) {(ys, y) => y :: ys}        //> reverseLeft: [T](xs:
List[T])List[T]

  def reverseLeft1[T](xs: List[T]) =
    (List[T]() foldLeft xs) {(ys, y) => y :: ys}  //> reverseLeft1: [T](xs:
List[T])List[T]

  reverseLeft(xs)                                 //> res0: List[Int] =
List(5, 4, 3, 2, 1)
  reverseLeft1(xs)                                //> res1: List[Int] =
List(1, 2, 3, 4, 5)


So, using foldLeft is not giving me the correct behaviour here.
reverseLeft1() is not reversing the list but reverseLeft() is.
Please suggest if I am missing something here.

Regards
Faisal

Packrat Parser bug?

Harshad — 2013-04-26T14:14:12

Hi all,

I have this toy grammar with some left-recursion in it. I have used Packrat 
parsers to get around the left-recursion problem. Parsing with a string 
works fine but parsing from a file throws a stackoverflow error. 

object test extends App {

  object ToyParser extends StandardTokenParsers with PackratParsers {
    lexical.delimiters ++= List("+", "/", "=", "(", ")", ":")

    private lazy val number = accept("number", { case lexical.NumericLit(n) 
=> n.toInt })
    private lazy val expression: PackratParser[Int] = numericExpr
    private lazy val numericExpr: PackratParser[Int] = (addExpr | 
numericLiteralExpr)
    private lazy val numericLiteralExpr: PackratParser[Int] = number
    private lazy val addExpr: PackratParser[Int] = ((numericExpr <~ "+") ~ 
numericExpr) ^^ { case a ~ b => a + b }

    def parseAll = phrase(expression)
  }

  val scanner = new ToyParser.lexical.Scanner("10 + 20 + 30")
  println(ToyParser.parseAll(scanner)) // Success

  val scanner2 = new ToyParser
.lexical.Scanner(StreamReader(io.Source.fromFile("test").reader))
  println(ToyParser.parseAll(scanner2)) // StackOverflowError

}

Is this a bug, or am I doing something wrong?

BigInt as a value class?

Mark Hammons — 2013-04-26T13:10:31

I've been working a little on porting https://github.com/tbuktu/bigint to
scala and using value classes and universal traits to implement BigInt. So
far my implementation seems to have a linear speed improvement over
scala.math.BigInt on repeated addition. I was curious, if I get this code
into good shape would it be able to be added to the standard library?

Is it now too late applying GSoC?

Jiaming Lu — 2013-04-26T12:19:41

I just heard the news of GSoC starting yesterday :(

Interested in this project because I recently completed my compilers course 
on Coursera (implemented that compiler for COOL) and also being interested 
in functional programming.

I'm new to scala, but know some haskell, used to programming in python and 
c++. Does my background sufficient for participating in this year?

GSoC Parallel Collections Advice

grypp — 2013-04-26T12:12:16

Dear Sir/Madam,

I'm MSc High-Performance Computing student at Polytechnic University
of Catalonia(BarcelonaTech). My MSc program is 2 years, and this year
is my first year 2nd term. In addition to I'm going to EPFL for 2nd
year with exchange program and i'm going to carry out my master
thesis. Therefore I can continue this project as my master thesis.

I worked previously 2 years as .Net developer. I used to much offline
debugging like WinDBG. Therefor I have a know-how .Net framework,
intermediate languages and Garbage Collector and GC generations. I
suppose .net framework is very similer JVM.

I'm interesting parallel collection scheduler for gsoc project. I'm
working on mercurium parallel compiler that was developed by my
university and also working on nanos task scheduler.
(http://pm.bsc.es/nanox) at university. I read some task scheduler
paper. Cilk and work-first scheduler makes sense for me instead of
classical fork-join algorithm. In addition to they can provide task
stealing. Scheduling performance is addressed by
http://www.sarc-ip.org/files/null/Workshop/1234128788173__TSchedStrat-iwomp08.pdf
 paper.

However i am not sure. Should i focus new task scheduling systems?
otherwise should i focus optimize existing scheduler?

King Regards,

Güray Özen
Polytechnic University of Catalonia